What's the difference between n8n self-hosted and n8n cloud?
n8n Cloud is the vendor-hosted version of n8n that the company runs, patches, and scales for you; self-hosted n8n is the exact same software running on infrastructure you own and operate. The workflow engine, the node library, the AI/agent nodes, and the editor are identical in both. What differs is who owns the servers, who applies updates, where your execution data physically lives, and how the bill is calculated.
For most teams the real question behind n8n self-hosted vs cloud is not "which is better" but "which trade-off fits us right now" — speed and zero-ops on one side, control and data residency on the other. Below is a decision framework a CTO or founder can act on in an afternoon.
How much does n8n cloud cost?
n8n Cloud is priced per workflow execution, not per step or per task. One full run of a workflow counts as a single execution whether it touches two nodes or two hundred — a meaningful difference from the per-task metering used by other tools (we break that down in n8n vs Zapier vs Make).
At the time of writing, the tiers look roughly like this — always confirm current numbers on n8n's pricing page before you commit:
- Starter — around €20/month billed annually, a few thousand executions, shared infrastructure, a handful of active workflows.
- Pro — higher monthly fee, tens of thousands of executions, more concurrency, admin roles, and execution search.
- Enterprise — custom pricing that adds SSO/SAML, log streaming, multiple environments, and dedicated support.
The cost trap is predictability. If you build high-frequency automations — polling triggers, per-row loops, chatty AI agents — execution counts climb fast, and a €20 plan can become a €200 plan quietly. Model your expected monthly executions before choosing Cloud, not after your first overage.
What does it actually take to self-host n8n?
Self-hosting starts free. The n8n Community Edition is source-available under n8n's fair-code Sustainable Use License, which permits internal business use at no license cost — you pay only for the infrastructure it runs on. That is the headline attraction: unlimited executions with no per-run meter.
The cost simply moves from a subscription line to an engineering line. A production-grade self-hosted setup means owning:
- A real database. Never run production on the default SQLite. Use PostgreSQL so executions, credentials, and workflow history survive restarts and scale.
- The encryption key. n8n encrypts stored credentials with
N8N_ENCRYPTION_KEY. Lose it and every saved credential is unrecoverable — it must be backed up and rotated deliberately. - TLS, auth, and a reverse proxy. A public n8n instance with weak access control is a standing incident; put it behind a proxy with HTTPS and, ideally, SSO.
- Updates and backups. New Docker image tags ship frequently. Someone on your team owns patching, database backups, and restore drills.
- Scaling. Beyond a single container you move to queue mode — Redis plus dedicated worker nodes — so heavy workflows do not block the editor.
Note the licensing nuance too: fair-code allows you to run n8n for your own operations, but reselling it as a hosted product to others is restricted, and features like SSO, log streaming, and git-based environments require a self-hosted Enterprise license. For most internal automation teams, none of that is a blocker — but read the license before you build a business on top of it.
Should you run n8n on AWS?
Running n8n on AWS is the most common self-hosting path for teams that already live in that ecosystem, and it maps cleanly onto managed services:
- Compute — a small EC2 instance with Docker for a single-node setup, or ECS Fargate when you want the container managed without babysitting a VM.
- Database — RDS for PostgreSQL, so backups, failover, and patching are AWS's problem rather than yours.
- Scale-out — ElastiCache for Redis plus additional worker tasks to run n8n in queue mode under load.
- Edge — an Application Load Balancer terminating TLS via ACM, with the editor locked behind your VPC, VPN, or SSO.
- Secrets — Secrets Manager or SSM Parameter Store for the encryption key and node credentials, kept out of plaintext environment files.
The strategic reason to choose AWS is data residency and integration. Everything your workflows touch — customer records, documents, model calls — stays inside a region and account you control, which matters directly for GDPR in Europe and for data-localisation expectations in the UAE and India. Your automations also sit next to the rest of your stack, so private VPC calls to internal APIs and databases never traverse the public internet.
n8n self-hosted vs cloud: a side-by-side comparison
| Factor | n8n Cloud | Self-Hosted (e.g. on AWS) |
|---|---|---|
| Cost model | Monthly subscription, metered by executions | Infrastructure + engineering time; unlimited executions |
| Time to first workflow | Minutes | Hours to days for a hardened setup |
| Ops burden | None — fully managed | You own updates, backups, scaling, security |
| Data residency | n8n's infrastructure and chosen region | Your account, your region, your VPC |
| Compliance control | Vendor's certifications and DPA | Full control; fits strict GDPR / localisation needs |
| Scaling model | Upgrade a plan | Queue mode with Redis + workers |
| Custom nodes / packages | Limited on shared tiers | Full control, any npm dependency |
| Best for | Fast starts, small ops teams, low-to-medium volume | High volume, sensitive data, deep integration |
Which should your team choose?
Choose n8n Cloud if you want automations live this week, your execution volume is modest and predictable, and you have no dedicated platform engineer to spare. It is the correct default for early validation — prove the workflows earn their keep before you invest in infrastructure. It also suits teams whose data has no hard residency constraints.
Choose self-hosted when any of these are true:
- Your execution volume is high enough that per-execution pricing would exceed the cost of running a server.
- You handle regulated or sensitive data and need it to stay inside your own AWS account and region.
- Your workflows must reach private internal systems that never touch the public internet.
- You need custom community nodes, specific npm packages, or Enterprise features on your own terms.
A pragmatic path many teams take: start on Cloud, migrate to self-hosted once volume or compliance forces the issue. Because the engine is identical, workflows export and import cleanly — the migration is an infrastructure project, not a rebuild. If you already know your data can't leave your account, skip the round trip and self-host from day one.
Whichever you pick, the hosting decision is upstream of everything else you'll build. Once the platform is stable you can move on to the interesting work — standing up your first AI agent in n8n, or wiring up an automated customer-onboarding workflow that runs without anyone watching it. And if you're still deciding whether workflow automation belongs at the centre of your operations at all, our guide to agentic AI for business frames where it pays off.
How ILMTEC helps
ILMTEC sets up and manages self-hosted n8n on your own AWS account, so you keep full ownership of the data and the bill while we own the hard parts: a hardened deployment with RDS Postgres, queue mode for scale, TLS and SSO, secrets management, backups, and a tested update path. It is the same discipline we bring to building production AI applications and agent workflows — infrastructure that a founder or CTO can trust in production, delivered in fixed six-week cycles across our Pune, Dubai, and Berlin teams. If you want n8n running securely in your cloud without hiring a platform team to babysit it, that is exactly the gap we close.
