Self-Hosted n8n vs n8n Cloud: Cost, Control, and When Each Wins

Pick n8n Cloud when nobody will patch, back up, and restore the box. Self-host when residency, a private network, fixed egress, or volume-plus-ops capacity makes the vendor instance the wrong place. Queue mode is a third decision — a concurrency topology — not a hosting brand.

Spurlock Studios runs both. Across 500+ automations the production spine does not change with the host: idempotency, parked failures, schema checks, named owners. Hosting is a constraint fit. The written spine lives in the Production n8n handbook. n8n’s own split is the same two-step: Cloud or self-hosted, then plan or edition — see Choose how to use n8n.

The short answer

• Choose n8n Cloud when you want less ops, a faster first production webhook, and legal will accept a SaaS workflow host. Deploy docs call this the managed path.
• Choose self-hosted when you need network placement, data residency you control, custom proxying, or cost that still works after you pay a human to own the box. Host n8n is the install map.
• Choose queue mode later, and usually only on self-hosted, when a single process is drowning. That switch is n8n queue mode, not this page’s hosting pick.
• Do not self-host because it feels more “pro” if nobody will patch it.

Cloud, self-host, or queue — which decision is this?

Three questions get mashed into one Slack thread. Separate them or you will buy Redis to solve a compliance problem, or buy Cloud to solve a concurrency problem Cloud Starter cannot.

Decision	Options	What it actually chooses
Who runs the instance?	n8n Cloud vs self-hosted	Ops burden, data location, egress IPs, upgrade owner
Which plan or edition?	Cloud Starter / Pro / Enterprise, or Community / Registered Community / Business / Enterprise	Features, execution quotas, concurrency, SSO, support
Regular vs queue?	One process vs EXECUTIONS_MODE=queue	How executions fan across workers — see enable queue mode

n8n’s comparison table is blunt: Cloud wins on install and maintenance; self-hosted wins on control and customization; both support production. Production is discipline. Hosting is where the rail lives.

Queue mode is included on self-hosted Community. Multi-main high availability is not — that is a paid edition feature per Compare editions. On Cloud, queue mode is an Enterprise conversation; you contact n8n to enable it. If your only reason to leave Cloud is “we need workers,” price that Enterprise ask against a self-hosted queue before you assume a VPS is cheaper.

What does n8n Cloud actually buy you?

Cloud buys an instance n8n runs for you. Use n8n Cloud is the admin surface: trial, dashboard, version pin, concurrency, workflow export.

You are buying:

1. No Docker, TLS, or database install on day one.
2. Vendor-owned patching and uptime ops.
3. A published concurrency cap per plan, with overflow queued FIFO for production executions.
4. A dashboard path to pick version and update cadence — Update your version documents security-and-stability versus every-new-release, plus a maintenance window.

Cloud fact (as of August 2026)	Source	What it means in production
Free trial, then Starter / Pro / Enterprise	Choose how to use n8n	Start here if the first webhook must ship this week
Concurrency is plan-capped; extras queue FIFO	Understand concurrency	A burst does not fork more processes; it waits
Manual, sub-workflow, and error runs sit outside that cap	Same page	Load tests that only click Execute lie about production headroom
Source IPs change without warning	Find your IP addresses	Vendor allowlists that demand one NAT IP often force self-host
Hosted-plan data location stated as EU / Frankfurt	Pricing FAQ	Confirm on the current page and DPA — regions move

Cloud is not “less production.” It is production with a landlord. You still owe idempotency, a dead-letter path, and an owner who reads the error workflow.

Cloud is the wrong default when legal already said payloads cannot leave your network, or when the systems you call are not internet-reachable without a bridge you control.

When does self-hosted n8n win?

Self-host when two or more are true:

1. Contracts or residency rules require the database and execution logs on infrastructure you name.
2. n8n must sit on a private network next to internal APIs.
3. Execution volume makes Cloud tiers uncomfortable and someone already owns Linux, Postgres, and on-call.
4. You need reverse-proxy, mTLS, or egress control beyond Cloud knobs — especially a stable outbound IP.
5. You need Community queue workers without waiting on a Cloud Enterprise enablement.

