DEV Community

John
John

Posted on

Self-Hosted n8n vs n8n Cloud: Which Paid Features Do You Lose and What Do the Workarounds Cost?

#selfhosted #opensource #automation #devops

Most solo builders and small teams lose very little by moving to the self-hosted n8n Community Edition. It has the same workflow editor and the same integration nodes, and it doesn't cap executions. The features you give up are mostly in the team and governance tiers: single sign-on, Git-based environments, log streaming and external secret stores. Every one of them has a workaround, and each workaround costs something: engineering hours, an extra container or more responsibility for you. Whether self-hosting is worth it depends on how many of those gaps you actually need to fill.

TL;DR

  • Solo automator (a freelancer syncing invoices, CRM and email): self-host the Community Edition, because none of the paid features you lose affect a single-user setup.
  • Small agency (three people building client workflows): self-host, then add a reverse proxy with authentication and a nightly export to Git, because that covers access control and versioning without a licence.
  • Startup running revenue workflows (webhooks for payments and onboarding): look hard at queue mode before leaving Cloud, because you become responsible for uptime, workers and upgrades.
  • Regulated team (a clinic or law firm handling personal data): self-host on infrastructure you control, because keeping data on your own servers usually matters more than the convenience of managed hosting.
  • Mid-size company with an identity provider (Okta or Entra ID with audit requirements): stay on Cloud or buy a self-hosted enterprise licence, because rebuilding SSO, audit logs and environments yourself costs more than it saves.
  • Homelab tinkerer (automating a home server and smart home): self-host without hesitation, because unlimited executions on hardware you already own costs you almost nothing.

The central tradeoff is simple: n8n Cloud charges you for convenience and governance, while the Community Edition charges you in maintenance time and in the features you have to rebuild yourself.

Table of contents

What exactly is the difference between n8n Community Edition and n8n Cloud?

n8n ships as one codebase in two delivery models. The Community Edition is the free build that you run yourself, usually from the official n8nio/n8n Docker image. n8n Cloud is the same product, hosted and operated by the n8n team, and you pay for it by subscription. The editor, the nodes and the expression syntax are the same in both. What differs is who runs the infrastructure, how usage is metered and which governance features are switched on.

Aspect Community Edition (self-hosted) n8n Cloud
Who runs it You, on a VPS, home server, NAS or any Docker host The n8n team, on their infrastructure
Usage metering No execution cap, limited only by your hardware Billed by monthly executions, with tiers per plan
Database SQLite by default, PostgreSQL recommended for production Managed for you, not exposed
Upgrades You pull new images and run migrations yourself Applied by n8n
Community nodes Installable from npm, including unverified packages Restricted to verified packages
Licence Sustainable Use License, source available Commercial subscription terms
Governance features Core only, enterprise features need a licence key Unlocked progressively on higher plans

Two details matter most when you plan a move. First, the self-hosted editor listens on port 5678 by default. You have to put it behind a reverse proxy with TLS yourself before webhooks from outside services can reach it. Second, the Community Edition is not a cut-down trial. It runs complex production workflows indefinitely. The missing pieces sit mostly in team management, compliance and scaling, which the next section lists one by one.

Which features are locked behind n8n paid plans and the enterprise licence?

n8n gates features in the same code that ships to everyone. The enterprise modules are already inside the Docker image you pull. They stay dormant until a valid licence key is activated, either in Settings > Usage and plan or through the N8N_LICENSE_ACTIVATION_KEY environment variable. Cloud customers get the same modules progressively as they move up the plans. The features most people notice are these:

  • Single sign-on: SAML and LDAP login, and OIDC on recent releases, are enterprise features. The free edition authenticates with its own email and password accounts.
  • Source control and environments: connecting an instance to a Git repository and promoting workflows from development to production through branches is licensed.
  • External secrets: pulling credentials from stores such as HashiCorp Vault, AWS Secrets Manager or Azure Key Vault is not available without a key.
  • Log streaming: forwarding audit and workflow events to a syslog server, a webhook or Sentry is licensed.
  • Projects and fine-grained roles: you can invite users for free, but scoped projects with custom permissions are paid.
  • Variables: instance-wide $vars that you can reference across workflows need a licence.
  • Extended workflow history: the free edition keeps only a short version history before older versions are pruned.
  • Multi-main high availability: running several main processes behind a load balancer for redundancy is an enterprise capability.

