Self-host n8n on a VPS.
Your automation engine, your credentials, your metal.

n8n is a workflow automation engine: a visual canvas where you wire a trigger — a webhook, a schedule, a new row in a database, a message in a queue — into a chain of nodes that call APIs, transform data, branch on conditions, run arbitrary JavaScript or Python, and hand the result to whatever comes next. Several hundred integration nodes ship in the box, plus a generic HTTP Request node that covers everything else. Since the 1.x line it also carries AI Agent and LLM nodes, which is why a large share of the people installing it in 2026 are building agents rather than classic ETL plumbing.

The part that matters before you type a single command is the licence, because n8n is not open source in the OSI sense and the difference is not academic. The core ships under the Sustainable Use License: a non-exclusive, royalty-free, worldwide grant to use, copy, modify and distribute the software for internal business purposes and for personal or non-commercial use. What it withholds is the right to charge others for n8n or for a derivative of it — which is the clause that rules out building a paid "managed n8n" product on top. Separately, any file carrying .ee. in its name or .ee in its path is excluded from that licence entirely and requires a paid n8n Enterprise License.

Read plainly: running n8n on a VPS to automate your own company, your own clients' work delivered as a service you perform, or your own personal life, is inside the free grant and always has been. Selling n8n-as-a-hosting-product is not. Almost every "is n8n really free?" argument on the internet is two people talking past each other across that line.

The cost side. n8n Cloud is priced per execution: the Starter plan is €20 a month billed annually for 2,500 executions, Pro is €50 a month for 10,000, Business is €667 a month for 40,000. Self-hosted, the execution count is not a line item at all — it is bounded by how much CPU and memory the box has. A workflow that polls an API every five minutes burns 8,640 executions a month on its own; on Cloud that single workflow already forces the Pro tier, and on a $3.90 VPS it is a rounding error against idle CPU.

Cloud prices as published on n8n.io in August 2026, billed annually; monthly billing costs more. The trade is not only money — self-hosting moves upgrades, backups, TLS renewal and uptime onto your side of the line.

In the panel: Order → VPS → Sentinel, image Debian 12. No email address is required to open the account, no identity document is requested at any point, and the invoice is settled in Monero, Bitcoin, Lightning or any of the other supported assets. Pick the bastion by latency to the services you automate rather than to yourself — an automation server talks to APIs far more than it talks to you.

Then create the DNS record before you touch the server: an A record for n8n.example.com pointing at the VPS IPv4, and an AAAA record if you use IPv6. This has to be done first, because Caddy asks Let's Encrypt for a certificate the moment the stack starts, and a certificate request for a name that does not resolve fails — then backs off, and you spend twenty minutes wondering why the site is unreachable.

Give the DNS a minute to propagate and confirm it from your own machine before continuing:

dig +short n8n.example.com
# → the IPv4 of your VPS, and nothing else

Before anything listens on a public port, run the first-hour hardening checklist — key-only SSH, a firewall that allows 22, 80 and 443 and nothing else, and unattended security upgrades. An automation server is a credential vault; it deserves the full hour.

Create the directory and generate the two secrets first. Generate them now, in this order, and paste them into the .env as you go — the encryption key in particular must exist before n8n's first boot, not after.

mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32   # → N8N_ENCRYPTION_KEY
openssl rand -hex 24   # → POSTGRES_PASSWORD

/opt/n8n/.env

DOMAIN=n8n.example.com
LETSENCRYPT_EMAIL=you@example.com
GENERIC_TIMEZONE=Europe/Stockholm

N8N_ENCRYPTION_KEY=paste_the_32_byte_hex_here
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste_the_24_byte_hex_here

Lock the file down immediately — it holds the key to every credential the instance will ever store:

chmod 600 /opt/n8n/.env

