Self-Hosted n8n vs n8n Cloud - The Cost Breakdown at 1K, 10K, and 100K Executions

Why ops time is the cost everyone skips in these comparisons

Every n8n self-hosted vs cloud comparison shows the same table: VPS at $12 to $20 per month, n8n Cloud at $24 to $50 per month, conclusion obvious. What those tables do not show is the hour or two per month you will spend on updates, SSL renewals, backup verification, and the occasional "why did that execution hang" investigation. That time has a cost, and if you skip it in the math, you will make the wrong call.

The honest version of the comparison has three inputs: the subscription or VPS cost, the monthly ops hours, and your real cost per ops hour. If you are a solo operator where an hour of your time is worth $200, two hours of self-hosted ops per month is $400. At that rate, n8n Cloud wins until you are well past 50K executions per month. If you have a junior ops person at $30 per hour who handles infrastructure, two hours is $60, and self-hosted wins much earlier in the cost curve. Run the comparison with your actual numbers, not the simplified table.

At 1K executions per month: cloud wins

At 1,000 executions per month, you are firmly in n8n Cloud Starter territory. The Starter plan covers this volume at $24 per month. Zero infrastructure. Zero ops overhead. Automatic updates. SSL handled. If something breaks, support is a ticket away rather than a debugging session on a VPS at 11pm.

Self-hosted at this volume costs you $12 to $15 on a Hetzner CX21 or equivalent DigitalOcean droplet, plus the initial setup time (typically two to four hours the first time you do it), plus ongoing ops. The math only works in self-hosted's favor if your ops time is essentially free. For most people, it is not.

The right call at 1K executions per month is n8n Cloud unless you already run your own infrastructure and adding n8n to it is a minimal incremental lift. If you are starting fresh, do not spin up a VPS to save $10 per month.

At 10K executions per month: break-even territory

At 10,000 executions per month, the comparison gets interesting. n8n Cloud Pro covers this volume at around $50 per month. A Hetzner CX21 or DigitalOcean Basic 2GB costs $12 to $15 per month. The raw infrastructure delta is $35 to $38 per month, and the question is whether your ops time costs more than that.

If your ops overhead is realistically two hours per month at a blended rate above $17 per hour, cloud is still cheaper when you count the full cost. Most operators in the $1M to $20M range are not running automation infrastructure personally; they have someone on the team handling it. If that person can absorb n8n maintenance without meaningful opportunity cost, self-hosted wins here. If every ops hour is pulled off revenue-generating work, run the number honestly before committing.

The break-even point, including two hours per month of ops time, sits around $15 to $18 per ops hour. Below that rate, self-hosted wins. Above it, cloud wins. Most teams in this volume range will find themselves near or above break-even, which is why this is genuinely contested territory rather than a clear call either way.

At 100K executions per month: self-hosted wins decisively

At 100,000 executions per month, the economics shift clearly. n8n Cloud Pro at this volume is around $200 per month. A Hetzner CX41 (4 vCPU, 16GB RAM) runs around $17 per month. With four hours per month of ops time, even at $100 per hour, self-hosted costs $417 per month total. At $50 per hour, it is $217. At $30 per hour, it is $137. Teams managing this kind of scale typically face the architectural challenges covered in n8n at 10x spike, where queue mode and monitoring become essential.

The savings are significant and durable. At this volume you will also want Postgres rather than SQLite, a daily backup strategy, and Redis queue mode if your workflows have any significant duration. Those setup requirements add to your initial investment but not to your monthly ops overhead once they are configured correctly. A well-configured self-hosted instance at 100K executions per month is stable infrastructure that runs mostly unattended.

The total cost comparison at scale, including estimated ops time at $50 per hour:

At 100K executions, the self-hosted ops burden grows to about four hours per month, and cloud and self-hosted total cost are roughly equivalent at $50 per ops hour. Above 100K, self-hosted wins by a widening margin regardless of ops rate.

