How to Install n8n Locally

Tool overview

n8n is a workflow automation platform. It lets you connect apps, APIs, databases, files, AI models, webhooks, schedules, and custom code through a visual workflow editor.

It is often compared with Zapier or Make, but local self-hosted n8n is more developer-friendly. You can run it on your own machine, connect local services, use custom code, and keep workflows closer to your own infrastructure.

Local n8n is especially useful for:

• AI automation experiments
• Local database workflows
• Webhook testing
• Private internal tools
• Data cleanup
• Marketing operations
• Slack, Gmail, Notion, Google Sheets, and CRM workflows
• Ollama or local AI pipelines

Docker vs npm

Use Docker if you want the cleanest local install with predictable persistence.

Use npm if you want quick development, direct terminal control, or you already manage Node.js carefully.

For most users:

• Docker is better for repeatable local self-hosting.
• npm is better for quick testing and development.
• PostgreSQL is better than SQLite when the instance becomes important.

This guide starts with Docker because it is the safer default.

Step-by-step setup

docker --version

Step 1: Run n8n in Docker

Create the persistent volume:

docker volume create n8n_data

Start n8n:

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -e GENERIC_TIMEZONE="America/New_York" \
  -e TZ="America/New_York" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -e N8N_RUNNERS_ENABLED=true \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Replace America/New_York with your timezone.

Open:

http://localhost:5678

Create the first owner account and keep the login details secure.

Step 2: Understand persistence

n8n stores important local data in:

/home/node/.n8n

With Docker, that path must be mapped to a volume or host directory. If you run n8n without persistence, you can lose workflows and credentials when the container is removed.

The official Docker command maps:

n8n_data:/home/node/.n8n

Do not delete the volume unless you intentionally want to wipe the local instance:

docker volume rm n8n_data

For local testing, SQLite is the default database. n8n also supports PostgreSQL, and the .n8n directory is still important even when PostgreSQL is used because it holds other instance files.

Step 3: Keep n8n running in the background

For a quick test, interactive mode is fine. For normal local use, run detached:

docker run -d \
  --name n8n \
  -p 5678:5678 \
  -e GENERIC_TIMEZONE="America/New_York" \
  -e TZ="America/New_York" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -e N8N_RUNNERS_ENABLED=true \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

View logs:

docker logs -f n8n

Stop it:

docker stop n8n

Start it again:

docker start n8n

Step 4: Install n8n with npm

For npm installation, first confirm Node.js is in the currently supported version range in n8n's docs.

Try without a global install:

npx n8n

Then open:

http://localhost:5678

Install globally:

npm install n8n -g

Start:

n8n

Or:

n8n start

Update a global npm install:

npm update -g n8n

If npm permissions become messy on Windows or macOS, Docker is usually less painful.

Step 5: Import community workflows

n8n has a public workflow template library at:

https://n8n.io/workflows/

The library contains thousands of workflow automation templates across AI, sales, marketing, IT operations, support, document operations, and other categories.

Inside n8n:

1. Open the workflow editor.
2. Choose Templates.
3. Browse or search the template library.
4. Open a template.
5. Import it into your instance.
6. Review every node.
7. Replace credentials and IDs.
8. Test with safe sample data.

Do not activate a downloaded workflow blindly. A template is a starting point, not a security review.

Step 6: Import a JSON workflow file

If you have a .json workflow file:

1. Open n8n.
2. Create or open a workflow.
3. Use the import option.
4. Select the JSON file or paste the JSON.
5. Review all nodes and credentials.
6. Save.
7. Run one manual test.

Check especially:

• HTTP Request nodes
• Code nodes
• Database nodes
• AI model nodes
• Webhook nodes
• File read/write nodes
• Credentials
• Environment-specific URLs

Templates often need editing before they work in your local environment.

Step 7: Use local AI tools with n8n

Local n8n can call local model servers such as Ollama.

If n8n runs directly on the host:

http://localhost:11434

If n8n runs in Docker and Ollama runs on the host:

http://host.docker.internal:11434

For OpenAI-compatible Ollama endpoints, use:

http://host.docker.internal:11434/v1

The correct URL depends on the n8n node and provider mode. Test the endpoint with a simple workflow before building a large automation.

Step 8: Understand local webhooks

n8n can receive webhooks, but a local localhost webhook is not reachable by cloud services.

For local-only testing, a localhost webhook is fine.

For GitHub, Stripe, Slack, or other cloud services to call your local n8n, you need a tunnel, public URL, or hosted n8n instance.

n8n provides a tunnel option for local development, but it should be treated as development tooling rather than a production exposure model.

Step 9: Secure the local instance

Even local n8n can contain sensitive credentials.

Use these rules:

