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.
n8n Cloud vs self-hosted: the short answer
Should you self host n8n? Only if a hard constraint forces it: data residency, custom nodes, long-running jobs or execution volume that outgrows the Cloud tiers. Everything else favours Cloud. Plan figures below are from n8n's pricing page as of October 2026, listed in euros and billed annually.
n8n Cloud vs self-hosted n8n at a glance (verify current figures on n8n.io/pricing).
| n8n Cloud (Starter / Pro) | Self-hosted Community | Self-hosted Business | |
|---|---|---|---|
| Licence price | €20 / €50 per month | Free (Sustainable Use Licence) | €667 per month |
| Included executions | 2.5K / 10K per month | Not metered | 40K per month |
| Who runs servers, backups, upgrades | n8n | You | You |
| Queue mode with workers | Managed for you | Yes, with PostgreSQL + Redis | Yes |
| SSO (SAML/LDAP), log streaming, Git environments | No | No | Partly; log streaming is Enterprise only |
| /metrics endpoint for Prometheus | No | Yes | Yes |
| Best fit | Small teams with no ops function | Engineering teams with residency or volume needs | Self-hosted teams that need sharing and projects |
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 | Queue mode cannot store binary data on the filesystem, and n8n lists S3 external storage as a paid feature, not part of the community edition. |
| Backups and restore drills | Rarely | Encrypted credentials plus execution history. An untested backup is not a backup. |
| Upgrades | Almost never | n8n's docs recommend updating at least monthly: release notes, staging test, 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 bills by workflow executions rather than per step or per user. As of October 2026, n8n's pricing page lists Starter at €20 a month for 2.5K executions and Pro at €50 a month for 10K, both billed annually. The Business plan, €667 a month for 40K executions, is currently self-hosted only. Prices move, so check n8n's pricing page before you budget.
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 queue mode docs state that running this distributed setup over SQLite is not supported.
- 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.
- A plan for binary data, because n8n does not support queue mode with filesystem binary storage. Its docs recommend S3 external storage, which the community edition does not include.
- A webhook processing decision: keep webhooks on the main instance or run dedicated webhook processes.
- The same N8N_ENCRYPTION_KEY on the main instance, every worker and every webhook processor, so they can decrypt stored credentials.
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. n8n's edition comparison lists SAML and LDAP as unavailable in the community edition, so the free instance means local accounts and manual offboarding.
- Projects and sharing. Without them, only the instance owner and each item's creator can access a workflow or credential.
- Version control with Git and environments, which you otherwise rebuild with export scripts.
- Log streaming. The community edition includes logging, but streaming events to a SIEM is an Enterprise feature.
- External secrets, custom variables, external binary data storage and multi-main high availability.
- Vendor-side uptime. Your webhook endpoint is now your responsibility, including TLS renewal and DNS.
Registering the community edition with an email gives a free licence key that unlocks folders, debug in editor and custom execution data. n8n moves features between tiers over time, so confirm against its edition comparison page. The pattern is stable: 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.
- 5Upgrade at least monthly, which is n8n's own recommendation: 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.
Recommended production architecture for self-hosted n8n
For a production self-hosted n8n deployment, I use the shape n8n's own scaling docs describe, sized to the load. Start with the single-instance column and move right only when concurrency or uptime demands it.
Three deployment tiers for self-hosted n8n.
| Component | Single instance | Queue mode | High availability |
|---|---|---|---|
| n8n processes | One main process (Docker Compose) | One main + N workers (+ optional webhook processors) | Several mains behind a load balancer with sticky sessions |
| Database | PostgreSQL (SQLite only for testing) | PostgreSQL, required | PostgreSQL, required |
| Broker | None | Redis | Redis |
| Binary data | Local filesystem | Not filesystem; S3 recommended (paid) | Not filesystem; S3 recommended (paid) |
| Licence | Community | Community | Self-hosted Enterprise (multi-main) |
| Health checks | /healthz, /healthz/readiness | Plus QUEUE_HEALTH_CHECK_ACTIVE on workers | Same, per process |
Put TLS termination in a reverse proxy, keep the editor off the public internet where you can, enable N8N_METRICS for a /metrics endpoint that Prometheus or Grafana can scrape, and keep every main and worker on the same n8n version.
Can outdated self-hosted n8n be compromised?
Yes. n8n publishes security advisories on GitHub, and several have been critical. CVE-2025-68613, published in December 2025 with a CVSS score of 9.9, let an authenticated user run arbitrary code through workflow expressions. Follow-up advisories in 2026 patched further expression bypasses. An unpatched instance keeps every one of those holes open.
The minimum security routine for a self-hosted instance.
- Watch the n8n GitHub security advisories page and apply patched releases promptly.
- Limit who can create or edit workflows. Several critical advisories required an authenticated user with edit rights.
- Keep the editor behind a VPN or SSO proxy; expose only the webhook paths that need to be public.
- Treat N8N_ENCRYPTION_KEY as a top-level secret, since it decrypts every stored credential.
On n8n Cloud, n8n applies patches for you. On self-hosted, the patch window is however long your team takes to notice and upgrade, which is the strongest argument for Cloud in teams without an ops function.
How do you stream n8n logs into a SIEM?
n8n's log streaming sends audit, workflow and node events to a syslog server, a generic webhook or a Sentry client, configured under Settings > Log Streaming. It is an Enterprise feature on both Cloud and self-hosted. Syslog is the usual route into a SIEM.
Without Enterprise, you can still ship n8n's standard application logs from the container to your log pipeline, and use /metrics plus OpenTelemetry tracing for monitoring. That covers operations, but it is not the structured audit trail many compliance reviews expect.
What is the cheapest way to host n8n?
The cheapest workable n8n hosting is a single small VPS running the community edition with Docker Compose and PostgreSQL. n8n's docs include guides for Hetzner, DigitalOcean, AWS, Azure and Google Cloud. The hosting bill is small; the true n8n hosting cost is the hours spent on backups, upgrades and monitoring.
If nobody can give those hours, n8n Cloud Starter is usually cheaper in practice. The cheapest option on paper is rarely the cheapest option after the first failed upgrade.
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.
- As of October 2026, n8n Cloud starts at €20/month for 2.5K executions, and the self-hosted Business plan is €667/month for 40K executions (annual billing).
- Queue mode requires PostgreSQL and Redis, and does not support filesystem binary storage, per n8n's queue mode documentation.
- SSO, projects and sharing, Git environments, external secrets and log streaming are not in the community edition; log streaming is Enterprise only.
- Outdated self-hosted instances are exposed to published critical vulnerabilities such as CVE-2025-68613. n8n recommends updating at least monthly.
- Self-host for data residency, custom nodes or heavy volume, and stay on Cloud when the only motive is avoiding a subscription.
Frequently asked questions
- Should I self host n8n?
- Self host n8n if data must stay in your own cloud, you need custom nodes or long-running jobs, or your execution volume outgrows the Cloud tiers. If none of those apply and nobody owns on-call, use n8n Cloud. The licence saving rarely covers the hours spent on upgrades and incidents.
- How much does self-hosted n8n cost?
- The community edition licence is free. A small VPS plus PostgreSQL covers the hosting, so the bill is usually modest, but the main n8n self hosted cost is engineering time for monthly upgrades, backups and monitoring. If you need governance features, the self-hosted Business plan is listed at €667 a month on annual billing as of October 2026.
- What is the difference between n8n Cloud and self-hosted n8n?
- n8n Cloud is a managed instance where n8n handles uptime, upgrades and security patches, billed by workflow executions; Starter is €20 a month for 2.5K executions. Self-hosted n8n runs on your infrastructure, so you control data residency and execution limits but own PostgreSQL, Redis, backups and patching. Self-hosted also exposes a /metrics endpoint that Cloud does not.
- What is the cheapest n8n hosting?
- The cheapest setup is the free community edition on one small VPS with Docker Compose and PostgreSQL. n8n's docs include deployment guides for Hetzner, DigitalOcean and the major clouds. Count your own maintenance hours too: for a team with no ops capacity, n8n Cloud Starter often costs less overall.
- What is the recommended production deployment architecture for self-hosted n8n?
- Run n8n in queue mode: one main process, several worker processes, PostgreSQL as the database and Redis as the broker, with the same N8N_ENCRYPTION_KEY and n8n version on every process. Put a reverse proxy with TLS in front, and use S3 for binary data because queue mode does not support filesystem storage. Multi-main high availability needs a self-hosted Enterprise licence.
- Can outdated self-hosted n8n be compromised?
- Yes. n8n has published critical advisories, including CVE-2025-68613 (CVSS 9.9), which allowed authenticated remote code execution through workflow expressions until patched releases shipped. An instance that is not updated keeps those vulnerabilities. n8n recommends updating at least monthly, and limiting who can edit workflows reduces exposure.
- Can I stream n8n logs into a SIEM?
- Yes, with an Enterprise licence. n8n log streaming sends audit, workflow and node events to a syslog server, a webhook or Sentry, and syslog is the usual route into a SIEM. The community edition includes standard logging only, so without Enterprise you ship container logs through your own pipeline.
- Do I need Redis to self-host n8n?
- Not for a single-instance deployment. You need Redis once you enable queue mode, where it acts as the message broker between the main instance and workers. Queue mode also requires PostgreSQL rather than SQLite.
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?
I build these systems for teams in the US, UK, and UAE. Book a free 30-minute consultation and you get a one-page plan and a fixed-scope quote within 48 hours — or message me directly, whichever is faster for you.
Prefer a form? Send a project brief →