What self-hosted n8n actually requires in 2026

The official Docker setup is the right starting point. You need a Linux host running Ubuntu 22.04 LTS or newer, Docker and Docker Compose installed, and a Postgres instance (either on the same host or managed). Postgres handles concurrent execution without the contention issues SQLite has at scale, and recovery from a Postgres backup is straightforward. SQLite is acceptable for evaluation or very low volume but should not be your production choice if you expect to grow.

SSL via Let's Encrypt with certbot or a reverse proxy like Caddy handles certificate management. Caddy automatic HTTPS is particularly clean here; it handles renewals without cron jobs and integrates with Docker Compose in a way that makes the setup readable. Your n8n instance should never be exposed on plain HTTP in production.

Docker Compose with restart: always on the n8n and Postgres containers covers process management. On a clean host, the full setup from a blank VPS to a running n8n instance is about 45 minutes if you follow the official docs. After that, your main maintenance task is updating the Docker image tag in your Compose file when a new n8n version releases. Do not run latest; pin to a specific version tag so you control when upgrades happen.

The Redis queue mode threshold

At under 50K executions per month and with workflows that complete in under 30 seconds, the standard n8n main-process mode handles the load without issues. Past 50K executions per month, or if you have workflows that run for longer than 30 seconds, you should move to queue mode.

Queue mode separates the main n8n instance, which handles the UI and triggers, from one or more worker containers that execute workflows. A Redis instance holds the job queue between them. The setup requires adding a Redis service to your Docker Compose file, configuring the worker containers, and setting the queue-related environment variables in n8n. The n8n docs walk through this in detail. It is about two additional hours of setup work but significantly improves reliability and throughput for high-volume or long-running workflows.

The practical signal that you need queue mode is execution timeouts or missed triggers during high-load periods. If your main process is handling both UI traffic and workflow execution under heavy load, one will starve the other. Queue mode eliminates that contention.

Backup and recovery: what you actually need

Daily Postgres backups encrypted off-site are the baseline. pg_dump with a cron job writing to an S3-compatible bucket covers this. If your VPS provider offers managed snapshots, use those as a secondary layer, not a substitute. Test a restore at least quarterly. Backups you have not tested are not actually backups; they are files with unknown integrity.

Workflow export to a Git repository is the second layer and is often skipped. n8n's CLI supports workflow export, and a daily cron job that exports all workflows to JSON and commits to a private repository gives you version history plus the ability to recover workflows independent of the database. If you accidentally delete a workflow or need to audit what changed, the Git history is the fastest path.

Credential backups require more care. Credentials in n8n are stored encrypted in the database with a key derived from N8N_ENCRYPTION_KEY. If you lose that key, your credential backup is unreadable. The environment variable file that contains that key needs to be backed up separately, encrypted, and stored somewhere that is not the same VPS. Losing the encryption key is an unrecoverable credential loss, which means needing to re-authenticate every connected service. That is a painful afternoon. Store the key backup correctly.

When to NOT self-host regardless of cost

If no one on your team is comfortable running a Linux VPS, do not self-host n8n. The ops overhead calculation assumes someone who can SSH into a server, read Docker logs, run a Postgres query to diagnose a stuck execution, and troubleshoot a certificate renewal failure. If that skill is not available, the ops tax becomes an incident tax. One outage that takes six hours to diagnose and resolve because nobody knows the infrastructure erases months of cost savings.

The honest path in that situation is n8n Cloud, or a managed hosting provider like Elestio that handles infrastructure while giving you a dedicated instance. You pay a premium for that management layer, but the alternative is being dependent on someone outside your team every time something goes wrong. For teams that genuinely do not have infrastructure comfort, cloud is not a compromise; it is the right answer for your risk profile.

Not sure which side of the curve you are on? Run the AI Operations X-Ray to see where your automation costs actually land and whether self-hosted n8n makes sense at your current volume.