Every team that adopts n8n hits the same fork within the first month: run it yourself, or pay for n8n Cloud. And almost every guide answering that question is quietly selling you something — the “self-host n8n” tutorials want you on their referral-linked VPS; the “why Cloud” posts are written by people who profit from Cloud.
I build both. I set up self-hosted n8n for clients who need it, and I tell other clients to stay on Cloud when that’s the honest answer. So here’s the version with no side to sell.
The real question isn’t “which is better”
Both run the identical n8n engine. Your workflows are portable either way — the JSON exports from one import straight into the other. So this isn’t a features decision. It’s a decision about who owns the operational burden and what your constraints actually are.
When n8n Cloud is the right call
- Nobody on your team wants to own infrastructure — and you’d rather it stayed that way.
- Your execution volume is modest and predictable.
- You need to start this week without provisioning anything.
- Compliance doesn’t require you to physically control where the data lives.
Cloud’s trade: you swap some control and per-execution cost for never thinking about servers. For a lot of teams, that’s a great deal.
When self-hosted wins
- Compliance / data control. HIPAA, GDPR data residency, or an internal policy that says the data can’t leave infrastructure you own. (More on that in my HIPAA self-hosted guide.)
- Cost at scale. Per-execution pricing is cheap at low volume and stings at high volume. A $5–20/month VPS comfortably runs tens of thousands of executions. (Here’s the Hetzner math.)
- Control. Custom nodes, your own environment variables, queue mode with workers, integrations that live behind your firewall.
The hidden cost nobody quotes you
Self-hosting isn’t “one docker-compose and you’re done.” The day you self-host, you own: uptime, encrypted backups you’ve actually tested restoring, SSL renewal, n8n version upgrades that don’t break your workflows, OS security patches, and the 3 AM page when the disk fills. That’s real, recurring work — and it’s the part that bites months later, not on day one.
Cloud has a hidden cost too: pricing that quietly climbs with volume, less visibility into the runtime, and you’re at the mercy of someone else’s incident response when it goes down.
A rough cost crossover
On paper, self-hosting wins on cost fast — a small VPS runs for the price of a couple of coffees while Cloud bills per execution. But “cheap” isn’t free. If you’d spend three hours a month babysitting the server, multiply that by what your time is worth and add it to the VPS bill. Below a few thousand executions a month, Cloud’s convenience usually wins. Above tens of thousands — or the moment compliance enters the picture — self-hosting pulls ahead even after the ops time.
The decision, in four questions
- Does compliance or data control require you to hold the data? → Self-host.
- Do you have someone who will genuinely own backups, updates, and uptime? → If no, Cloud (or self-host with managed help).
- Is your volume high enough that per-execution pricing hurts? → Self-host.
- Do you need to be live this week with zero setup? → Cloud.
The honest middle path
Start on Cloud to prove the workflows actually deliver value. Move to self-hosted once scale or compliance forces the issue — because your workflows export and re-import cleanly, that switch is low-risk and not a rebuild. Or self-host from day one, but don’t carry the ops yourself.
If Cloud fits, use Cloud — there’s no shame in not running infrastructure. If you self-host, the part that bites isn’t the install, it’s the production layer: tested backups, monitoring that pages you before your customers do, and upgrades that don’t break. That’s exactly what a one-time Self-Hosted Setup handles, and what Managed Hosting keeps running after. Either way — pick the option that matches your constraints, not the one a tutorial is trying to sell you.