n8n Cloud vs Self-Hosted: The Real Cost Comparison

Last Updated on October 5, 2026 by Elizabeth Sramek

Every n8n cloud vs self-hosted thread converges on the same claim within four replies: self-hosting is free. The licence is free, the container is free, the VPS is twenty euros. Then an execution table quietly grows to fill a 50GB disk and the instance stops accepting webhooks on a Saturday afternoon.

The gap between licence cost and total cost is the whole decision, and almost nobody prices it. Servers are cheap and predictable. Attention is expensive and lumpy. A self-hosted instance costs you almost nothing for eleven months and then eats a weekend.

This post does three things the ranking comparisons do not: it states the licence terms accurately rather than repeating “open source” as if that settles anything, it puts an hourly rate on the maintenance burden and totals it, and it gives you a crossover table instead of “it depends on your needs”.

What each option costs, and the one-line rule

n8n Cloud costs a fixed monthly fee tied to an execution allowance, starting at EUR 20 per month; self-hosted n8n costs nothing in licence fees for internal business use but typically lands somewhere between EUR 80 and EUR 150 per month in infrastructure once you run Postgres, Redis and real backups, plus whatever your team’s time is worth.

The one-line rule: if you cannot name the specific person who gets paged when the instance goes down, and that person is not the only one who understands it, buy Cloud. Everything below is the argument for why that single question outranks execution volume, data residency and cost per run.

The licence question: what the Sustainable Use License actually permits

n8n is not open source under the OSI definition; it is source-available under the Sustainable Use License, which grants a royalty-free licence to use, copy, distribute and modify the software subject to two limitations that matter commercially. This is the single most misunderstood fact in the n8n cloud vs self-hosted debate, and it is the one with legal consequences rather than operational ones.

The licence text limits you to using or modifying the software “for your own internal business purposes or for non-commercial or personal use”, and permits distribution or provision to others only “free of charge for non-commercial purposes”. You may not alter, remove or obscure licensing and copyright notices. The licence terminates automatically on breach, with a 30-day cure window after notification.

Read that first clause carefully. Running n8n on your own servers to automate your own company’s operations is squarely inside it. Running n8n and charging third parties for access to it is not.

Which features are Enterprise-licensed rather than community

A second licence sits on top: source files with “.ee.” in the filename or “.ee” in the directory name are excluded from the Sustainable Use License and require a valid n8n Enterprise licence, per LICENSE_EE.md in the same repository. The code ships in the same container you download, but running it without a licence key is a licence breach, not a clever hack.

Per n8n’s community edition features page, the free Community edition includes almost the complete feature set. Registering with an email address unlocks folders, debug in editor and custom execution data at no cost. The following need a paid licence key on a self-hosted instance:

• SSO via SAML and LDAP
• Git-based version control and environments
• Projects, and sharing of workflows and credentials
• External secret stores and external storage for binary data
• Log streaming, custom variables and multi-main mode

That list is the quiet cost of self-hosting for a team of more than about four people. Credential sharing and Git-backed workflows are not luxuries once several engineers touch the same instance, and our walkthrough of n8n version control covers what changes when you have them. Self-hosting to avoid a subscription and then paying for a licence key to get SSO is a legitimate outcome, just not the free one people expect.

Agencies and consultancies: read the terms, do not assume

If you run workflows on behalf of paying clients, the “own internal business purposes” wording is the clause you need a real answer on, not a forum opinion. Building an automation for a client on the client’s own instance looks different from hosting a shared instance where you sell your clients access to n8n, and the second is the pattern the licence exists to restrict.

n8n Cloud pricing, and why an execution is not an operation

n8n Cloud sells execution allowances rather than task or operation counts, which is the structural difference from Zapier and Make and the reason its pricing is hard to compare directly. n8n’s own pricing page defines an execution as “a single run of your entire workflow. It doesn’t matter how many steps are in the workflow or how much data it processes. It’s still a single execution.”

