JH← Back to blog

Self-Hosting n8n in Production: What Actually Breaks

The Docker setup, queue mode, credential and encryption-key handling, upgrade pitfalls, and monitoring gaps you'll hit running n8n in production — and how to get ahead of them.


Most n8n self-hosting guides stop at docker run. Production is where it gets interesting — restarts that wipe state, queue mode that isn't obvious to configure, upgrades that silently break credentials. This is the version I wanted before I shipped it.

Cloud vs self-host — the actual decision

n8n Cloud is the right call until one of three things becomes true: the bill at your execution volume crosses what a small VPS costs, you need data residency or to keep sensitive data on your own infrastructure, or you need custom community nodes and full control. Those are the wins. What you're signing up for in return is ops burden — you now own backups, upgrades, uptime, and security. The break-even is less about price than about whether you have the appetite to run it. If you don't, stay on Cloud.

Docker setup that survives restarts

The default footgun: run n8n in a container without persistence and a restart wipes your workflows and credentials. The essentials:

  • Named volumes / a bind-mounted data directory so workflows, credentials, and execution data survive container recreation.
  • A real database — SQLite is fine to start, but Postgres is the production choice for concurrency and reliable backups.
  • N8N_ENCRYPTION_KEY set explicitly. This is the most important variable in the whole setup: it encrypts your stored credentials. If n8n generates one for you and you lose it (e.g. by not persisting it), every saved credential becomes undecryptable. Set it yourself, store it in your secret manager, and treat it like a master key.
  • Health checks so your orchestrator restarts a wedged instance.

Queue mode and workers

The default "main" mode runs everything in one process, which falls over under concurrent executions or long-running workflows. Queue mode fixes this by separating the main instance from worker processes, coordinated through Redis.

The pieces: set the execution mode to queue, add Redis, run one or more dedicated worker containers, and understand that webhooks still need to reach the main instance (webhook routing is the gotcha people miss when they scale out workers). Move to queue mode before you actually need it — diagnosing capacity problems in main mode under load is no fun.

Credentials and secrets handling

Beyond the encryption key: you can't easily rotate N8N_ENCRYPTION_KEY once credentials are encrypted with it, so get it right and back it up from day one. For sensitive secrets, prefer injecting them via environment variables or a secrets manager rather than storing everything inside n8n. And be aware that execution data can capture sensitive values in logs — review what your workflows log, and prune execution history so you're not retaining secrets in plaintext indefinitely.

Backups and version upgrades that bite

  • Back up the database and the encryption key together — one without the other is useless. A credential backup you can't decrypt isn't a backup.
  • Test upgrades in staging first. n8n moves quickly and breaking changes aren't always loud; a node's behaviour or a workflow's assumptions can shift between versions.
  • Pin a version and upgrade deliberately rather than always tracking latest in production. Read the release notes for breaking changes before you bump.

Monitoring

The built-in execution log is fine for debugging a single workflow and poor as a monitoring system. Watch, at minimum: execution failure rate, queue depth (in queue mode), and worker health. Wire failures to external alerting — a Slack/email notification on workflow failure, plus uptime monitoring on the instance — so you find out a critical automation broke from your alerts, not from a customer.

FAQ

What's the one thing I must not lose? N8N_ENCRYPTION_KEY. Lose it and every stored credential is unrecoverable. Set it explicitly and back it up with your database.

When do I need queue mode? Once you have concurrent executions or long-running workflows that overwhelm a single process. Set it up before you hit the wall, not after.

SQLite or Postgres for production? Postgres. SQLite is fine for trying n8n out, but Postgres handles concurrency and backups properly.