n8n Cloud vs Self-Hosted: Costs, Limits and When to Switch

n8n is unusual among automation tools because the hosted product and the one you run yourself are the same software. A workflow exported from one imports into the other. So the n8n cloud vs self hosted decision is not about features first. It is about how you pay, which limits you hit, where the data sits, which licence applies and who fixes the instance when it breaks. This post goes through each, and ends with a checklist for switching in either direction.

What you are actually choosing between

n8n Cloud is n8n run by n8n. n8n handles installation, upgrades, backups, TLS and monitoring, and a free trial lets you build a workflow the same day.

Self-hosted Community Edition is the same n8n that you install on a server you control. It is free to licence, has almost the complete feature set, and every operational job is yours.

Paid self-hosted editions (Business and Enterprise) add team and governance features through a licence key. n8n's own choose how to use n8n page recommends Cloud for people who want to start right away or lack technical expertise, and self-hosting for those who need full control and have the technical resources.

How n8n Cloud vs self hosted pricing is metered

n8n Cloud is metered by executions. Plans are priced on monthly workflow executions. An execution is one run of a whole workflow, whether it has three nodes or sixty, and however much data it moves. Higher tiers raise the monthly allowance and the number of production executions that can run at the same time, and add features such as longer history and team controls. We do not quote n8n's prices or allowances here, because they have changed more than once; read the current n8n pricing page on the day you compare.

