DEV Community

Dmitry Chervonyi
Dmitry Chervonyi

Posted on • Originally published at livemy.app

Self-hosting n8n in 2026: three paths, the env vars that matter, and 5 things that quietly break

n8n Cloud Starter is $24/month for 2,500 executions. Pro is $60/month for 10,000. Self-hosted Community Edition has unlimited executions and costs whatever your server costs.

That math is why most people end up here. This is the setup, the environment variables that actually matter, and the five things that quietly break a self-hosted n8n once real workflows run through it.

Why self-host

Three reasons, in the order people usually hit them:

Execution caps. The moment your workflows fire more than a couple thousand times a month, Cloud pricing stops being cute. Self-hosted has no cap.

Data sovereignty. Customer data flowing through your workflows touches your server, not someone else's. Relevant if you handle PII or anything with GDPR / HIPAA / SOC 2 implications.

Cost at scale. A $3–20/month server replaces $24–800/month of Cloud. Most teams save $200–700/year once workflow count grows past a handful.

Three ways to self-host it

Path A: Docker Compose on a VPS

The path n8n's own docs walk. Spin up a VPS (Hetzner, DigitalOcean, Vultr — $5–10/month), install Docker, write a docker-compose.yml running n8n plus Postgres, set env vars, put nginx in front as a reverse proxy, wire up automated certificate renewal, point DNS at the box.

Good: cheapest possible. Full control. Cleanest ownership story.

Catch: you are now the DevOps team. Backups, security patches, n8n version bumps, cert renewal, nginx config, Postgres maintenance. Realistic time to first deploy if you have never done it: 2–6 hours, plus ongoing upkeep.

Pick it if you are comfortable in Docker and Linux and the time cost is fine.

Path B: Managed Docker host (Coolify, Dokploy, CapRover)

Same VPS, but with a UI handling Docker, reverse proxy, certs and backups. Coolify and Dokploy both ship n8n as a one-click template: install Coolify on the VPS, click Deploy n8n, paste a domain, done.

Good: self-hosted economics without hand-writing Compose files.

Catch: still your VPS, still your responsibility to patch the host OS. Coolify itself needs updates.

Pick it if you want the savings but not the YAML.

Path C: a managed host that runs the container for you

Push the n8n image at a platform that handles certs, database provisioning, backups and patching. You trade a few dollars a month for not owning any of it.

Disclosure so you can weigh the rest properly: I co-founded livemy.app, which is one of these, so I am biased. Render and Railway are the other reasonable picks in this shape. Railway is worth a caveat for n8n specifically: it bills usage, and a cron workflow firing hourly bills compute around the clock.

Pick it if you would rather pay to skip the DevOps entirely.

The environment variables everyone gets wrong

Whatever path you take, four variables decide whether your instance actually works:

N8N_HOST=n8n.yourdomain.com
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.yourdomain.com/
GENERIC_TIMEZONE=Europe/Berlin
Enter fullscreen mode Exit fullscreen mode

Plus one that decides whether you can ever restore a backup:

N8N_ENCRYPTION_KEY=<32-char random string you write down somewhere safe>
Enter fullscreen mode Exit fullscreen mode

If you move to a custom domain later, update N8N_HOST and WEBHOOK_URL and redeploy. Webhooks stay broken until those match the public URL.

Five things that quietly break self-hosted n8n

1. WEBHOOK_URL does not match the public URL

The most common one by far. n8n generates webhook URLs from WEBHOOK_URL, not from whatever you typed in the browser. If it still says http://localhost:5678 while your instance lives at https://n8n.yourdomain.com, every webhook you register at Stripe, Calendly or anywhere else points at nothing.

Fix. Set it to the full public URL with a trailing slash. Redeploy. Test one webhook end to end before trusting any of them.

2. SQLite is the default and it is not a production database

n8n defaults to SQLite. Fine for personal use, breaks the moment you have concurrent executions, because SQLite locks the whole file on write. Two workflows firing at once gives you lock errors.

Fix. Use Postgres:

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=...
DB_POSTGRESDB_DATABASE=...
DB_POSTGRESDB_USER=...
DB_POSTGRESDB_PASSWORD=...
Enter fullscreen mode Exit fullscreen mode

3. Credentials are encrypted with a key you can lose

n8n encrypts stored credentials with N8N_ENCRYPTION_KEY. Do not set it and n8n generates one into the data folder. Restore that backup onto a different server without the same key and every credential is unreadable. You will not find out until you need the restore.

Fix. Set it explicitly. Store it somewhere that is not the server.

4. Cron nodes fire in UTC

Without GENERIC_TIMEZONE, "every weekday at 9 AM" means 9 AM UTC. Set a valid IANA timezone and redeploy.

5. Free tiers and always-on automation do not mix

n8n runs crons that need to fire reliably. Hosts whose free tier sleeps on inactivity silently miss cron slots, and you find out from the workflow that did not run. Render Free spins down after 15 minutes of inactivity, for example.

Fix. Run production automations on a tier that stays awake. This is worth the few dollars regardless of which host you pick.

The cost math

For a typical small team:

  • n8n Cloud Starter: $24/month, 2,500 executions. A team automating daily can burn that in a week.
  • n8n Cloud Pro: $60/month, 10,000 executions. Still capped.
  • Self-hosted, $5 VPS: $5/month plus your time.
  • Self-hosted, managed host: roughly $10–15/month all in, unlimited executions, no DevOps.

Once you cross a few thousand executions a month, self-hosting wins even if you pay for managed convenience.

Migrating off n8n Cloud

Export workflows from Cloud (settings → export), stand up the self-hosted instance, import, re-enter credentials. Budget a few hours for a small team's worth of automations. Credentials do not export, by design.

The honest summary

If you are under ~2,500 executions a month and do not care where the data sits, n8n Cloud Starter is genuinely simpler and you should use it. Past that, self-host. Path A if you enjoy servers, Path B if you want the savings without the YAML, Path C if you would rather not think about it at all.

Whichever you pick: set WEBHOOK_URL correctly, use Postgres, and write down your encryption key. That is most of the pain avoided.


What broke first on your self-hosted n8n? I am collecting these, and I suspect WEBHOOK_URL wins by a mile.

Top comments (0)