AI Agent

How to Install n8n: 3 Ways

July 04, 2026 · 4 min read · YayaAgent Team

Most people picture installing n8n as one decision — self-hosted or not. It's actually three separate paths with very different trade-offs: running it locally just to try it out, using n8n's hosted Cloud plans, or self-hosting it on your own server for production. Which one is right depends entirely on whether you're testing an idea, need zero infrastructure work, or are running workflows that matter 24/7 — not on which one is "best" in the abstract.

This guide walks through all three, with the actual commands for each.

Before starting, one thing worth knowing: if you haven't used a workflow tool like n8n before, it helps to understand what an AI agent actually is before wiring up automations — n8n workflows and AI agents solve overlapping problems in different ways, and knowing the difference will save you some confusion later.

Quick Decision Guide

Situation	Recommended Path
Just want to try n8n or build/test a workflow	Local (npx or Docker on your machine)
Want zero infrastructure, don't mind a monthly fee	n8n Cloud (SaaS)
Need workflows running 24/7, want full control and no execution caps	Self-hosted on a server

1. Local Install

This is the fastest way to get n8n open in a browser with nothing else installed. Two options, depending on whether you want something disposable or something that persists.

Option A — npx (no install, disposable):

If you have Node.js 18+ already:

npx n8n

This downloads what it needs and starts n8n at http://localhost:5678. Nothing is installed permanently — good for a five-minute test, not for real use. n8n itself is explicit about this: it isn't safe for production.

Option B — Docker (persistent, recommended even for local use):

docker volume create n8n_data
docker run -it --rm --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

The volume (n8n_data) is what keeps your workflows, credentials, and settings across restarts — skip it and everything resets when the container stops. To keep n8n running in the background instead of tied to your terminal, swap -it --rm for -d.

Open http://localhost:5678, and on first run you'll be prompted to create an owner account (email, username, password) — this is local-only and doesn't touch any n8n cloud service.

2. n8n Cloud (SaaS)

This is the path with no Docker, no server, no updates to manage — you sign up, log in, and start building. It's the right call if you don't want to own the infrastructure at all.

There's no permanent free tier as of 2026. Plans are usage-based by execution (one workflow run = one execution, regardless of how many steps or nodes are inside it):

Plan	Executions/month	Rough monthly cost
Starter	2,500	~$20–24
Pro	10,000	~$50–60
Business	40,000	Custom / ~$667+

A 14-day free trial is available on Starter and Pro, no credit card required. The number that catches people off guard: a polling trigger checking every 5 minutes burns through 8,640 executions a month on its own — the Starter plan's entire allowance is gone in about 9 days from a single workflow like that. If you're planning to use Cloud, prefer webhook-triggered workflows over polling wherever the source supports it, and check your expected execution volume against the plan before committing.

To get started: sign up at n8n's Cloud plans page, verify your email, and you land directly in the workflow editor — no separate install step.

3. Server Deployment (Self-Hosted, Production)

This is the path for workflows that need to run continuously and reliably, without Cloud's execution caps. It takes more setup, but it's also the cheapest option long-term — a small VPS running Docker Compose typically costs a few dollars a month versus $20+ for Cloud, with no execution ceiling.

Minimum server: 1–2 vCPU, 2GB RAM to start (more if you're running many concurrent workflows).

docker-compose.yml — Postgres instead of the default SQLite, since SQLite locks on writes and struggles once multiple workflows run concurrently:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change_this_password
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      # Identity and URLs — get these wrong and webhooks silently fail
      N8N_HOST: n8n.yourdomain.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.yourdomain.com/
      N8N_PROXY_HOPS: 1          # required if you're behind a reverse proxy

      # Encryption key — generate once, back it up, never change it
      N8N_ENCRYPTION_KEY: your_64_char_hex_key

      # Database
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change_this_password

      GENERIC_TIMEZONE: UTC
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres

volumes:
  postgres_data:
  n8n_data:

Generate the encryption key once, before first boot, and store it somewhere durable:

openssl rand -hex 32

This key is not recoverable — lose it and every stored credential becomes permanently unreadable, with no way to decrypt them. Back it up to a secret manager immediately, not just a text file on the same server.

Start the stack:

docker compose up -d

Put n8n behind a reverse proxy (Nginx, Traefik, or Caddy) for HTTPS — n8n itself doesn't terminate SSL. Whatever proxy you use, WEBHOOK_URL must match your actual public domain exactly, or external services (Stripe, GitHub, Slack) will try to call a URL n8n can't receive.

Myth vs. Reality

Myth: Self-hosting n8n is only worth it if you're technical enough to manage servers professionally.

Reality: The Docker Compose setup above is genuinely a copy-paste-and-fill-in-the-blanks job — the actual skill required is patience with environment variables, not deep sysadmin experience. Think of it less like running your own data center and more like setting up a home router: most of the complexity is in getting a handful of settings right once, not in ongoing expertise.

That said, self-hosting does put updates, backups, and uptime on you — n8n itself recommends Cloud for teams without the time or interest in owning that.

Troubleshooting

Symptom	Fix
Webhooks silently never trigger	`WEBHOOK_URL` doesn't match your public domain, or `N8N_PROXY_HOPS` isn't set behind a reverse proxy
All credentials suddenly unreadable after redeploying	`N8N_ENCRYPTION_KEY` changed or wasn't persisted — there's no recovery; re-enter credentials and fix the volume/secret going forward
"Database is locked" errors under real usage	Still on default SQLite — switch to `DB_TYPE=postgresdb`
Container restarts with settings reset	The Docker volume for `/home/node/.n8n` wasn't mounted, or was mounted to the wrong path
n8n Cloud workflows suddenly stop running	Execution cap hit for the month — Cloud halts everything with no grace period until the next billing cycle

Bottom Line

There's no single "right" way to install n8n — a local Docker container is right for testing, Cloud is right when you'd rather pay a monthly fee than own any infrastructure, and a self-hosted server is right once you need workflows running continuously without an execution ceiling. Whichever you pick, the database and execution settings you choose upfront (SQLite vs. PostgreSQL, regular vs. queue mode) are the same settings that determine whether your workflows stay fast as usage grows — if you're already noticing runs slowing down or timing out, diagnosing why your agent or workflow is slow walks through exactly which of those settings to check first.