Which tier a feature belongs to has changed between releases, and some features have been moved down to cheaper plans or into the free edition. Check the current pricing page against your own list of must-haves. For a single user, this list rarely matters. For a team of ten with an auditor, almost every line becomes a cost to replace, and the following sections price those replacements one at a time.

How does n8n Cloud execution-based pricing compare with paying for your own server?

n8n Cloud counts one execution each time a workflow runs from start to finish, however many nodes it passes through. That is kinder than per-step billing, but it still scales with frequency. A Schedule Trigger firing every 5 minutes produces 288 executions a day, or about 8,640 in a 30-day month, from a single workflow. Ten workflows like that put you into a high tier quickly, even if each run only checks an inbox and finds nothing new.

A self-hosted server works the other way round. You pay a fixed amount for the compute and the bill stays flat whether you run 1,000 or 1,000,000 executions, until the hardware saturates.

Cost driver n8n Cloud Self-hosted Community Edition
Monthly bill Plan price tied to an execution quota Fixed hosting cost, independent of executions
High-frequency triggers Each run consumes quota Free beyond CPU and memory
Traffic spikes Can push you to the next tier Absorbed until the server is saturated
Hidden cost Governance features tied to higher plans Your time for patching, backups and monitoring
Predictability Rises in steps with usage Flat, with occasional hardware upgrades

There are several places to run that flat-cost server: a self-managed VPS, a home server, a NAS with Docker support, or a managed platform. Yundera is a managed Personal Cloud Server, built on CasaOS, that runs self-hosted apps as Docker containers on a server dedicated to the user.

Before you compare quotes, export a month of execution counts from your Cloud workspace's usage page. Your real run frequency, not the number of workflows you have, decides which side of the table costs less.

What does a self-hosted n8n server actually cost to run each month?

The headline hosting price is only one line of the bill. A realistic monthly cost for the Community Edition is made up of these components, and each one can be estimated in advance:

  • Compute: n8n itself is light. It mostly waits on HTTP calls, so a small instance with 1 to 2 vCPUs and 2 GB of RAM is a common starting point for one user. Code nodes, large JSON payloads and parallel executions are what push you into a bigger size.
  • Database: PostgreSQL adds a few hundred megabytes of memory and needs its own volume. You can stay on SQLite for very light use, but you then give up queue mode and concurrent writes.
  • Storage growth: execution logs grow until you prune them. Set EXECUTIONS_DATA_PRUNE=true and choose a value for EXECUTIONS_DATA_MAX_AGE (in hours, default 336) so the disk doesn't fill up silently. Setting N8N_DEFAULT_BINARY_DATA_MODE=filesystem keeps attachments out of the database.
  • Off-site backups: object storage or a second machine for nightly database dumps is a small recurring cost, and losing workflows and credentials would cost far more.
  • Domain and TLS: you need a domain for webhook URLs. Let's Encrypt certificates are free, but someone has to keep renewals working.
  • Electricity, for a home server: multiply average watts by 730 hours. A 10 W mini PC uses 7.3 kWh a month, which you then multiply by your own tariff.
  • Your time: upgrades, restores and incident response. This is usually the largest line, and section 10 covers it.

Where you put the box changes which lines apply. A self-managed VPS bills compute and storage directly. A home server or a NAS trades those for electricity and your own uplink. Managed options such as Yundera bundle the hosting and HTTPS routing.

Replacing SSO and role-based access without the enterprise licence

Without a licence, every person logs into n8n with a local email and password. Accounts are created by invitation from the owner, and they never sync with your identity provider. You can't make n8n itself speak SAML, but you can put a gate in front of it. The usual workarounds stack together:

Workaround What it gives you What it costs
Forward-auth proxy (Authelia, Authentik or oauth2-proxy) Your company login and MFA in front of the editor An extra container to run, plus a second login screen in front of n8n's own
VPN-only editor (WireGuard or Tailscale) The editor is unreachable from the public internet A VPN client on every device, and you still have to expose webhooks separately
Path exceptions for /webhook/ and /webhook-test/ External services can still trigger workflows Careful proxy rules: one wrong pattern either breaks integrations or exposes the UI
Separate instances per team A rough form of isolation in place of scoped projects Double the upgrades, backups and credentials to manage
A written offboarding checklist Leavers lose access on the same day A manual step that someone has to remember every time