/opt/n8n/docker-compose.yml

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DOMAIN=${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://${DOMAIN}
      - WEBHOOK_URL=https://${DOMAIN}/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_VERSION_NOTIFICATIONS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  caddy_data:
  caddy_config:
  pg_data:
  n8n_data:

/opt/n8n/Caddyfile

{$DOMAIN} {
    encode zstd gzip
    tls {$LETSENCRYPT_EMAIL}
    reverse_proxy n8n:5678
}

Two design decisions worth naming. First, n8n does not publish a port. Only Caddy binds 80 and 443; n8n listens on 5678 inside the Compose network where nothing outside the host can reach it. A surprising number of self-hosted n8n instances are on the public internet on port 5678 with no TLS in front, and search engines for exposed services index them. Second, the n8n data volume stays mounted even though PostgreSQL now holds the workflows — that directory still carries the instance settings, the log files and the source-control assets.

Bring it up:

cd /opt/n8n
docker compose up -d
docker compose logs -f caddy   # watch the certificate being issued

An n8n that boots, shows the editor and runs a manual test is not yet a working n8n. The half that breaks quietly is inbound webhooks, and it breaks in ways that look like the third-party service is at fault.

WEBHOOK_URL. Without it, n8n builds webhook URLs from N8N_HOST and N8N_PORT and hands you something like http://localhost:5678/webhook/abc — which you then paste into Stripe or GitHub, where it can never be reached. The Compose file above sets WEBHOOK_URL to the public HTTPS root, which is what the editor will display and what the outside world can actually call.

N8N_EDITOR_BASE_URL. The public URL n8n uses for links in the emails it sends — password resets, user invitations. Wrong here means an invitation link pointing at localhost, which is a support ticket from a colleague rather than a broken integration.

N8N_PROXY_HOPS. n8n reads the client IP from X-Forwarded-For, and it only trusts as many hops as this number says. With one reverse proxy in front — the Caddy in this stack — the value is 1. Put Cloudflare in front of Caddy and it becomes 2. Leave it at the default 0 and every request appears to come from the proxy itself, which quietly breaks rate limits and any IP-based logic in your workflows.

N8N_SECURE_COOKIE. It defaults to true, meaning the session cookie is only sent over HTTPS. That is the correct setting and this stack satisfies it. It is worth knowing because it explains the classic symptom of a first attempt over plain http: the login form accepts the password and then returns you to the login form, forever. The fix is TLS, not turning the flag off.

Test it properly. Create a workflow with a Webhook node, activate the workflow, copy the Production URL, then call it from a machine that is not the server:

curl -i https://n8n.example.com/webhook/<path>
# → HTTP/2 200, and a new execution visible in the editor

The distinction that trips everybody once: the Test URL only listens while you have the editor open with "Listen for test event" armed. The Production URL exists only when the workflow is toggled Active. A webhook that works in the editor and 404s in production is almost always an inactive workflow.

By default n8n runs in regular mode: the same process that serves the editor and receives webhooks also executes the workflows. It is simple and it is correct until one long workflow starts making the others wait. The symptom is unmistakable — executions sit in "running" for minutes, the editor gets sluggish, and a webhook that should answer in 200 ms answers in eight seconds.

Queue mode splits the job. The main instance keeps the editor, the triggers and the webhook endpoints; it pushes execution IDs into Redis; separate worker processes pull them, load the workflow from PostgreSQL, run it, and report back through Redis. Three rules follow from that architecture and all three bite people who skip them: every instance must share the same PostgreSQL database, every instance must carry the same N8N_ENCRYPTION_KEY, and SQLite is not supported at all.

The additions to the Compose file are a Redis service and one worker service, which is the same n8n image run with the worker command:

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--save", "60", "1", "--appendonly", "no"]
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker --concurrency=5
    depends_on:
      - redis
      - postgres
    environment:
      # the SAME encryption key and the SAME database as the main instance
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}

Add EXECUTIONS_MODE=queue and QUEUE_BULL_REDIS_HOST=redis to the main n8n service as well — both sides need to agree on the mode. Two options are worth setting on day one: OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true, so that pressing "Test workflow" in the editor does not tie up the main process, and N8N_GRACEFUL_SHUTDOWN_TIMEOUT, which defaults to 30 seconds and decides how long a worker is allowed to finish its current job during a redeploy. If your workflows routinely run longer than half a minute, raise it or every deployment kills work in flight.

Do not start here. Queue mode adds two moving parts and a class of failure that regular mode simply does not have. Stay in regular mode until you can see the queue growing or one workflow blocking another, then add a single worker on the same box before you add a second box. That progression — Sentinel in regular mode, Garrison with one worker, Ravelin with three — covers everything short of a genuinely large deployment.