n8n Cloud or self-hosted? How a small company should decide
Self-hosted n8n has no execution cap but makes you the operator; Cloud charges per run and is patched for you. Why we chose Cloud, and when we would not.
- n8n Cloud: managed, updated for you, billed per workflow execution. You run workflows, not servers.
- Self-hosted: no execution limit and full control over where data lives, but you become the operator: updates, database, backups, monitoring.
- The deciding questions are volume, data residency and who is on call, not the licence price.
- We run Cloud. Whichever you choose, back up from outside n8n.
For most small companies, n8n Cloud is the better start, and self-hosting becomes worth it only when execution volume is high, data must stay on your own infrastructure, or you already have someone who looks after servers. Self-hosted n8n removes the execution limit, but it turns you into the operator of a production system. Cloud costs money per run, but someone else handles updates, uptime and security patches. We run close to a hundred active workflows on n8n Cloud, and this is how we would make the decision again.
What our instance carries
To make the trade-off concrete: our n8n Cloud instance runs the sales mailbox pipeline (triage, drafting, review screens, sending, reconciliation), inbox-zero rules for a personal mailbox, bank statement imports through a read-only connection, backup runners and watchdogs for other systems, the AI diagnosis step of our website quality monitor, and the image generation used for this blog. Several of these are called by AI agents as tools through webhooks. If the instance stopped for a day, sales replies would wait, backups would not be checked and nobody would get the error alerts. That is a production system, whoever hosts it, and the question is only who keeps it alive.
What actually differs
| n8n Cloud | Self-hosted (Community Edition) | |
|---|---|---|
| Billing | Plan with an execution allowance; one run counts once however many steps it has | No execution limit; you pay for the server and your time |
| Updates and security | Done for you | Your job, on your schedule |
| Where data lives | n8n's infrastructure | Wherever you run it |
| Database and scaling | Managed | You choose and maintain it (SQLite or Postgres, queue mode for heavy loads) |
| Environment and custom nodes | Limited control | Full control |
| Backups | Platform-level; your own export still recommended | Entirely yours |
Plans and prices change. Check n8n's current pricing page before you decide. The billing model, per execution on Cloud and unlimited when self-hosted, has been stable, and it is the model that shapes the decision.
Cost at volume
Per-execution billing is generous compared with per-step billing, which is why we chose n8n over Zapier in the first place (see n8n vs Zapier). But executions add up in ways that are easy to miss:
- Polling triggers. A workflow that checks a mailbox every minute runs about 43,000 times a month, even if it finds nothing most of the time. Our inbox classifier runs four times a day instead. That was a business decision first, and it is also cheaper.
- Sub-workflows. Splitting a big workflow into reusable parts is good design, and on most plans every part that runs counts as an execution.
- Webhooks called by agents. When AI agents use workflows as tools, call volume follows the agents' activity, not your calendar.
If your projected volume sits comfortably inside a Cloud plan, the server you would rent for self-hosting is not the real saving. The saving would have to cover the hours of operating it.
The maintenance you sign up for
Self-hosting n8n is easy to start: one container and a domain. Keeping it running for years is a different job:
- Applying n8n updates, and reading the release notes for breaking changes before you do.
- Running and backing up the database that holds workflows, credentials and execution history.
- TLS certificates, a reverse proxy, firewall rules, operating system updates.
- Monitoring that tells you the instance is down before a customer does.
- Protecting the encryption key for credentials. Lose it and every stored credential becomes useless.
None of this is difficult for someone who runs servers anyway. For a small company without that person, it is a production system with nobody on call. That is the real reason we chose Cloud. We want to spend our time on the workflows that run the business, not on the machine underneath them.
Data residency
This is the strongest argument for self-hosting. An automation that reads a sales inbox or accounting data moves sensitive information through the automation platform. Some customers will ask where that happens before they let a workflow near their mailbox, and some sectors have rules that settle the answer for you.
Two things help whichever way you go. First, keep secrets in the tool's credential store, never in workflow fields or in an AI agent's context. In our setup, agents call n8n webhooks as tools and never see the API keys behind them. Second, give credentials the smallest scope that works. Our bank-data connection is read-only. When a system cannot narrow a credential's rights, we write down which single job it is for and keep everything else away from it.
Backups from outside the tool
Whichever you choose, do not let n8n back itself up. A workflow that backs up n8n and runs in n8n disappears together with it. Ours is a scheduled GitHub Action that downloads the full JSON of every workflow through the n8n API and stores it on a separate shared drive. Credentials are listed by name only: n8n does not export their values through the API, and we would not want them in a backup anyway. They belong in an encrypted secrets vault.
This also answers the lock-in question. With every workflow as a JSON file in a folder you control, moving between Cloud and a self-hosted instance is an import plus re-entering credentials, not a rebuild.
How to decide
| If this is true | Lean towards |
|---|---|
| Nobody in the company runs servers | Cloud |
| Volume fits comfortably in a Cloud plan | Cloud |
| Data must stay on your own infrastructure | Self-hosted |
| Very high volume, such as per-event webhooks at scale | Self-hosted, with someone on call |
| You need custom nodes or full control of the environment | Self-hosted |
If you are unsure, start on Cloud, export your workflows from day one, and revisit when the bill or a customer's data question forces the issue. The Models, limits and cost lesson helps with the other half of the running cost, the AI calls inside the workflows. If part of your logic is better as code at the edge than as a workflow, the Cloudflare Workers manual shows the alternative we use for our forms gateway.
Frequently asked questions
Is self-hosted n8n free?
The Community Edition is free to run under n8n's Sustainable Use Licence and has no execution limit. You still pay for the server, the database, backups and, above all, the time to keep it updated and running.
Can I move from n8n Cloud to self-hosted later?
Yes. Workflows export as JSON and import into another instance. Credentials do not travel with them and have to be re-entered, which is a good reason to keep a written list of which credentials each workflow uses.
Which is more secure?
Neither by default. Cloud gives you a professionally patched platform; self-hosting gives you control over where data lives. A self-hosted instance that is not updated is less secure than Cloud.
How do you back up n8n?
From outside n8n. We export every workflow as JSON with a scheduled GitHub Action and store it on a separate drive, with credentials listed by name only. A backup that runs inside n8n disappears together with it.
Written from our own production systems. Drafted with AI assistance and reviewed by Kamil Hrbáček.
Want this running in your company?
Flowsmith designs and operates automations like this for small and mid-sized teams — with a person approving anything that leaves the building.
