n8n Cloud vs Self-Hosted
Same tool, two different jobs. One rents you the infrastructure; the other hands it to you.
The short answer
Stay on n8n Cloud until execution volume, data residency or a custom node forces the move; self-hosting wins on cost at scale, but you take on upgrades, queue mode and backups yourself.
Most teams who think they need to leave n8n entirely actually need to self-host the n8n they already have. The complaints that send people shopping for alternatives are almost always about the Cloud tier, not the tool.
Side by side
| Dimension | n8n Cloud | Self-hosted |
|---|---|---|
| Who runs the server | n8n does. You get a URL and log in. | You do. A container, a database, and someone who owns it. |
| Pricing model | Per workflow execution, tiered by plan. | Your own infrastructure cost, whatever that runs on. |
| Code node on custom logic | Only crypto and moment are available as imports. | Any npm module you choose to install. |
| Data residency | Data passes through n8n's hosting. | Stays inside infrastructure you control. |
| Upgrades | Handled for you, on their schedule. | You choose the version and the timing, and you test it first. |
| Scaling past one instance | Handled behind the scenes. | Needs queue mode: Redis as the broker plus separate worker processes. |
| Backups and recovery | Included in the plan. | Your responsibility, including testing that a restore actually works. |
n8n Cloud
Strengths
- Running in minutes, with no server to provision.
- Upgrades and backups happen without you scheduling them.
- Predictable place to start while a workflow is still small.
Trade-offs
- Execution-based billing rewards a few large workflows and penalises many small, frequent ones.
- The code node cannot import external npm packages, so custom logic hits a wall the self-hosted version does not have.
- Data passes through n8n's hosting rather than staying on infrastructure you control.
Self-hosted
Strengths
- No per-execution ceiling. Cost scales with your own infrastructure, not with how often a workflow fires.
- The code node can import any package your workflow needs.
- Data never leaves infrastructure you already trust.
- You choose when to upgrade, rather than inheriting a change on n8n's schedule.
Trade-offs
- SQLite is the default database, but n8n does not recommend it for queue mode, so a real deployment means Postgres from the start.
- Scaling past one instance means standing up Redis and separate worker processes.
- Backups, monitoring and version upgrades are now your team's job, not a vendor's.
- Debugging a failed run in a long workflow is already slow in n8n, and now there is no support ticket to open.
How to choose
Ask what is actually forcing the conversation. Most of the time it is execution cost, not a technical limit. That argues for self-hosting the same workflows, not rebuilding them somewhere else.
- 01Choose Cloud if the workflow is new, small, or still being shaped. You want to be changing the logic, not running a server.
- 02Choose self-hosted if execution volume makes per-task pricing painful, or a workflow needs an npm package the Cloud code node blocks.
- 03Choose self-hosted if the workflow touches data that has to stay inside your own infrastructure.
- 04Choose neither yet if nobody on the team owns Postgres, Redis or a container in production. Get that answered before you migrate.
What the migration actually involves
Moving off Cloud is not a rebuild. Each workflow exports as JSON and imports straight into a self-hosted instance. Credentials do not travel with it, so those get re-entered by hand once on the new install. Code nodes carry over untouched, since the logic is ordinary JavaScript either way.
The work is standing up the platform underneath, not moving the automations. That means a Postgres database from day one, since n8n does not recommend SQLite once queue mode is involved. It also means environment variables, webhook URLs and every scheduled trigger repointed at the new host before the old one is switched off.
Run both instances in parallel for a short window rather than cutting over in one step. Point one non-critical workflow at the self-hosted instance first, confirm executions, credentials and error notifications all behave the same, then move the rest.
01Can I move a workflow from Cloud to self-hosted later?
Yes. Workflows export as JSON, and the logic inside code nodes is ordinary JavaScript, so both port over cleanly. The visual layout does not carry across, so expect to redo the wiring on the canvas, not the thinking behind it.
02What does self-hosting n8n actually cost in effort?
A container, a Postgres database, and someone who owns upgrades. SQLite ships as the default, but n8n does not recommend it once you run queue mode, so a real deployment starts with Postgres. Scaling past one instance adds Redis and separate worker processes. That ongoing ownership, not a licence fee, is what leaving Cloud actually costs.
03Does self-hosting mean n8n is fully open source?
No. n8n ships under the Sustainable Use License, a fair-code licence rather than an OSI-approved one. You can self-host and modify it for internal use freely, but you cannot resell it as a competing hosted service.
04What happens to credentials when I migrate?
They do not travel with the workflow export. Credentials are stored separately for security. Each connection has to be re-entered by hand on the self-hosted instance before a migrated workflow can run there.
05Can I run n8n Cloud and a self-hosted instance at the same time?
Yes, and doing so briefly during a migration is the safer path. Point one low-risk workflow at the new instance and confirm it behaves the same under real load. Then move the rest, instead of cutting over all at once.
Read next
- n8n, reviewed from production use →What it is good at, and where it is weak, from a workflow we run for a client.
- n8n alternatives →The tools people reach for when they think Cloud is the problem, and why self-hosting is usually the real fix.
- Best n8n automation agencies →Who to hire once you know which deployment you need.
- Little Tree: meeting to action with n8n →A production n8n system, self-hosted, running a bakery's meeting-to-task pipeline.