Plan	Price	Executions/month	Concurrency	Projects	Notable inclusions
Starter	EUR 20/mo	2,500	5	1	Unlimited users, forum support
Pro	EUR 50/mo	10,000	20	3	Admin roles, global variables, workflow history
Business	EUR 667/mo	40,000	30	6	SSO/SAML/LDAP, environments, Git version control, self-hosted option
Enterprise	Custom	Custom	200+	Unlimited	External secret store, log streaming, 365-day insights, SLA support

The counting model matters enormously and it is where n8n beats its competitors on unit economics. A 30-node workflow that enriches a lead, checks three APIs, branches twice and writes to two systems is one execution on n8n. On a per-operation platform the same run bills dozens of operations. If your workflows are wide, n8n Cloud is cheap; if you run thousands of trivial two-step automations, the per-execution model works against you. Our Zapier vs Make vs n8n comparison works through what that means at different workflow shapes.

One consequence people miss: sub-workflows called from a parent count as their own executions in most configurations, so a heavily modularised build inflates the number faster than the workflow count suggests. Measure your real execution volume in the trial before choosing a tier.

The true cost of self-hosting n8n: a worked example

Self-hosting costs infrastructure plus attention, and the attention line is usually three to five times the infrastructure line. The table below is a worked example with stated assumptions, not a quote or a measurement: replace every number with your own provider pricing and your own loaded hourly cost.

Assumptions: a production instance in queue mode serving a 15-person company, roughly 25 active workflows, hosted on a mainstream European VPS provider, with an ops engineer whose fully loaded cost is EUR 60 per hour. Backups are off-site and tested. Monitoring is a hosted uptime and log service rather than a self-built Prometheus stack, because a self-built stack adds hours, not saves them.

Line item	Assumption	EUR/month
Application server	4 vCPU / 8 GB VPS running main instance and webhook process	40
PostgreSQL	Managed Postgres, small tier, daily snapshots	25
Redis	Small managed Redis for the Bull queue	15
Worker node	2 vCPU / 4 GB VPS running one worker process	20
Off-site backups	Object storage plus retention for DB dumps and the encryption key	8
Domain and TLS	Domain amortised monthly; certificates via Let’s Encrypt	2
Monitoring and alerting	Uptime checks, log retention, on-call notification	20
Infrastructure subtotal		130
Routine attention	3 hours/month: upgrades, disk checks, credential fixes, at EUR 60/hr	180
Steady-state total		310
Incident month	Add 6 hours for one upgrade rollback or disk-full recovery	+360

Steady state lands near EUR 310 per month against EUR 50 for Cloud Pro at 10,000 executions. That is the number the “self-hosting is free” argument leaves out, and it is why the crossover point sits much higher than most teams assume. If you want to model this properly against your own labour rates, our automation TCO calculator handles the arithmetic.

Three hours a month is optimistic for a first year and generous for a mature instance. The honest version is that maintenance is bimodal: near zero for months, then a full day when an upgrade breaks something.

Single instance or queue mode: the architecture decision

A single n8n container with SQLite is fine for evaluation and wrong for production; queue mode with Postgres, Redis and separate worker processes is what you run once workflows matter. The difference is that in the default regular mode, the main process executes workflows itself, so one slow HTTP node blocks the editor, the webhook listener and every other run.

SQLite hurts specifically under write concurrency. Execution data is written continuously, and a busy instance produces lock contention, then slow queries, then timeouts on the executions list. Start on Postgres. Migrating later is possible but it is a maintenance window you did not need to spend.

Move to queue mode when any of these are true: more than a handful of concurrent executions, any long-running workflow that must not block others, a need to restart n8n without dropping in-flight runs, or webhook endpoints that must stay responsive during heavy processing. Per the queue mode documentation, you set EXECUTIONS_MODE=queue, point every process at the same Redis, and start workers with n8n worker.

# docker-compose fragment: n8n in queue mode
# Pin an exact image tag. Never :latest on a production instance.

