Self-hosting n8n: when it is worth the trouble
Running your own n8n gives you data control and predictable costs, and hands you uptime, upgrades and backups. A straight look at both sides.
Self-hosting n8n is genuinely the right call for a lot of the companies we work with, and genuinely the wrong one for others. The deciding factor is rarely technical ability. It is whether anyone will own the thing after launch.
The case for running it yourself
Three arguments carry real weight.
- Data residency — customer records never leave infrastructure you control, which resolves most compliance conversations before they start
- Cost shape — you pay for a server, not per execution, so a workflow that fires ten thousand times a day costs the same as one that fires ten times
- No ceiling — execution time, payload size and concurrency are yours to configure rather than tiers to buy
The cost argument is the one people underestimate. High-frequency workflows on usage-priced platforms get expensive in a way that is hard to predict in advance, and impossible to reverse quickly once you depend on them.
The case against
You are now running a production service. That means upgrades, certificate renewals, database backups you have actually tested restoring, and someone who notices when it stops.
The failure we see most often is not a server falling over. It is an n8n instance that was set up by someone who has since left, running a version two years old, with credentials nobody can rotate because nobody knows what would break.
What a sane setup looks like
- Postgres as the database, never the default SQLite, for anything beyond experimenting
- Queue mode with separate worker processes once you are running meaningful volume
- Automated encrypted backups of both the database and the encryption key — the key alone makes credentials recoverable
- A reverse proxy handling TLS, with the editor behind authentication and ideally not on the public internet
- Workflows exported to version control, so a broken change can be reverted like any other
- A staging instance, because testing a workflow change in production is testing it on your customers
A reasonable middle path
Start on n8n Cloud. Build the workflows, prove they earn their keep, and find out what your real execution volume is. Move to self-hosted when either the bill or a compliance requirement makes the case for you.
Self-host when you have a reason. Migrating later is a weekend; guessing wrong at the start costs months.
Either way, keep workflows in version control from day one. It is the decision that makes every subsequent decision reversible.