n8n’s self-hosting story is one of its biggest selling points and one of its most quietly expensive features. The Docker image runs in five minutes. Keeping it running for two years without losing a workflow takes more thought. Here is how we decide whether to self-host on a given project.
The case for self-hosting
The economics are real. Once your automation usage crosses a few thousand executions a day, Zapier and Make get expensive fast, and even n8n Cloud’s higher tiers start to add up. A self-hosted instance on a small VM can run hundreds of thousands of executions a month for the cost of dinner.
Beyond cost, there are workloads that only work self-hosted. Anything touching customer data that cannot leave your infrastructure. Anything calling internal services on a private network. Anything with custom code in nodes that goes beyond what the cloud sandbox allows. For all of these, self-hosting is not optional.
The case against
Self-hosting is not free. Someone owns updates - and n8n updates often. Someone owns the database, the backups, the queue worker scaling, the credential encryption keys. Someone gets paged when the workflow that runs payroll silently stops because the host ran out of disk last Tuesday.
For a team without anyone comfortable doing basic ops, n8n Cloud is almost always the right call. The premium you pay for managed hosting is much smaller than the cost of one bad outage on a critical workflow.
What the production setup actually looks like
When self-hosting makes sense, here is roughly what we ship:
- n8n in queue mode (separate worker processes), not the all-in-one default. This is the difference between a hobby setup and one that survives long-running flows.
- A managed Postgres database, not the embedded SQLite. Backups configured, point-in-time recovery on, the database actually restored once before going live.
- A real secrets strategy. The encryption key is stored outside the container, rotated on a schedule, and not the default value from a tutorial.
- Monitoring on workflow failures and queue depth, with alerts going somewhere a human will see them.
- A staging instance with a copy of the workflows for testing changes before they touch production.
None of this is exotic. All of it is skipped by 80% of self-hosted setups we are asked to take over.
The honest middle path
For many clients, the right answer is: start on n8n Cloud, prove the workflows are valuable and stable, then move to self-hosted when the bill or the data-residency story demands it. Migration is not free, but doing it once with a proven set of workflows is much cheaper than running production-grade ops while you are still figuring out what to automate.
How we help
We design and run automation stacks for clients across all three tiers - cloud, self-hosted, and hybrid - and we are happy to take over the operational side of an n8n deployment that has outgrown its origins as a side project. If your automation footprint is reaching the point where the platform decision actually matters, that is a good moment to talk before the costs (in cash or downtime) compound.
Tags