Best n8n hosting options in 2026
The question is not which host is cheapest. It is who owns Postgres, queue mode, and the 2am upgrade when a workflow stalls.
The short answer
n8n Cloud is right until a workflow touches a private database or runs often enough that execution billing bites. Past that point, a self-managed VPS with Docker Compose, Postgres, and queue mode is the honest production setup.
n8n's own docs are blunt about the default: SQLite ships out of the box and is not recommended for production. Queue mode is documented as needing Postgres 13 or later, plus Redis as the message broker. Hosting is really a decision about who carries that stack.
We run n8n for Little Tree Confections' meeting-to-action pipeline. It reads the client's live task structure, and that is the kind of job that decides this ranking. It touches real data, so it runs on infrastructure we control.
How this ranking was made
Verified
We ranked four ways to run n8n on what a production workflow actually needs, not on sticker price. A workflow that touches customer data, runs on a schedule, or has to survive a failed step needs Postgres. Past a handful of concurrent users, it needs queue mode with Redis workers too.
Pricing and feature claims were read from n8n's own documentation and each host's pricing page on 14 August 2026, and are linked in each entry. We host n8n for a client in production, and that experience sets the criteria below.
- Data residency
- Whether the workflow's data ever leaves infrastructure you control.
- What breaks the billing model
- Execution count, active workflows, or nothing at all.
- Who owns the upgrade
- You, a platform's build pipeline, or nobody until something breaks.
- Path to queue mode
- How far you get before Redis and worker processes stop being optional.
The four at a glance
Read from n8n's documentation and each host's pricing page on 14 August 2026.
| Option | Who owns the database | Billed on | Best moment to pick it |
|---|---|---|---|
| n8n Cloud | n8n | Executions per month | You want zero infrastructure and no private data |
| Railway (managed platform) | You, provisioned automatically | Compute and database usage | You want Postgres and Redis without writing the compose file |
| Self-managed VPS + Docker | You, fully | The server, flat | The workflow touches a private database |
| Kubernetes + Helm chart | Your platform team | Cluster capacity, flat | You already run workloads on Kubernetes |
The ranking
Order reflects how many teams each one is right for, not raw capability.
Postgres, queue mode, and the data stay where you put them
This is where every production instance we run ends up. n8n's own guidance recommends Docker for self-hosting because it isolates the app from operating-system quirks and makes database management simpler. Docker Compose is the documented path for a setup with a real database and extra services, rather than one process running alone.
Best for
- Workflows that read or write a private database
- Teams that need queue mode and are willing to run Redis
- Anyone who needs a clear answer to "where does the data live"
Not for
- Teams with nobody willing to own an upgrade schedule
- Low-volume workflows against public SaaS tools only
- Database
- Postgres 13+, self-managed
- Scaling path
- Queue mode: Redis broker, separate workers
- Minimum spec
- 2 vCPU, 4GB RAM for queue mode
The Docker Compose stack, provisioned for you
Railway's n8n template deploys Postgres, Redis, and worker processes together with no compose file to write. It is the same architecture as the option above, minus the afternoon spent debugging environment variables.
You still own the data and the upgrade decision, since the containers run in your Railway project. What you give up is the fine-grained server control a bare VPS gives you. In exchange, the bill scales with usage instead of staying flat.
Best for
- Teams who want Postgres and queue mode without writing infrastructure
- A first production instance before hiring anyone to own a VPS
Not for
- Workloads where a predictable flat cost matters more than convenience
- Teams that already have a VPS or Kubernetes habit
- Setup
- One-click template, Postgres and Redis included
- Billed on
- Compute and database usage
No infrastructure, execution-based billing
Pick this to get moving before any of the hosting questions matter. There is nothing to patch and nothing to back up. n8n's pricing counts one execution per whole workflow run rather than per step, so a small number of long workflows costs little.
The trade is that a private database now sits behind a third party's infrastructure. A workflow that runs often will also hit the execution ceiling sooner than it feels expensive. Neither is a flaw. Both are reasons to move once the workflow gets serious.
Best for
- A first workflow, or a prototype before anything is decided
- Automation that only touches public SaaS tools
Not for
- Workflows that read or write a private or customer database
- High-frequency workflows, where execution billing adds up fastest
- Runs as
- Fully managed, n8n's infrastructure
- Billed on
- Executions per month
For teams already running everything else this way
n8n publishes an official Helm chart. It is the right choice for one situation. A platform team that already runs its other services on Kubernetes, and does not want n8n to be the exception.
It ranks last only because it is the most machinery for a tool that does not usually need it. A single client-facing automation almost never justifies a cluster. Adopt this path because you already have one, not because n8n asked for it.
Best for
- Platform teams standardising every workload on Kubernetes
- Multiple n8n instances across environments, managed the same way
Not for
- A single production workflow with no cluster already in place
- Teams without someone who already operates Kubernetes
- Deployment
- Official Helm chart
- Fit
- Existing Kubernetes platforms only
- n8nThe editor and the API.
- PostgresRequired past SQLite. Workflows and credentials live here.
- RedisThe queue-mode broker, once volume needs it.
- WorkersSeparate processes that actually run each workflow.
- UpgradesThe recurring cost every hosting choice is really about.
The host you pick decides who is responsible for each of these, not whether they exist.
When none of these is the answer
A workflow that needs guaranteed execution, retries with backoff, and a durable record of every attempt has outgrown n8n itself. Hosting will not fix that. n8n has no durable replay: a failed run in the middle of a long workflow gets re-triggered, not resumed. That is fine for most automation and wrong for anything where a missed step has real consequences.
If that is your workflow, the fix is not a bigger server. It is a job queue built for durable execution, with n8n or a code service sitting in front of it.
- 01If the answer to a failed run has to be provably recoverable, this is the wrong tool regardless of host.
- 02If the workflow runs a handful of times a day against public SaaS only, n8n Cloud is simpler than any self-hosted option.
- 03If nobody on the team will own upgrades, budget for someone who will before you self-host anything.
n8n hosted and running unattended, in production
Not sure which host fits your workflow?
Tell us what the workflow touches and how often it runs. We will name the setup we would use and why, on a scoping call that costs nothing.
Questions buyers ask
01Is n8n Cloud good enough for production?
Yes, for the right workload. It suits automation that never touches a private database and runs infrequently enough that execution-based billing stays cheap. Once either condition stops being true, a self-managed instance is the better production fit.
02Can I start on n8n Cloud and move later?
Yes. Workflows export as JSON and the logic inside code nodes is ordinary JavaScript, so both port to a self-hosted instance. What does not port automatically is the credentials and connections, which have to be re-added on the new host.
03Do I need Redis and queue mode from day one?
No. n8n runs fine in regular mode for low-to-moderate volume. Queue mode becomes necessary once concurrent executions start backing up behind each other. n8n's own benchmarks show a large throughput gain once workers take over from a single process.
04Why does self-hosting outrank the managed platforms here?
Because most of the workflows worth automating touch a database somebody cares about. Once that is true, data residency stops being optional. The ranking follows what the workflow needs, not what is fastest to click through.
05What does self-hosting cost in effort, not money?
A container, a Postgres database, and someone who owns upgrades. Scaling past one instance adds Redis and worker processes. The honest cost is ongoing attention, not a one-time setup.
Related reading
- n8n, reviewed from production use →What it does well and where it stops being the right tool.
- What to use when you outgrow n8n →Temporal, Windmill, and Make, and when the honest answer is to stay.
- Hire n8n developers →Engineers who treat workflows as code, not a canvas nobody reviews.
- Business process automation →How we build automation that runs unattended.