The proxy approach has the most pitfalls. OAuth credential flows call back to /rest/oauth2-credential/callback, and if your proxy challenges that path, connecting a Google or Microsoft account fails with an opaque redirect error. Test every credential type after you enable forward-auth, not just the login page.

What you can't rebuild is group sync. When someone changes team in your identity provider, nothing in n8n changes. For two or three people, that is a minor chore. Past roughly ten users, or with an auditor asking who approved which access, the manual approach starts to cost more than the licence it replaces.

Can you get Git version control and staging environments without paying?

Partly. The licensed feature connects n8n to a Git branch and lets you push and pull from the UI. The free edition has a command-line interface that gets you most of the way there, as long as you accept some scripting and a few sharp edges:

  • Nightly export to a repository: run docker exec -u node n8n n8n export:workflow --all --separate --output=/home/node/backup/ from cron, then git add and git commit on the host. --separate writes one JSON file per workflow, which keeps your diffs readable.
  • Noisy diffs: every save touches fields such as updatedAt and versionId, and dragging a node changes its position array. Strip or sort those fields with jq before committing, or every commit looks like a rewrite.
  • A staging instance: a second n8n container with its own database and its own N8N_ENCRYPTION_KEY works as a test environment. You promote a workflow with n8n import:workflow --separate --input=... on the production side.
  • Credential mapping: workflows reference credentials by ID. If the staging and production IDs differ, imported workflows show broken credential links until you reassign them by hand or create the credentials with matching IDs.
  • ID collisions: importing a file whose workflow ID already exists overwrites that workflow without warning. It is useful for promotion and dangerous if you get it wrong.
  • The public API alternative: the REST endpoints under /api/v1/workflows let a CI job pull and push workflows with an API key, which suits teams that already run GitHub Actions or GitLab CI.

Never commit the output of n8n export:credentials --decrypted to a repository. It contains every secret in plain text. What you lose compared with the licensed feature is the guardrails: the UI never shows which instance is ahead, and a careless import has no undo.

Credentials, secrets and the encryption key on a self-hosted instance

On Cloud, n8n holds the key that encrypts your stored credentials. Once you self-host, that key is yours to keep, and losing it is the most expensive mistake you can make with the Community Edition. Without the licensed external secrets feature, these are the habits that replace it:

  • Pin the encryption key: if N8N_ENCRYPTION_KEY is not set, n8n generates one on first start and writes it to /home/node/.n8n/config. If you lose that volume, every credential in the database becomes unreadable. Set the key explicitly and store a copy in your password manager.
  • Back up the key separately from the database: a dump of PostgreSQL without the key restores your workflows but not their credentials. A key stored next to the dump means a single leaked backup exposes everything.
  • Use _FILE variables for infrastructure secrets: n8n reads variables such as DB_POSTGRESDB_PASSWORD_FILE from a mounted file. That lets Docker secrets or a mounted Vault agent supply values without putting them in docker-compose.yml.
  • Block environment access from nodes: set N8N_BLOCK_ENV_ACCESS_IN_NODE=true so a Code node or an expression can't read $env and leak host secrets into a workflow output.
  • Rotate by hand: without external secrets, rotating an API key means editing every n8n credential that uses it. Keep a simple inventory of which credentials map to which upstream accounts.
  • Plan for a key change: changing the encryption key later means you either re-enter every credential, or export them decrypted, switch keys and re-import. Do the export step on a trusted machine only.

These rules apply wherever the container runs, whether that is a VPS, a NAS, a home server or Yundera. The platform stores the volume, but you are responsible for the key.

Logging, monitoring and execution history without log streaming

The licensed log streaming feature sends structured events to a syslog server, a webhook or Sentry. The free edition has no single equivalent, but it has enough building blocks to cover most operational needs. The one real gap is audit.