Host n8n lists install paths: one-line setup, Docker Compose, npm (deprecated in n8n 3.0 — do not start a new production box on npm), plus cloud-provider guides. For anything that must survive a reboot, n8n points at Compose plus a real database, not docker run with SQLite in the container filesystem. The Docker Compose guide is explicit: SQLite is fine for trying things; production that runs around the clock should swap in Postgres.

Community edition is free, indefinitely, for almost the full editor. It is not OSI “open source.” n8n licenses the product under the Sustainable Use License: internal business use and consulting are allowed; white-labeling n8n or charging people to access a hosted editor is not, unless you have a separate commercial agreement. If you are an agency building client workflows, you are in the allowed bucket. If you are productizing n8n as the product, email license@n8n.io before you invoice.

Paid self-hosted features (SSO, environments, external secrets, Git version control, multi-main) need a Business or Enterprise license key. Registering Community is free and unlocks folders, debug-in-editor, and custom execution data — Compare editions.

What does self-hosted cost once you count labor?

Do not compare only subscription stickers. As of August 2026, n8n’s public pricing page listed these Cloud figures on annual billing. They move. Recheck the page before you put a number in a board deck.

Plan (Cloud, annual billing, Aug 2026 listing)	Listed price	Listed executions	Listed concurrency
Starter	€20 / month	2,500	5
Pro	€50 / month	10,000	20
Business (listed as self-hosted license)	€667 / month	40,000	Scaling options on the page
Enterprise	Contact sales	Custom	200+ on the comparison table

n8n bills a full workflow run, not each node. A 40-node graph is one execution. That is the useful comparison to Zapier-style task math — still confirm the current definition on the pricing FAQ.

Cloud TCO: subscription + design time + the limits you work around (concurrency queue, saved-execution retention, IP churn).
Self-hosted TCO: compute + disk + Postgres + backups + observability + upgrade labor + idle knowledge (“only Jamie knows how it runs”) + the hours you will spend the first time Redis or TLS expires.

A $0 VPS with an abandoned n8n is not cheap. It is a future incident.

Revisit cost quarterly against peak month executions, not a quiet week. A daily cron is ~30 runs. A five-minute cron is ~8,600–8,900. n8n’s own pricing FAQ uses those examples — use them, then multiply by the workflows that actually fire.

Self-hosted Community has no execution sticker. The meter is CPU, disk, and the human. If that human is a founder doing nights-and-weekends sysadmin, price those hours at what they would bill, not at zero.

A useful back-of-napkin: take last month’s execution count, multiply by three, and put that number next to the current Cloud tier on pricing. If 3× still fits Pro and you have no residency constraint, stay. If 3× forces Enterprise math and you already pay a platform person, model self-hosted. If 3× forces Enterprise math and you do not have that person, you are not “saving” by standing up Redis.

Do the same napkin for concurrency, not just monthly totals. Five parallel webhooks on Starter is a different problem than 2,400 polite cron runs.

Is queue mode a reason to leave Cloud?

Usually no. Queue mode solves concurrency drowning a single Node process. It does not move your data into a VPC. It does not give you a static NAT. It does not replace idempotency.

From n8n’s enable queue mode docs:

1. Main handles timers and webhooks and creates an execution.
2. The execution ID goes to Redis (Bull).
3. A worker loads the workflow from the database and runs it.
4. The worker writes results; Redis notifies main.

Topology	When it is the right next step	What you now own
Regular (one process)	Low concurrency; Cloud Starter/Pro caps are enough	Almost nothing extra
Cloud concurrency queue	You are on Cloud and bursting past plan concurrency	Wait time, not more workers — concurrency docs
Self-hosted queue mode	UI freezes, webhook latency climbs, CPU pegged after you already set a concurrency limit	Redis, Postgres, shared N8N_ENCRYPTION_KEY, worker health, version pin across nodes
Cloud Enterprise queue	You want workers without running Redis yourself	An Enterprise commercial conversation
Multi-main	You need HA on the editor/API tier	Self-hosted Enterprise; sticky sessions; Postgres + Redis