x-n8n-env: &n8n-env
  DB_TYPE: postgresdb
  DB_POSTGRESDB_HOST: postgres
  DB_POSTGRESDB_DATABASE: n8n
  DB_POSTGRESDB_USER: n8n
  DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
  EXECUTIONS_MODE: queue
  QUEUE_BULL_REDIS_HOST: redis
  QUEUE_BULL_REDIS_PORT: 6379
  # Must be identical on main, workers and webhook processes
  N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
  N8N_HOST: n8n.example.com
  N8N_PROTOCOL: https
  WEBHOOK_URL: https://n8n.example.com/
  N8N_GRACEFUL_SHUTDOWN_TIMEOUT: 30
  # Pruning: defaults are prune=true, max age 336h, max count 10000
  EXECUTIONS_DATA_PRUNE: "true"
  EXECUTIONS_DATA_MAX_AGE: 168
  EXECUTIONS_DATA_PRUNE_MAX_COUNT: 20000
  EXECUTIONS_DATA_SAVE_ON_SUCCESS: none
  EXECUTIONS_DATA_SAVE_ON_ERROR: all

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine

  n8n-main:
    image: n8nio/n8n:PINNED_TAG
    environment: *n8n-env
    ports:
      - "5678:5678"
    depends_on: [postgres, redis]

  n8n-worker:
    image: n8nio/n8n:PINNED_TAG
    command: worker --concurrency=5
    environment: *n8n-env
    depends_on: [n8n-main]

volumes:
  pgdata:

Note what those pruning variables do. n8n’s executions environment variables document defaults of EXECUTIONS_DATA_PRUNE=true, EXECUTIONS_DATA_MAX_AGE=336 hours and EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000. Those defaults are sane, but two weeks of full execution payloads on a webhook-heavy instance is still a lot of rows, and every workflow that pushes large JSON through the pipeline stores that JSON.

n8n cloud vs self-hosted: the crossover table

The crossover is driven by team shape first and volume second, because the infrastructure cost scales slowly while the attention cost is a step function that starts the moment you take responsibility for uptime. The table below is a decision matrix, not a range of opinions.

Profile	Executions/month	Who maintains it	Choose	Why
Solo operator or two-person team	Under 2,500	Nobody, in practice	Cloud Starter	Your time is the scarcest input and a broken instance stops revenue work
Marketing or RevOps team, no engineer	2,500 to 10,000	Nobody with root access	Cloud Pro	Self-hosting without an owner produces an orphaned instance nobody dares upgrade
Startup with a platform or DevOps engineer	10,000 to 50,000	Existing on-call rotation	Self-hosted, queue mode	Marginal cost of one more service on an existing rotation is genuinely low
Any team with hard data-residency or network isolation rules	Any	Compliance-mandated ops function	Self-hosted	The requirement is categorical; cost is not the deciding variable
Agency running client workflows	Any	Delivery team	Check the licence first, then decide	Licence terms constrain the model before economics do
Enterprise, 100k+ executions, SSO and audit required	100,000+	Dedicated platform team	Self-hosted with an Enterprise licence key	You need the .ee features anyway; the only question is where they run

The pattern worth noticing: unlimited execution volume only becomes the deciding factor at the top band. Below roughly 40,000 executions a month, the Cloud tiers cost less than the labour of running the thing yourself, and the argument for self-hosting has to come from somewhere other than the invoice.

What self-hosting genuinely buys you, and what is rationalisation

Four of the standard justifications are real and two are usually stories people tell to justify a decision already made. The real ones are data residency, internal network access, arbitrary npm packages in Code nodes, and control of version pinning.

Data residency is real when it is contractual. If your DPA forbids customer records transiting a third-party processor, no amount of encryption in transit fixes that, and self-hosting is the only answer. It is a rationalisation when nobody has actually read the contract and “we do not want our data on someone else’s servers” is a feeling rather than a clause.

Internal network access is the strongest technical argument. Reaching a Postgres replica, an on-prem ERP or an internal-only API from Cloud means exposing it or building a tunnel. An instance inside your VPC just connects. If half your integration targets are behind a firewall, the decision is made for you, and that is the case for a large share of enterprise integration work.

Arbitrary npm packages via NODE_FUNCTION_ALLOW_EXTERNAL are real but narrower than people think. Most Code node work needs no dependencies. Version pinning is real and underrated: on self-hosted you upgrade when you have tested, not when the vendor ships.