Need With log streaming Free workaround
Alerts on failed workflows Failure events forwarded to your log destination An error workflow built on the Error Trigger node, assigned in each workflow's settings, posting to Slack, email or ntfy
Application logs Structured event stream N8N_LOG_OUTPUT=console,file with N8N_LOG_LEVEL=info, shipped by Promtail or Vector to Loki or another collector
Metrics Not the purpose of the feature N8N_METRICS=true exposes a Prometheus endpoint at /metrics for Grafana dashboards
Liveness checks Not covered Poll /healthz from Uptime Kuma or any external monitor
Audit trail of user actions Login, credential and workflow change events No clean equivalent: you can only rebuild a partial history from Git exports and proxy access logs

Execution history is a related cost. Each saved execution writes its full input and output data to the database, so heavy workflows grow PostgreSQL quickly. Set EXECUTIONS_DATA_SAVE_ON_SUCCESS=none on high-volume instances and keep EXECUTIONS_DATA_SAVE_ON_ERROR=all. That way you keep exactly the runs you would debug and drop the thousands you never look at.

Make sure the error workflow itself can't fail silently. If it depends on the same SMTP credential that just expired, nothing tells you. Give it a second, independent alert channel, and trigger a deliberate failure once a month to confirm the alerts still arrive.

How do you scale self-hosted n8n with queue mode, Redis and workers?

Queue mode is free in the Community Edition, and it is how one instance grows beyond a single process. The main process accepts triggers and webhooks, pushes jobs into Redis, and separate worker containers pull and run them. Getting it right comes down to a handful of decisions:

  • Switch the mode: set EXECUTIONS_MODE=queue and point every process at Redis with QUEUE_BULL_REDIS_HOST. SQLite is not supported here, so PostgreSQL becomes mandatory.
  • Add workers: each worker is the same image started with n8n worker. The --concurrency flag defaults to 10 parallel jobs per worker. Raise it for I/O-bound workflows and lower it for heavy Code nodes.
  • Split off webhook processors: for high inbound traffic, run n8n webhook containers behind your load balancer so the main process isn't parsing every request.
  • Share the encryption key: every main, worker and webhook process needs the same N8N_ENCRYPTION_KEY, or workers fail as soon as they decrypt a credential.
  • Plan binary data storage: the default filesystem mode assumes a single machine, and the S3-backed external storage option is licensed. Workflows that pass files between nodes need a deliberate design before you scale them out.
  • Accept a single main: multi-main high availability is licensed, so the main process remains a single point of failure. Restarting it pauses triggers until it comes back.

The hardware question follows on from this. If you run every process on one box, whether that is a VPS, a home server, a NAS or Yundera, the main, the workers, Redis and PostgreSQL all compete for the same CPU and memory. Queue mode on a single machine buys you concurrency and isolation from crashes, not more capacity. Real horizontal scaling means workers on separate hosts, with Redis and PostgreSQL reachable over a private network.

Backups, upgrades and the maintenance hours nobody budgets for

On Cloud, upgrades and backups are part of what you pay for. Self-hosted, they become recurring work on your calendar, and they are usually the biggest hidden cost of the move. Budget for them from the first week:

  • Pin image tags: use n8nio/n8n:1.x.y in docker-compose.yml, never latest. n8n ships new versions often, and an unplanned restart can pull a release whose database migrations you haven't reviewed.
  • Back up before every upgrade: migrations run automatically when the container starts and are not designed to be rolled back. Take a pg_dump -Fc immediately beforehand, so a downgrade means restoring that dump rather than hoping.
  • Back up three things, not one: the PostgreSQL dump, the encryption key, and the /home/node/.n8n volume, which also holds installed community nodes under nodes/. Any one of the three alone gives you an incomplete restore.
  • Read the breaking changes first: n8n publishes a breaking-changes page in its documentation. The move to 1.0 changed defaults such as the execution order of branches, and that silently altered how some older workflows behaved.
  • Rehearse restores: a backup you have never restored is a guess. Restoring into a scratch container once a quarter tells you how long a real recovery takes.
  • Watch community nodes: unverified npm packages can break after an n8n upgrade and stop every workflow that uses them from loading. Test them in staging first.

The honest way to compare costs is to convert this list into hours. Count a monthly upgrade window, a quarterly restore drill and the occasional incident. Multiply the total by what your time is worth and add the result to the hosting bill from section 4. For many small teams that figure, not the server, decides whether self-hosting saves money.

Top comments (0)