SQLite plus queue mode is not a production pair. n8n says so on the queue page. Binary data in filesystem mode is also unsupported in queue mode; they point at S3-compatible external storage.

Every main, worker, and webhook processor must share the same encryption key or credentials in the database are unreadable. Set N8N_ENCRYPTION_KEY explicitly — custom encryption key. Losing that key is a credential-restore failure, not a “we still have the SQL dump” success.

If the symptoms are concurrency, read n8n queue mode before you rewrite hosting. If the symptoms are residency or allowlists, queue mode will not help.

Webhook processors are an optional extra layer on self-hosted queue: they take inbound HTTP so the main process can stay on the editor. n8n tells you not to put main in the webhook load-balancer pool. Paths that matter: /webhook/* and /webhook-waiting/* to the processor pool; /webhook-test/* and the editor API to main. Large “Respond to Webhook” bodies travel worker → Redis → main; oversized payloads fail unless you offload binary storage. That is a queue-mode problem, not a Cloud-vs-VPS problem.

What does a Cloud concurrency cap do to a webhook burst?

Cloud regular mode does not grow workers when you get a Shopify or Stripe storm. It queues production executions FIFO once you hit the plan cap — Understand concurrency. Manual clicks, sub-workflows, and error workflows do not count against that cap. That is why a “it felt fine when I pressed Execute” test is a lie.

Burst behavior	What you see	Wrong fix	Right fix
Five concurrent on Starter, twenty on Pro (Aug 2026 listing)	Later webhooks wait	“We must self-host tonight”	Upgrade plan, or shed load, or move only the hot path
Provider retries while you are queued	Duplicate deliveries	Raise retries on the vendor	Idempotency keys; park duplicates
You cancel a queued run	It leaves the queue; you cannot retry that ID	Re-fire from the vendor blindly	Know which events are safe to replay
Instance restart	Queued work resumes up to the cap	Assume the queue survived in your head	Check the executions tab after a Cloud version change

Self-hosted regular mode has the same shape if you set N8N_CONCURRENCY_PRODUCTION_LIMIT: overflow waits inside one process. Queue mode is how you add capacity, not how you change the landlord.

If Cloud queue time is the pain and legal is fine with SaaS, buy the next Cloud tier or ask about Cloud Enterprise workers. If Cloud queue time is the pain and you already need a VPC, then self-host + queue is one project, not two slogans.

Which database do you actually get?

Choose n8n’s database is the source, not hallway lore.

Install	Default database (docs as of 2026)	Production note
Self-hosted, unset	SQLite at ~/.n8n/database.sqlite	Fine for a laptop; not the restore story you want for money paths
Self-hosted, DB_TYPE=postgresdb	PostgreSQL	Required direction for queue mode and any box you will restore
n8n Cloud Starter / Pro / legacy Enterprise	SQLite	Cloud still abstracts backup ops; you do not SSH the file
n8n Cloud Enterprise Scaling	PostgreSQL	The tier that matches “we need a real DB” on the vendor side

Supported Postgres majors, as of July 2026 on that page: 17 and 18, plus 16 for compatibility. The range shifts every November with upstream. Do not tattoo a version from a 2024 blog post onto a new cluster.

n8n does not officially support Aurora, AlloyDB, Cockroach, or Yugabyte. If platform wants a compatible fork, that is an accepted risk, not a documented configuration.

Self-hosted Postgres checklist:

• DB_TYPE=postgresdb and credentials from a secret manager or _FILE mounts — basic configuration
• Automated backups and a restore you have actually run
• Disk alerts on the volume that holds Postgres and binary data
• TLS to the database if it is not on localhost
• Permissions that let n8n create and migrate its own schema

Cloud buyers still need an execution-retention policy. Pricing lists saved-execution caps and day windows per plan. Hitting the cap does not stop workflows; it deletes old history. That is a compliance answer, not just a debug inconvenience.

What is the minimum self-hosted ops bar?

If any box is unchecked, stay on Cloud or hire platform help before you migrate. Keep n8n running is the vendor index for logs, metrics, and updates.

• Postgres (not SQLite) with automated backups and a restore tested into a scratch instance
• TLS certificates that auto-renew
• Container or host updates on a calendar
• n8n version pin — no :latest on production
• Disk, memory, and (if queued) Redis alerts
• SMTP or another outbound path for invites and alerts
• Admin 2FA; SSO if your edition includes it
• Secrets via env or secret manager, not a .env committed to git
• Offsite export of workflows (CLI export is not a substitute for DB backups, and not a substitute for credentials)
• Named primary owner and a backup human who can restore
• N8N_ENCRYPTION_KEY stored in the same secret system as the DB password

“docker run on a VPS” is a science fair project until this list exists.

Upgrade procedure that does not ruin Monday:

1. Read the changelog for breaking changes.
2. Upgrade staging first, same pin you will use in production.
3. Hit one webhook verify, one idempotent write, one error-workflow path.
4. Then production, during a window you chose.
5. Keep the previous image digest so you can roll back.

Cloud owners still pick a cadence in the dashboard. Self-hosted owners who skip staging are volunteering for a surprise major.

Monitoring that is not a vibe check:

• /healthz on main; on workers enable QUEUE_HEALTH_CHECK_ACTIVE so /healthz and /healthz/readiness exist
• Disk watermark on Postgres and on whatever holds binary data
• Execution age: oldest waiting production run, not just “is the UI up”
• Certificate expiry with more than seven days of warning
• A page that fires when n8n is up and the downstream write is not (silent-success)

Keep n8n running points at logs, Prometheus-style metrics, Grafana, and OpenTelemetry. Pick one export path. A container that is “healthy” while workflows have been queued for forty minutes is a green lie.

Why do Cloud IPs and allowlists force self-host?

This is the constraint that has decided self-hosted for several of our clients. n8n’s Cloud IP page is not subtle: addresses change without warning. They publish a list and tell you to use strong auth anyway, because the list is not a contract.

Egress need	Cloud	Self-hosted
Vendor allowlists one NAT /32	Fragile; list churn	Your NAT, your ticket to change it
Private RFC1918 APIs	Needs a bridge or expose	Place n8n on the same network
mTLS to an internal gateway	Limited to vendor knobs	Your reverse proxy, your certs
Admin UI not on the public internet	Vendor hostname	VPN / SSO / private ALB; only /webhook/* public

Common self-hosted layouts:

• Public webhook receiver + private worker (queue mode).
• VPN to the editor; only webhook paths on the load balancer.
• Egress through a fixed NAT for bank, EHR, or warehouse allowlists.

If the only “security” requirement is “we prefer not to use SaaS,” that is a feeling. If the requirement is “the general ledger API accepts one IP we issued last year,” that is a hosting decision.

How do you answer legal about where data lives?

When legal asks “where does data live?”:

Question	n8n Cloud	Self-hosted
Region	Vendor statement on pricing (EU / Frankfurt as of August 2026 for hosted plans) plus the current DPA	The cloud region you picked, including replicas
Subprocessors	Vendor list; you do not get to swap the hypervisor	Your cloud, your backup vendor, your Redis host
Who can open executions	n8n operators + your users	Your IAM + whoever has DB credentials
Encryption at rest	Vendor controls	Your volume keys + N8N_ENCRYPTION_KEY for credentials
Retention	Plan caps on saved executions and days	EXECUTIONS_DATA_* and your backup TTL

Also answer what is in the executions. PII sitting in node output for 30 days can matter more than which logo is on the container. Pair hosting with the retention rules in the handbook.

Self-hosted is not automatically “more secure.” A patched Cloud instance with 2FA beats a public :5678 on a VPS with yesterday’s n8n and a password in Discord. Self-hosted can be tighter when you need private networking and you operate it.

License is a legal question too. Internal automation is in bounds. Reselling the editor is not. Get that in writing if procurement is nervous about fair-code.

Who is allowed to own the box?

Skill	Cloud	Self-hosted regular	Self-hosted queue
Workflow design	Required	Required	Required
Production spine	Required	Required	Required
Linux / containers	Optional	Required	Required
Postgres backup / restore	Optional	Required	Required
Redis	No	No	Required
Networking / TLS	Optional	Required	Required
On-call for the platform	Light (vendor + you for workflows)	You	You, with more moving parts

Do not assign self-hosted ownership to a marketer who happens to be brave. Bravery is not a restore strategy.

Cloud still needs a workflow owner: who gets the error, who rotates credentials, who approves a breaking node upgrade. That person is cheaper to staff than a platform engineer. That is the Cloud pitch.

If the only candidate for self-host ops is a freelancer who will be gone in six weeks, you are buying a museum piece. Stay on Cloud or put ownership in a role that survives the contract.

How do you migrate Cloud to self-hosted (or back)?

Treat it as a production change, not a weekend hobby. n8n documents export/import on the CLI; Cloud also has download workflows from the admin docs set. Credentials do not travel as a chat paste.

Procedure:

1. Inventory active workflows, webhook URLs, and credential names.
2. Stand up the target with the ops bar above (or a Cloud workspace on the reverse path).
3. Export workflows; import; map credentials fresh.
4. Rebuild webhook URLs. Update every provider. Old Cloud hostnames will keep receiving events until you cut them.
5. Replay-test idempotency and the error workflow in the new place.
6. Shadow or dual-run critical paths for a short window.
7. Cut DNS / provider endpoints. Keep the old side ready to flip back for 72 hours.
8. Only then decommission.

Migration landmine	What it looks like	Fix
Copied secrets through Slack	Credential leak + half-mapped nodes	Secret manager; rotate after cutover
Hard-coded Cloud webhook URLs	Silent miss on the new host	Env-specific webhook base; search the graph
SQLite file copied as “the backup”	Queue mode or a second replica will not love you	Dump/restore Postgres; test it
Encryption key not moved	Workers cannot decrypt credentials	Same N8N_ENCRYPTION_KEY everywhere
Providers still pointing at Cloud	Duplicate side effects	Cutover checklist per vendor

Portable design (named credentials, documented webhook bases, no hostnames in Function nodes) is what makes this boring. Design for it on day one even if you start on Cloud.

When does a hybrid Cloud + self-host setup make sense?

Common and sane:

• Cloud for marketing and ops experiments that touch public SaaS only.
• Self-hosted for finance-adjacent, health, or internal-only systems.
• Export/import workflows; environment-specific credentials; never one shared OAuth client across both.

Pattern	Use it when	Kill it when
Cloud lab + self-hosted prod	You want speed to first draft without opening the VPC	The lab starts writing to production CRMs
Two self-hosted envs (staging / prod)	You upgrade like software	Staging is a forgotten box with real credentials
Cloud now, self-host later	Timeline is this week; residency is a 2027 problem	You never scheduled the revisit

Avoid two unmanaged environments with the same workflow names and nobody sure which is live. Label the editor, the webhook host, and the runbook. “n8n” is not a unique identifier.

Hybrid doubles ops. That is fine if two owners exist. It is how teams get a Cloud invoice and a dead VPS.

What fails when you “save money” on a neglected VPS?

The failure mode is not theoretical architecture. It is a Tuesday.

What breaks: disk fills with execution data; Let’s Encrypt fails; the host kernel is two CVEs behind; Redis was added “temporarily” on the same box and nobody documented the password; the only person who knew N8N_ENCRYPTION_KEY left.

What it costs: missed webhooks while the container is down; duplicate side effects when providers retry into a half-upgraded instance; a restore that cannot decrypt credentials; a security questionnaire you can no longer answer honestly.

What you do instead:

1. Stay on Cloud until the ops bar is staffed.
2. Or pay for managed hosting / an internal platform team that already runs Postgres.
3. If you already self-host and have skipped two restore drills, treat that as an incident and move — Cloud or a real platform — before the disk fills.

Pride is not an availability strategy. Choose the mode you can operate.

Signals to move back to Cloud (or to managed help) after you already self-host:

• Repeated missed upgrades or a pin that is six months behind current stable
• Single owner burnout; the backup human has never SSHed in
• Restore drills skipped twice
• Security questionnaire answers getting thinner, not sharper
• Redis or Postgres added “temporarily” on the same VM with no runbook

That is not a moral failure. It is a capacity signal. Cloud exists so the workflow owner can stop being the platform.

Restore drill (quarterly, or you do not have backups):

1. Spin an ephemeral instance.
2. Restore the database.
3. Confirm workflows load.
4. Confirm the credential re-inject process works with the same encryption key.
5. Tear down. Record time-to-restore in the incident plan.

Decision worksheet

Copy this into the next architecture review. Answer in writing.

1. Data residency requirement? (yes / no / specify region)
2. Private-network dependencies?
3. Do vendors require a static egress IP?
4. Peak executions / month now, and at 3×
5. Peak concurrent production executions (not manual clicks)
6. Platform hours available per month
7. Incident-response owner and backup
8. Budget preference: subscription vs labor
9. Timeline to first production webhook
10. License fit: internal use only, or are you productizing n8n?
11. Do you need queue workers this quarter, or is that a slide?

Scoring we actually use:

• If (1), (2), or (3) is yes → bias self-hosted.
• If (6) is near zero → bias Cloud.
• If (4) or (5) is huge and (6) is solid → model Cloud Pro / Enterprise and self-hosted TCO against pricing.
• If (11) is yes and you are on Cloud → ask about Cloud Enterprise queue, or plan self-hosted queue as a scale project, not a hosting conversion.
• If (9) is this week → Cloud, put a 90-day revisit on the calendar with execution counts and ops hours.
• If (10) is “we resell the editor” → stop and read the Sustainable Use License before you write a proposal.

Spurlock default: n8n Cloud for speed and clean ops, unless residency, network, or scale economics say otherwise. We implement the same spine on either. Hosting is not a personality test.

Write the answers down. A hosting debate that cannot fill this worksheet is not ready for a migration ticket. Re-run the sheet ninety days after go-live with real execution counts and the hours you actually spent on the platform — not the hours you hoped you would spend.

FAQ

n8n Cloud vs self-hosted — which is better?

Neither universally. Cloud wins on ops convenience and time-to-first-webhook. Self-hosted wins on control, residency, fixed egress, and some high-volume cost shapes — if a named owner will patch and restore it. Pick from constraints, not from which option sounds more serious.

Is n8n Cloud worth it for a small team?

Usually yes, if SaaS subprocessors and the published Cloud region are acceptable. Small teams rarely win by running their own automation platform on nights and weekends. As of August 2026, Starter and Pro were the listed Cloud ramps; confirm current prices and execution caps on n8n pricing.

Is self-hosted more secure?

Not automatically. A patched, monitored Cloud instance can beat a neglected VM with an open editor port. Self-hosted can be tighter when you need private networking, your own keys, and you actually operate backups, upgrades, and access control.

Can I start on Cloud and move later?

Yes. Many teams do. Design workflows with named credentials, a documented webhook base, and no hard-coded Cloud hostnames so the cutover is a URL and credential remap — not a rewrite. Treat the move as a production change: shadow, then flip, then keep rollback for a few days.

What about execution limits?

Cloud plans cap executions, saved history, and concurrency; extras queue or age out of logs depending on which cap you hit. Self-hosted Community has no execution sticker — limits are hardware, database, and (if you enable it) queue-mode worker capacity. Model peak month, not a quiet week.

Who should own self-hosted n8n?

A platform or devops owner with a backup human who has run the restore drill. “The freelancer who set it up” is not an ownership model. Cloud still needs a workflow owner; it does not need that person to also be on-call for Postgres.

CTA

Buy convenience until constraints force control — then earn that control with real ops.

If you want a hosting recommendation for your volume and compliance posture, read the handbook, then use automation or book a call.