The argument for self hosting n8n always starts the same way: the community edition is free, a small VPS is cheap, so why pay for n8n Cloud? That arithmetic is correct about the licence and wrong about everything that comes after it.
I run n8n both ways on client work. Self-hosted when data legally cannot leave a customer's own cloud, or when workflows depend on custom nodes and long-running jobs. Cloud when a small team simply needs automations that stay up. The decision is almost never about the server bill.
What does self hosting n8n actually cost?
The licence is zero and the infrastructure is modest. The real cost is the recurring engineering time to keep a stateful service, its database, its queue and its upgrade path healthy, and that cost does not shrink as your workflows grow.
The cost lines people budget for, and the ones they discover in month three.
| Line item | Budgeted? | What it actually involves |
|---|---|---|
| n8n licence | Yes | Community edition is free. Business and Enterprise self-hosting need a paid key. |
| Compute | Yes | One VPS runs a small instance. Queue mode needs a main process plus worker processes. |
| PostgreSQL | Sometimes | Managed Postgres or a container you now own. SQLite works for toys only. |
| Redis | Rarely | Required as the broker the moment you enable queue mode. |
| Object storage | Rarely | S3-compatible storage for binary data, which queue mode needs instead of the filesystem. |
| Backups and restore drills | Rarely | Encrypted credentials plus execution history. An untested backup is not a backup. |
| Upgrades | Almost never | Version pinning, breaking node changes, migration windows, rollback plan. |
| On-call | Almost never | Someone is paged when the webhook endpoint dies at 02:00 and orders stop flowing. |
Add those last three rows honestly. If a senior engineer spends even a few hours a month on patching, restore tests and a bad upgrade, the loaded cost of that time usually exceeds a mid-tier Cloud plan long before the infrastructure bill does.
Is self-hosted n8n really cheaper than n8n Cloud?
Below serious volume, no. Self-hosting becomes cheaper when execution counts get large enough that per-execution pricing dominates, because your own server bill does not move each time a workflow fires while a metered plan does.
n8n Cloud is structured around workflow executions rather than per-step or per-user billing, with tiers that raise your monthly execution allowance and concurrency ceiling. Prices move, so read n8n's official pricing page for current numbers rather than trusting any blog post, including this one.
The structural point matters more than the number. Cloud pricing scales with how often your workflows run. Self-hosted cost scales with how much operational surface you are willing to own. Those two curves cross, and the crossing point is much further right than most teams assume. If you are still choosing a platform at all, my n8n vs Zapier vs Make comparison covers that layer first.
"Self-hosting is not a discount. It is a trade of a predictable invoice for unpredictable engineering hours."
When do you need queue mode, Redis and PostgreSQL?
You need queue mode as soon as one n8n process can no longer absorb your concurrency, or as soon as a single crash losing in-flight executions is unacceptable. n8n's deployment docs describe queue mode as a main instance that enqueues executions and separate worker processes that run them, with Redis as the broker.
What flipping EXECUTIONS_MODE to queue actually commits you to, per n8n's hosting documentation.
- PostgreSQL as the database. n8n's docs recommend Postgres 13+ and advise against running queue mode on SQLite.
- Redis as the message broker, reachable from the main instance and every worker.
- At least one separate worker process, started with the n8n worker command, that you now monitor.
- S3-compatible external storage for binary data, because filesystem binary storage is unsupported in queue mode.
- A webhook processing decision: keep webhooks on the main instance or run dedicated webhook processes.
That is four stateful dependencies where you previously had one container. It is entirely doable, and it is exactly the kind of work I do on data engineering engagements, but it is not the weekend project the free licence implies.
There is also a licensing edge here. n8n's docs mark the in-app worker monitoring view and multi-main high-availability setups as self-hosted Enterprise features. You can run queue mode without them, but you will be reading logs and metrics from outside n8n rather than from its UI.
n8n Cloud vs self-hosted by team size
The right answer changes with how many engineers you can spare, not with how many workflows you have. Use this as a first-pass decision matrix.
How I advise teams to choose, by size and constraint.
| Team | Default choice | Why | What would change it |
|---|---|---|---|
| Solo founder / 1 engineer | n8n Cloud | Every hour on infrastructure is an hour not on the product. | A contract that forbids third-party processing of customer data. |
| 2 to 10 people, no ops function | n8n Cloud | No one owns backups, and nobody wants the 02:00 page. | Execution volume growing fast enough to outrun the tier ladder. |
| 10 to 50, one platform engineer | Self-hosted, single instance | You already run Postgres and containers. n8n is one more service. | Concurrency spikes that force queue mode sooner than planned. |
| 50+, real platform team | Self-hosted, queue mode | Volume justifies workers, and you can absorb upgrades properly. | Compliance needs pushing you to a paid licence for SSO and RBAC anyway. |
| Regulated (health, finance, gov) | Self-hosted from day one | Data residency and audit requirements outrank convenience. | Nothing. Budget for the licence and the ops time up front. |
What do you give up when self hosting n8n?
The community edition is a complete automation engine, not a complete enterprise product. What you lose is governance, and governance is the thing security reviews ask about.
The gaps that surface once more than a handful of people touch the instance.
- Single sign-on. SAML and LDAP sit behind a paid n8n licence key, so the free instance means local accounts and manual offboarding.
- Granular role-based access control, so everyone with access can see and edit credentials for production systems.
- Git-backed environments and promotion between dev and prod, which you otherwise rebuild with export scripts.
- Log streaming to your SIEM, which auditors ask for and which you will otherwise scrape from container logs.
- Vendor-side uptime. Your webhook endpoint is now your responsibility, including TLS renewal and DNS.
n8n moves features between tiers over time, so treat that list as the shape of the gap rather than a fixed spec, and confirm against the current pricing page. The pattern is stable even when the details shift: execution power is free, governance is paid.
What does keeping self-hosted n8n alive look like?
It looks like owning a small stateful production service. Here is the loop I put in place on every self-hosted n8n build before a single client workflow goes live.
The operating routine that makes self-hosting survivable.
- 1Pin the n8n image to an explicit version tag. Never deploy from latest, because node behaviour changes between minor releases.
- 2Set N8N_ENCRYPTION_KEY explicitly and store it in your secrets manager. Lose it and every stored credential becomes unreadable.
- 3Back up PostgreSQL on a schedule, and restore into a scratch environment at least quarterly to prove the backup works.
- 4Prune execution data aggressively. Unbounded execution history is the most common reason a self-hosted instance slows to a crawl.
- 5Stage upgrades: read the release notes, deploy to a staging instance, run your five highest-value workflows, then promote.
- 6Alert on the webhook endpoint from outside your own network, plus queue depth and worker liveness once you are in queue mode.
- 7Keep an exported copy of every production workflow in git, so a bad restore is an inconvenience rather than an outage.
None of this is exotic. It is the same discipline behind the distributed web scraping platform I run at 100K+ jobs a day. The point is that it is real work, and it does not appear anywhere in the free-versus-paid comparison people make on day one.
Who should not self-host n8n?
If nobody on your team can name who gets paged when the instance goes down, you should not self-host. That single question filters out most teams that ask me about it.
Stay on Cloud if any of these describe you.
- Your automations are revenue-critical but you have no on-call rotation.
- You are still learning the tool. Start with the n8n beginner tutorial on Cloud, then move once you know your real volume.
- Your workflows are mostly SaaS-to-SaaS calls with no data residency constraint.
- Your compliance team will demand SSO within six months, which means a paid licence either way.
- The motivation is purely to avoid a subscription. That saving evaporates the first time an upgrade breaks a node.
How I decide on client builds
I default to Cloud and treat self hosting n8n as something a specific constraint forces on the build. Three constraints qualify: data that cannot leave a jurisdiction or VPC, custom nodes or long-running executions that Cloud limits will not tolerate, and execution volume high enough that per-execution pricing dominates.
On the Indonesia livestock operations dashboard the data pipeline sat next to the database for latency and residency reasons, so self-hosting the orchestration layer alongside it was the obvious call. On lighter builds where n8n is glue between APIs, paying for Cloud and spending the saved hours on the actual product wins every time.
If you want the decision made with your numbers rather than a generic table, that is the first hour of any AI automation engagement I run, and the n8n integration page covers how I build and hand over these systems either way.
Key takeaways
- The n8n community edition is free to license but not free to operate; the recurring cost is engineering time, not hosting.
- Queue mode requires PostgreSQL, Redis, separate worker processes and S3-compatible binary storage, per n8n's deployment documentation.
- Governance features such as SAML SSO, RBAC and git-backed environments sit behind a paid n8n licence key.
- Cloud pricing scales with executions; self-hosted cost scales with operational surface, and the crossover point sits at high volume.
- Self-host for data residency, custom nodes or heavy volume, and stay on Cloud when the only motive is avoiding a subscription.
- If no one can name who gets paged at 02:00, the team is not ready to self-host.
Frequently asked questions
- Is n8n free if I self-host it?
- Yes, the n8n community edition is free to download and run under n8n's Sustainable Use Licence. It is not open source in the OSI sense, and it excludes paid features like SAML SSO and role-based access control. Free covers the licence only; you still pay for compute, PostgreSQL, backups and the engineering time to maintain it.
- How much does self hosting n8n cost per month?
- The licence is zero for the community edition, and a single small VPS with managed PostgreSQL is inexpensive. The dominant cost is engineering hours for upgrades, backup restore drills and on-call. Price your own loaded hourly rate against the Cloud tier you would otherwise buy, then check n8n's pricing page for current plan figures.
- What is the difference between n8n Cloud and self-hosted n8n?
- n8n Cloud is a managed instance where n8n handles uptime, upgrades and scaling, billed by workflow executions. Self-hosted n8n runs on your infrastructure, so you control data residency, custom nodes and execution limits, and you own PostgreSQL, Redis, backups and patching. Feature availability also differs, since some governance features need a paid licence key.
- Do I need Redis to self-host n8n?
- Not for a basic single-instance deployment. You need Redis once you enable queue mode, where n8n's docs describe Redis as the message broker between the main instance and worker processes. Queue mode also requires PostgreSQL rather than SQLite, and S3-compatible external storage for binary data instead of the filesystem.
- Does self-hosted n8n support SSO?
- Not in the free community edition. SAML and LDAP single sign-on are licensed features that require a paid n8n plan key, even when you run the software on your own servers. If your security review mandates SSO, budget for the licence rather than assuming self-hosting removes the subscription entirely. Check n8n's current pricing page for tier details.
- Can I migrate from n8n Cloud to self-hosted later?
- Yes. Workflows export as JSON and import into any instance, so the workflow layer moves cleanly. Credentials do not export in usable form because they are encrypted with an instance-specific key, so plan to re-enter them. Execution history generally does not migrate, which is another reason to start on Cloud and move when a constraint appears.
- Is self hosting n8n worth it for a small team?
- Usually not. For teams under roughly ten people with no dedicated ops function, the saved subscription rarely covers the hours spent on upgrades, restore testing and incident response. Self-hosting becomes worth it when data residency rules, custom node requirements or high execution volume make Cloud genuinely unworkable rather than merely more expensive.
- How many executions can a single self-hosted n8n instance handle?
- It depends on workflow complexity, not a fixed number, because a heavy AI workflow consumes far more CPU and memory than a webhook-to-Slack relay. The practical signal is concurrency: when executions start queueing behind each other or timing out, move to queue mode with dedicated workers rather than buying a bigger single server.
Sources
Written by Syed Husnain Haider Bukhari
AI engineer, data scientist, and founder of Revolutionary Technologies LLC. Ships production AI agents, automations, and data platforms for teams in the US, UK, and UAE — including AgentFlow, AI Walay, and ProLeads.
Get in touch →Related pages
Want this built instead of researched?
Book a 30-minute scoping call. You get a one-page plan and a fixed-scope quote within 48 hours.
Start a conversation