• Keep http://localhost:5678 private.
• Do not expose port 5678 publicly.
• Use strong owner credentials.
• Keep the data volume backed up.
• Do not paste production secrets into unreviewed templates.
• Check Code nodes before running imported workflows.
• Use a dedicated local test account for risky integrations.
• Do not activate workflows until they have been manually tested.

If you move from local testing to a networked instance, review n8n's production hosting guidance rather than simply opening a port.

Common problems

n8n opens but data disappears after restart

Your volume mapping is wrong or missing. Use:

-v n8n_data:/home/node/.n8n

Then keep the same volume when recreating the container.

Port 5678 is already in use

Map a different host port:

docker run -d \
  --name n8n \
  -p 5680:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Then open:

http://localhost:5680

Webhooks do not work from cloud apps

Cloud apps cannot reach localhost on your laptop. Use a tunnel for development, or deploy n8n where the webhook URL is publicly reachable and secured.

npm install fails

Check Node.js version compatibility and npm permissions. If you just want a working local instance, use Docker.

Imported templates fail

Update credentials, base URLs, IDs, and environment-specific settings. Test each branch manually before activating the workflow.

Background, planning, and caveats

Approximate planning cost (U.S.)

For local n8n, planning cost is mostly infrastructure and storage, not licensing for a self-hosted install.

Consider these buckets:

• Hardware: a small laptop setup is often enough for light local development, while sustained automation and queue-based workloads may want a bigger RAM/CPU profile.
• Storage: reserve enough local disk for your SQLite/PostgreSQL data, logs, workflow exports, and downloaded dependencies. Models and large attachments increase this quickly.
• Optional cloud/VPS: useful when you want always-on operation, predictable network access, or separate production from your laptop.
• API/provider costs: many integrations call third-party APIs and bill by usage, so your workflow can still incur recurring cloud costs even when n8n runs locally.
• Optional managed hosting: n8n Cloud exists with paid tiers and is useful when you need guaranteed uptime and managed operations instead of infrastructure duty.

If you are deciding among options, use local install for experimentation and private testing, and managed when you need uptime, support, and less operational overhead.

Cost breakdown

• one-time local setup:
  • host hardware or monthly VPS reservation,
  • optional SSL/domain costs,
  • backups storage or external object storage if you want off-device redundancy.
• recurring local setup:
  • power and internet,
  • model/API/provider usage from third-party connectors,
  • optional monitoring/security tooling.
• managed hosting:
  • subscription-level charges from n8n.

Use the official pricing page for current rates before buying a plan.

Data persistence and backups

Persistent storage is where most local n8n installations fail later. Keep this mapping:

n8n_data -> /home/node/.n8n

Back up at least:

• the Docker volume containing /home/node/.n8n,
• any external PostgreSQL data path if you switch from SQLite,
• your .env file and secrets references,
• a copy of exported workflows and credentials (where supported by your deployment model).

Test restore from backup on a fresh folder before a major workflow migration.

Credential handling

• Do not hardcode API keys into public scripts or shared workflow JSON files.
• Keep environment variables in .env and exclude them from version control.
• For multi-user local networks, rotate credentials before moving from test mode to routine use.
• Prefer dedicated service credentials with minimal scopes for integrations.

Security risk and operational cautions

A local container is not automatically safe:

• Do not expose localhost:5678 publicly.
• Disable untrusted network access to the n8n port.
• Review community nodes before enabling broad imports.
• Set execution pruning to reduce retained data footprint.
• Add reverse proxy/TLS if you expose the service outside local testing.

Questions before installing

• Will this run on one machine or a shared team subnet?
• Do you need PostgreSQL/Redis queue mode, or is SQLite enough for your load?
• Are any workflows handling regulated data?
• Do you have a documented restore process before adding production traffic?
• Do you have at least one test workflow to validate webhooks, APIs, and scheduled nodes?

Red flags

• No backup policy for n8n_data.
• Missing upgrade or rollback path for production-like use.
• Uncontrolled import of unknown templates and community nodes.
• Reaching for local install while expecting team-level controls without planning a database/host strategy.

Rollback and update guidance

For rollback:

• keep a backup of volume-backed data,
• keep your docker-compose or run command in version history,
• test restored instances with a simple workflow before resuming full traffic.

For updates:

• pull a new Docker image or update the npm package only after checking release notes,
• prefer regular, small updates over skipping many versions,
• verify behavior in a local test environment before touching a steady-state instance.

Bottom line

Use Docker with a persistent volume for the safest local n8n setup. Open http://localhost:5678, create the owner account, and keep n8n_data:/home/node/.n8n mapped so workflows and credentials survive restarts.

Use community templates for speed, but review every node before activation. Local n8n is powerful because it can connect private services, local AI models, webhooks, and custom code. That also means imported workflows deserve careful inspection.