Unlimited execution volume is the one that flips from rationalisation to reason at scale. Below the Business tier it saves you less than it costs. Above it, at hundreds of thousands of runs, the economics invert hard and self-hosting wins outright. “It is cheaper” is a rationalisation at 5,000 executions a month and a fact at 500,000.

Failure modes of self-hosted n8n, and how each one presents

Self-hosted n8n fails in a small number of highly repeatable ways, and every one of them is preventable with configuration you can apply in an afternoon. These are the ones that generate the 2am pages.

Failure mode	Symptom	Prevention
Execution database fills the disk	Editor hangs, new executions fail to start, Postgres refuses writes, webhooks return 500	Tune EXECUTIONS_DATA_MAX_AGE and PRUNE_MAX_COUNT, set SAVE_ON_SUCCESS to none on high-volume flows, alert at 70 percent disk
Webhook URLs break behind the reverse proxy	Registered URL shows localhost:5678 or http instead of https; external services get connection errors	Set WEBHOOK_URL, N8N_HOST and N8N_PROTOCOL explicitly; forward X-Forwarded-Proto in the proxy config
Upgrade breaks pinned community nodes	Workflows referencing a community node show as unrecognised after restart and stop firing silently	Pin the image tag, keep a staging instance, read release notes for breaking node changes before pulling
Secrets live in environment variables with no rotation	No symptom until an incident, then no way to tell what a leaked key had access to	Rotate on a schedule, use an external secret store where licensed, keep credential scope minimal
Encryption key not backed up	After a restore, every stored credential is unreadable and must be re-entered by hand	Back up N8N_ENCRYPTION_KEY separately from the database, in a password manager, before anything else
No staging instance	Every upgrade is tested in production, so every regression is an outage	Run a second small instance on the same version; upgrade it first; keep workflows in Git

The unpruned execution database is the most common cause of a self-hosted instance falling over, and it is entirely silent until the disk is full. The secrets one is the most expensive when it goes wrong; our ops guide to rotating API keys covers doing that without breaking live workflows, and the broader guide to automation failure modes covers the ones that are not n8n-specific.

Migrating between n8n Cloud and self-hosted

Workflow JSON transfers cleanly in both directions; credentials and execution history do not. That asymmetry is the whole migration story, and the detail people discover too late is the encryption key.

Credentials are stored encrypted with an instance-specific key. Export a credential from one instance and it is decryptable only where that key exists. Moving from Cloud to self-hosted means re-entering every credential and re-authorising every OAuth connection by hand. Budget an hour per twenty credentials and do it before you cut traffic over, not during.

Execution history does not migrate at all. If you need audit evidence of past runs, export what you need to your warehouse before you decommission the old instance. Nobody misses execution history until an auditor asks for a specific run from four months ago.

A workable order of operations: stand up the new instance and pin the version, back up the encryption key immediately, import workflows from Git rather than clipboard, recreate credentials, run every workflow manually in a disabled state, then repoint webhooks last because that is the irreversible step. If you are coming from a different platform entirely, our guide to replacing Zapier with self-hosted n8n walks the same sequence from a Zapier starting point.

Going the other way, Cloud to self-hosted and back again, is easier in the sense that Cloud runs the same product. The friction is identical: workflows move, secrets do not.

Verdict by team profile

Self-host if you have an existing on-call rotation, a compliance requirement, or volume above the Business tier; buy Cloud in every other case, and stop treating that as a defeat.

If you are a small ops team with no dedicated engineer, self-hosting is the wrong choice regardless of how comfortable you are with Docker. The container is not the hard part. The hard part is the Tuesday eight months from now when Postgres needs a major version upgrade and the person who set it up has left.

If you already run production infrastructure with monitoring, backups and an alerting rotation, self-host without hesitation. n8n is one more service on a platform you already operate, the marginal attention cost is small, and you get network access and version control that Cloud cannot give you.

If you are an agency, resolve the licence question before the architecture question. If you have a residency clause in a signed contract, self-host and price the labour into the deal rather than pretending it is free.

And if you are self-hosting mainly because a subscription feels like a tax, run the arithmetic in the worked example above with your own hourly rate. For most teams under 40,000 executions a month, EUR 50 buys back more engineering time than it costs.

Frequently asked questions