Concurrency on Cloud is capped per plan; beyond the cap, production executions wait in a queue (see n8n's concurrency documentation).

Self-hosting is flat. The Community Edition has no execution meter. You pay for a server, and you pay with your time. Whether a workflow runs 500 or 500,000 times a month, the server bill stays the same; only the server size changes, and that grows far more slowly than the execution count.

Count your executions first

The count is usually higher than expected, and triggers drive it:

Tip: polling triggers count even when they find nothing. A workflow that checks a mailbox every minute and finds one new message a day still runs 43,200 times a month. On a metered plan, replace polling with a webhook wherever the other system can send one, and set every remaining interval to what the business actually needs.

On an existing instance, take one normal month from the executions list instead of estimating.

Limits you meet in practice

The community nodes row comes from n8n's community nodes documentation, which says unverified community nodes are not available on n8n Cloud.

The network row matters more than it looks: a self-hosted instance has one static address for a partner's allowlist, and can reach a private database without exposing it.

Scaling differs too. On Cloud you move up a tier; self-hosted, you resize the server and eventually split n8n into a main instance and workers. That is queue mode, covered step by step in n8n queue mode with Redis and workers. On our Cloud n8n VPS queue mode is not pre-configured; you add Redis, PostgreSQL and the workers yourself, and the L plan is the size we suggest for it.

Data residency and GDPR

An n8n instance stores two sensitive things: credentials for every system you connected, and execution data, which is a copy of whatever passed through each workflow.

On Cloud, both sit in n8n's infrastructure under n8n's terms and data processing agreement. n8n's pricing FAQ states that hosted plans store data in the EU, on servers in Frankfurt, Germany. For many European companies that is enough; check the DPA and the sub-processor list with whoever handles your compliance.

Self-hosted, both sit on a server you chose, encrypted with a key only you hold. Our servers are in France, in the EU. So the difference is control rather than country: on your own VPS you decide access, retention, backup location and update timing. As controller of the personal data, configuring that properly is your work; EU hosting alone does not make a setup GDPR compliant.

Tip: whichever side you choose, turn off saving of successful execution data for workflows that carry personal data, or shorten retention. Data you did not store cannot leak.

Maintenance burden

On Cloud, n8n runs upgrades, backups, TLS and monitoring, and that is a real part of what you pay for.

On a self-managed VPS, those jobs move to you. On our Cloud VPS and Cloud n8n VPS the customer's job is OS updates, firewall and SSH hardening, SSL, monitoring and backups beyond the daily snapshot. A Cloud n8n VPS keeps the n8n setup in /opt/n8n, so the routine looks like this:

cd /opt/n8n
docker compose pull && docker compose up -d     # update n8n
docker compose logs --tail 50 n8n               # confirm it started cleanly
df -h /                                         # execution history fills disks

Add a workflow export to your own backup routine, so a restore does not depend on a single snapshot:

cd /opt/n8n
docker compose exec n8n n8n export:workflow --all --output=/home/node/.n8n/backup-workflows.json

Then copy that file somewhere off the server, together with a copy of the instance encryption key: without that key, credentials from a backup cannot be decrypted.

For someone comfortable on Linux this is a modest monthly routine. If nobody wants that job, a fully managed VPS moves OS patching, monitoring and backups to us at a higher price; n8n and your workflows stay yours.

Tip: the failure mode of self-hosting is an instance nobody has updated for a year, holding OAuth tokens for the company mailbox. If you cannot name the person who will run the update each month, choose Cloud.

Cost at different usage levels

Our Cloud n8n VPS plans, US dollars with VAT included:

All plans include unlimited workflows and executions and root access; yearly billing gives two months free, with a 30-day money-back guarantee (refund policy).

The comparison at three usage levels:

Self-hosted, memory and concurrency pick the plan, not run counts. Add your time to make the sum honest:

self-hosted per month = server + (maintenance hours x your hourly rate)
cloud per month       = the tier that covers your executions and concurrency

A worked example with the S plan, one hour a month and time valued at $40 an hour gives $8.49 + $40 = $48.49 a month. If the Cloud tier you need costs less than that, Cloud is cheaper and less effort. If it costs more, self-hosting wins, and the gap widens as executions grow. If n8n would be your first server, count the setup hours too; a server delivered with n8n already running removes most of them.

The licence

The Community Edition is released under n8n's Sustainable Use License, which is source-available, not an OSI open source licence. The licence text allows you to use or modify the software "only for your own internal business purposes or for non-commercial or personal use". Automating your own company's invoicing, support and reporting is squarely allowed, with no limit on workflows or executions.

What it restricts is offering n8n itself to others: reselling access or embedding it white-labelled in your product needs a commercial agreement with n8n.

The second line is Enterprise features. Source files marked .ee are not under the Sustainable Use License and need an n8n Enterprise licence. According to n8n's edition comparison, the Community Edition does not include SSO (SAML and LDAP), workflow and credential sharing, projects, environments, Git-based version control, external secrets, log streaming, external binary data storage, custom variables or multi-main mode. Free registration of the Community Edition adds folders, debug in editor and custom execution data. If you need the paid features, you pay n8n either way, on Cloud or self-hosted.

When to switch: a checklist

Stay on, or move to, n8n Cloud when

• Nobody on the team is comfortable with SSH, Docker and DNS, and nobody wants to be.
• Volume is low and predictable: a handful of workflows running a few times a day.
• You need SSO, projects or other paid features and would be buying a licence anyway.
• The automation is business-critical and you want a vendor responsible for running it.
• You are evaluating n8n and want a working workflow today.

Move to self-hosted when

• Your execution count keeps pushing you into the next tier, because of frequent schedules, busy webhooks or polling.
• Workflows need unverified community nodes, a database next to n8n, or access to private systems.
• A partner needs one fixed IP address for their allowlist.
• You want control over where data and backups live, and how long execution data is kept.
• You want a fixed monthly cost that does not depend on how widely the automation is adopted.
• Someone on the team already looks after Linux servers.

How to move

Starting on Cloud and moving later is a sound path. Export the workflows, import them on the new instance, re-enter the credentials, then switch webhook URLs in the systems that call them. If you are new to servers, our explainer on what a VPS is covers the basics, and a Cloud n8n VPS boots with n8n already running so you can start at the import step. Going the other way works the same, minus the server.

Frequently asked questions