n8n is the kind of tool you start using lightly and then quietly route half your operations through. At which point "it's running on someone's cloud seat, metered per execution, with my API keys living on their servers" starts to feel less great. Self-hosting fixes all three — flat cost, no execution cap, and your keys stay on a box you own. With Docker it's a fifteen-minute job.
Honest numbers first, so you don't over- or under-buy:
n8n isn't CPU-hungry at rest; it spikes during runs. A 2-core box is fine for most setups. (More on matching specs to workload in the sizing guide.)
On a fresh Ubuntu/Debian box, install Docker:
curl -fsSL https://get.docker.com | sudo sh
Make a folder and a docker-compose.yml
— n8n with a persistent volume and Postgres:
services:
n8n:
image: docker.n8n.io/n8nio/n8n
restart: always
ports:
- "127.0.0.1:5678:5678"
environment:
- N8N_HOST=n8n.yourdomain.com
- N8N_PROTOCOL=https
- WEBHOOK_URL=https://n8n.yourdomain.com/
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=db
- DB_POSTGRESDB_PASSWORD=change-me
volumes:
- ./n8n-data:/home/node/.n8n
depends_on: [db]
db:
image: postgres:16
restart: always
environment:
- POSTGRES_PASSWORD=change-me
- POSTGRES_DB=n8n
volumes:
- ./db-data:/var/lib/postgresql/data
sudo docker compose up -d
Two things worth pointing out: the volumes (n8n-data
, db-data
) are what keep your workflows alive across restarts and upgrades — don't skip them. And n8n is bound to 127.0.0.1
, not 0.0.0.0
— it's not exposed to the internet directly. That's deliberate; the next step handles access safely.
127.0.0.1:5678
. This is where a ssh -L 5678:127.0.0.1:5678 user@server
, then open localhost:5678
. Works fine on a NAT VPS.n8n holds your API keys and credentials, so the box must be tight: do the security checklist (SSH keys, firewall, no password login) before you put real credentials in. restart: always
in the compose file already means Docker brings n8n back after a crash or reboot — that's your uptime handled.
Be honest with yourself about volume. If you run automations constantly, self-hosting wins on cost (flat vs per-execution) and removes any workflow/run limits. If you trigger a few flows a month, a hosted seat is less hassle. But the control argument stands regardless: your workflows, your data, your keys — on your server, not rented. For most people who got serious about n8n, that's the deciding factor.
A 2 GB box, a compose file, a domain (or a tunnel), and you're running your own automation hub — payable in crypto with no KYC, live in minutes.
Around 2 GB is the comfortable sweet spot for n8n plus its Postgres database and normal workflows. It runs in 1 GB if workflows are light, but you'll feel it during bigger runs. Heavy parallel executions or large payloads — go to 4 GB.
It's by far the easiest way — one compose file gives you n8n, a database and persistent storage, and upgrades are a single pull. You can install via npm instead, but Docker saves you the dependency and upgrade headaches.
If you run a steady stream of automations, yes — a flat monthly VPS beats per-execution pricing, and there's no workflow or execution cap. For a handful of runs a month, a hosted seat may be simpler. The other reason people self-host is control: your data and API keys never leave your server.
For OAuth-based nodes (Google, etc.) and clean HTTPS, yes — point a domain at the server and put n8n behind a reverse proxy with a certificate. For purely internal use you can reach it over an SSH tunnel without a domain.
Internal/SSH-tunnel use works on a NAT box. If you want a public URL with your own domain and HTTPS (needed for some OAuth callbacks and webhooks), a dedicated-IP plan is the cleaner fit since you control all ports.
Originally published at eqvps.com.