Self-hosting n8n in production: the four things that break
n8n on a single container is a demo. Running it for a company means queue mode, a real database, a plan for credentials and a restore you have tested. Here is the shape that survives.
Almost every n8n installation we are asked to look at started the same way: someone ran the Docker image on a spare VM, built three workflows that saved the team an afternoon a week, and then twenty more people found out. Six months later it is holding invoice processing together and nobody knows where the credentials live.
The tool is fine. The single container is the problem. Here is what changes when an automation platform stops being a side project.
1. Queue mode, or one slow workflow stops everything
By default n8n runs everything in one process. A workflow that waits ninety seconds on a slow API is ninety seconds during which your webhooks queue behind it, and a node that leaks memory takes the editor down with it.
Queue mode splits this into a main instance that serves the UI and webhooks, a Redis queue, and worker processes that execute. Set EXECUTIONS_MODE=queue, point QUEUE_BULL_REDIS_HOST at a managed Redis, and run two or more workers. The first consequence is that you can scale workers independently of the editor. The second, less obvious one, is that a worker crash no longer logs everyone out.
Give workers a concurrency limit that matches what your downstream APIs tolerate, not what the CPU allows. Most incidents we see in n8n are not n8n failing; they are n8n succeeding thirty times a second against an API that rate-limits at five.
2. Postgres, and the executions table that eats the disk
SQLite is the default and it is the wrong default for anything shared. Move to Postgres before you have data you care about, because the migration is an export and re-import of credentials that nobody enjoys.
Then set the pruning variables. EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE_MAX_COUNT exist because the execution log stores the full payload of every node run, and a workflow that moves documents will store those documents. We have seen a 400 GB executions table in a company whose actual business data was under two gigabytes. Keep fourteen to thirty days, and set EXECUTIONS_DATA_SAVE_ON_SUCCESS=none for the high-volume workflows where you only care about failures.
3. Credentials are the crown jewels, and they are encrypted with one key
n8n encrypts stored credentials with N8N_ENCRYPTION_KEY. If that key is generated on first boot and lives only in the container's volume, your backup is useless without it, and your disaster recovery plan is a fiction.
Set the key explicitly from your secrets manager, the same way you would a database password. Then treat the instance as a production system with access to every SaaS account in the company, because that is exactly what it is: a single n8n instance in a mid-sized company typically holds tokens for the CRM, the email provider, the accounting system, the data warehouse and a cloud account. A compromise of the editor is a compromise of all of them, which is why the editor should never be on the public internet without SSO in front of it, and why the blast radius of what an agent can touch deserves a design session of its own.
4. Workflows are code, and they are not in git
The editor is a database, and that means no diffs, no review, no rollback. The fix is boring: export workflows to JSON, commit them, and promote between a staging and a production instance rather than editing production live.
n8n's source control feature does this natively on the paid tiers; on the community edition, a scheduled workflow that calls the internal API, writes the JSON to a repo and opens a pull request gets you eighty percent of it in an afternoon. Either way, the rule that matters is cultural, not technical: production is not an editor.
What it costs to run properly
A production-shaped install is a main instance and two workers, roughly 2 vCPU and 4 GB between them for most workloads, a small managed Postgres and a small managed Redis. On AWS or Azure that lands around 120 to 200 euros a month, and it replaces a Zapier or Make bill that in the same company is usually three to ten times that once the task volume is real. The trade is that the 150 euros of infrastructure comes with the operational load of a service you now own — upgrades, backups, an on-call path.
That is the decision, not the feature list. We wrote out the comparison in n8n, Make or Zapier.
What to do this week
Find your n8n instance — there is one, and it is probably on somebody's VM. Check three things: whether N8N_ENCRYPTION_KEY is set explicitly, how large the execution_entity table is, and who can reach the editor. Those three answers usually turn a comfortable conversation into a project.