n8n is open source: you can host it yourself, or use the official n8n Cloud. The difference is about more than who maintains the server.
30-second overview
| n8n Cloud | Self-hosted / managed | |
|---|---|---|
| Billing | Execution count capped by plan | Per instance, executions not metered |
| Where data sits | Their servers | Your environment |
| Community nodes | Restricted | Installable |
| Operations | Not your problem | Yours if you self-host |
| Best for | Low volume, no appetite for infrastructure | High volume, or data residency requirements |
Difference 1: billing by execution count
n8n Cloud's plans are tiered by workflow execution count. That is an awkward pricing model for automation: the more valuable your workflow is and the more often it fires, the more it costs, until you start merging workflows and cutting triggers to save money — which defeats the whole point of automating.
Self-hosted has no concept of execution count. What your instance can run depends on its CPU and memory, not on how many times it ran. A monitoring workflow that fires every minute and a report that fires once a day cost exactly the same.
Difference 2: where the data flows
This is the core reason to self-host. The data an n8n workflow touches is usually sensitive: customer lists, order contents, API responses from internal systems, credentials for third-party services.
On Cloud, that data passes through n8n's own servers; self-hosted, it is only ever processed inside your own container. If your business involves personal data, or a customer contract explicitly states that data must not pass through a third party, this difference is decisive rather than a matter of preference.
The same goes for credentials (the API keys for each service) — self-hosted, they are stored in your own instance.
Difference 3: community nodes
n8n has a large ecosystem of community nodes that extend it with integrations the official build doesn't include. Installing community nodes is only fully open on self-hosted; Cloud has restrictions. If what you need to connect is a local Taiwanese service or a more obscure SaaS, this alone decides whether you can do it.
The price of self-hosting
To be honest about what self-hosting costs you: servers, Docker, a reverse proxy, SSL certificates, version upgrades. None of it is difficult, but it is an ongoing cost, and when something breaks it is your weekend.
RoamerHost sits in between — the instance is your own isolated container, the data is in your own environment, community nodes are fully open, but the operating system, certificates and reverse proxy are handled by the platform.
RoamerHost's n8n specs
| Item | Details |
|---|---|
| Image | n8nio/n8n (the official build, not a fork) |
| Price | avg. NT$499/mo (billed yearly) |
| CPU | 1 core |
| Storage | 2 GB |
| Execution count | Unlimited |
It runs the official image, not a fork we modified — which means the official documentation, community tutorials and upgrade paths all apply to you exactly as written, and you can take your data and host it yourself whenever you like.
The plan's resources are more than enough for most workflows, with one caveat: if your workflow loads a large amount of data into memory at once (pulling tens of thousands of records and then transforming them, say), switch to batch-processing nodes or you will hit the memory ceiling.
Three things to know before you move
Credentials don't move with you
Workflows export and import, but the API keys and authorizations for each service have to be set up again. With a lot of workflows this step takes longer than you'd think, so put together a list before you start moving.
Webhook URLs change
Changing platforms means changing URLs, so every callback URL you entered into an external service has to be updated. The one you miss will quietly stop working.
Run both in parallel for a while
Only switch the old platform off once the workflows are running reliably in the new environment. You pay twice during the overlap, but that is cheaper than broken automation.
Three differences that actually drive the decision
1. The billing model works its way back into your design
When you're billed per execution, you start writing workflows to be frugal without noticing — cutting a step wherever you can, skipping error handling, skipping retries. Those compromises stay in the workflows, even after you change platforms.
Per-instance billing removes that pressure, so you can add the fault tolerance that belongs there. This difference never shows up on a feature comparison table, but over time it shapes the quality of your automation.
2. Whose servers your data passes through
What your workflows handle — customer lists, orders, conversation logs — passes through their servers on the cloud version. Usually that's fine, but if you handle personal data or your customers have compliance requirements, run it past your own people first.
3. Community nodes
n8n's community node ecosystem is very active, and integrations for many niche services come from the community. The cloud version is restricted here, and you usually only find out when you need to connect one specific service.
FAQ
Q: How is an execution counted?
Definitions differ between vendors, which is exactly what to watch for. Whether "one execution" means the whole workflow running once, or each node counting separately, makes an enormous difference. Check that definition when comparing plans instead of just comparing numbers.
Q: What's the difference between self-hosted and managed?
Data location and billing model are the same for both; the difference is who handles operations. Self-hosted, you deal with installation, upgrades, backups and SSL; managed, the host does. There's a cost comparison in the cost table with your time included.
Q: Can I start on the cloud version and move later?
Yes, workflows export and import. But remember that credentials (the API keys for each service) don't come with them and have to be configured again.
Q: Is data residency a real issue or marketing talk?
It depends on your business. If you handle ordinary marketing data, it usually isn't a substantive problem; if you're in healthcare or finance, or your customer contracts contain data processing clauses, it's a hard requirement. Honestly, most small and medium businesses don't need to pay for this.
Q: How much volume justifies switching?
There's no absolute number, but there is a signal: when you start writing workflows that are hard to maintain in order to save executions. That cost has already exceeded the bill.
Don't decide for a scale that hasn't happened
A common thinking trap: volume is small now, but "what if it grows?", so you pick the more complicated option from the start.
In reality you can switch either way at any time, and workflows export. Decide based on what you need now and switch when you actually hit a limit — that costs far less than carrying complexity you don't use.
There is only one case where you have to get it right from day one: when data residency is a hard requirement. That's not a question of scale but of compliance, and it leaves no room for "we'll deal with it later".
Sources and further reading
n8n's nodes and pricing change frequently; these are the primary sources to verify against:
- n8n official documentation
- n8n official pricing — cloud plans and quotas
- n8n source code and release notes — the authority on licensing terms
Further reading
- What is n8n? The full introduction
- Building your first automation workflow
- Webhooks and third-party integration guide
Want someone to build it for you?
If you would rather not assemble these workflows yourself, or the scale is big enough that you want someone planning alongside you, Roamer Tech (RoamerHost's parent company) takes on business process automation and custom AI agent development:
