n8n is a fair-code workflow automation tool you can run on a server in your office, a VPS you control, or a Kubernetes cluster in your private cloud. The hosted version, n8n Cloud, is fine for a lot of teams. The self-hosted version is a different proposition. It trades money for time, and it adds operational responsibility that you do not get with Zapier or Make. Whether that trade is worth it depends on three things: how much your data matters, how many tasks you run, and whether you have someone on the team who can keep a Docker container healthy.
This guide is the honest version of that trade. It covers the cost math, the real maintenance burden, the deployment patterns that work in 2026, and the cases where self-hosting is the wrong call. If you finish reading and you are still unsure, the decision matrix at the bottom will help you pick.
What n8n is, and what changed in 2025
n8n started in 2019 as a side project by Jan Oberhauser and is now maintained by n8n GmbH, a Berlin-based company. The platform is a node-based visual workflow builder, similar in concept to Zapier and Make, but the source code is published under a Sustainable Use License that allows self-hosting for most commercial uses. There is also an Enterprise plan with a different license if you want to embed n8n in a paid product.
The shape of the product matters. A workflow in n8n is a directed graph of nodes, where each node is a service, an HTTP request, a database query, a function, or one of more than 400 built-in integrations. You connect them, set conditions, and the engine runs the graph on a trigger, a schedule, or a webhook. The visual model is the same in the cloud and self-hosted editions. The differences are who runs the engine, who stores the credentials and execution logs, and what the scaling limits look like.
In March 2025, n8n raised a $60M Series B led by Accel to push the product into the enterprise space (TechCrunch). That investment funded features that matter for self-hosted operators: native queue mode with Redis, a dedicated database backend, hardened Docker images, and SSO support in the community edition. The result is that the gap between n8n Cloud and a self-hosted instance, in terms of feature parity, is much smaller than it was 18 months ago. Today the main differences are operational, not functional.
The honest case for self-hosting
There are three reasons teams self-host n8n, and the strength of each reason varies a lot by industry.
Data residency and compliance. If you are in healthcare, finance, legal, or any industry that handles PII or PHI under HIPAA, GDPR, or SOC 2, the data question is not a nice-to-have. It is the whole game. A hosted automation platform receives every API key, every payload, and every execution log for every workflow that touches your stack. Most of these platforms publish SOC 2 reports and sign DPAs, but your auditor may still want to know where the data physically sits. Self-hosted n8n running on infrastructure you own answers that question with one sentence. For teams in regulated industries, that is often the entire justification.
Cost at volume. Zapier's pricing is per task. Make's pricing is per operation. n8n Cloud's pricing is per workflow execution. At low volume, the hosted products are cheaper because you do not have to pay anyone to keep a server running. At high volume, the math flips. A self-hosted n8n instance on a $40/month Hetzner or DigitalOcean VPS, plus a few hours of setup, can run tens of thousands of executions a month for less than a single Zapier Professional plan. The break-even point depends on your task count and your time-cost, but for teams running more than 50,000 task-equivalent operations per month, self-hosting usually wins on direct cost.
Customization and control. n8n is open source. You can add custom nodes, fork the engine, integrate with internal services that do not have public APIs, run workflows on internal networks that hosted platforms cannot reach, and inspect every line of the execution path. For engineering teams that treat automation as part of their platform, this is the difference between renting someone else's tool and owning a piece of infrastructure.
<figure> <img src="/blog/img/n8n-self-hosted-automation-when-it-makes-sense-3.webp" alt="Vintage tin-toy robot standing inside an open data vault with glowing blue data crystals on shelves, one claw hand on a stack of data and the other raised in a 'data stays here' gesture" width="2000" height="1125" loading="lazy"> </figure>The honest case for staying hosted
The flip side matters too, and it is the part that gets glossed over in n8n marketing material.
You are on the hook for the stack. A self-hosted n8n instance is a Node.js process, a Postgres or SQLite database, a Redis instance if you want queue mode, a reverse proxy with TLS, a backup system, a monitoring layer, and a process supervisor. If any of those breaks at 2am, you are the one fixing it. Hosted platforms absorb that burden, and for most small businesses, the cost of those few hours a month of operational work is more than the hosted subscription would be.
Updates and security patches. n8n ships releases every two to three weeks. Some of those releases are security patches, and missing them is a real risk because n8n workflows often hold credentials to high-value services. The fair-code license does not auto-update your instance. You need a watchpoint: an RSS subscription, a calendar reminder, a Renovate config, or a managed update service like n8n's own "easy upgrade" tooling. If you forget, you are the only one standing between your credentials and a public CVE.
Scalability ceilings. n8n can scale, but it takes work. The default single-process mode is fine for a small business. Queue mode with Redis and multiple workers is the production setup, and it requires you to think about resource limits, queue depth alerts, database connection pooling, and worker recycling. A hosted platform handles that for you. A self-hosted instance asks you to do it.
No SLA. When n8n Cloud goes down, you can call support. When your self-hosted instance goes down, you read the logs, check the disk, restart the container, and post in the forum. For most teams that is a feature, not a bug. For some, it is a deal-breaker.
Self-hosting n8n is not free. It is a different bill. You trade monthly subscription cost for time spent operating, securing, and updating a server.
The cost picture, in actual numbers
Let me put rough numbers on the trade. These will vary by region and provider, but the shape is consistent.
A minimal production self-hosted n8n setup in 2026 looks like this:
| Component | Spec | Monthly cost (USD) |
|---|---|---|
| VPS (4 vCPU, 8 GB RAM, 160 GB SSD) | Hetzner CPX31 or DO droplet | 15 to 40 |
| Managed Postgres (or self-hosted) | 1 GB RAM, 10 GB storage | 0 to 30 |
| Managed Redis (queue mode) | 256 MB, low traffic | 0 to 10 |
| S3-compatible object storage (backups) | 50 GB | 1 to 5 |
| Domain + TLS | Let's Encrypt + registrar | 0 to 2 |
| Monitoring (UptimeRobot Pro + a log drain) | 5 monitors, 1 app | 0 to 13 |
| Total | 20 to 100 |
Now compare that to the hosted side. n8n Cloud's Pro plan is currently €24/month for 10,000 executions; the Enterprise plan, which is what you need for SSO, audit logs, and SLA, is custom-priced and starts around €800/month for production workloads. Zapier's Team plan is $103.50/month for 2,000 tasks and ramps hard from there. Make's Core plan is $10.59/month for 10,000 operations, but usage scales aggressively as you add more scenarios.
For a small business running 5,000 executions a month on a handful of low-stakes workflows, n8n Cloud or Make is cheaper. For a team running 100,000 executions a month, self-hosting is between 4x and 30x cheaper, depending on what you compare it to. The breakeven point on direct cost is somewhere in the 15,000 to 30,000 executions per month range, once you account for the operational overhead.
The thing the hosted-vs-self-hosted comparison misses is time. A reasonable estimate is that a self-hosted n8n instance takes 4 to 8 hours for the initial setup, 1 to 2 hours per month for maintenance, and an extra 4 to 8 hours per year for major version upgrades. At a fully loaded engineering rate of $100/hour, that is $2,000 to $4,000 in year-one labor, on top of the hosting cost. If you do not have someone on the team who can absorb that, the hosted product is the cheaper choice, even at higher volume.
A deployment that actually works in 2026
If you decide self-hosting is the right move, the deployment pattern that works today is much simpler than it was a year ago. Here is the version I would ship.
Use Docker Compose, not Kubernetes, unless you already have a K8s platform. A self-hosted n8n instance for a small business does not need Kubernetes. A single host with Docker Compose, a managed Postgres, and a managed Redis is enough until you cross roughly 100,000 executions a month or need 99.9% uptime. If you have a K8s platform team, the n8n Helm chart is solid. If you do not, do not introduce K8s for one app.
Run queue mode from day one. Even at low volume, queue mode gives you cleaner failure isolation and a real upgrade path. The cost is one extra Redis instance. The benefit is that when you scale to multiple workers next year, you do not have to migrate the architecture.
Postgres, not SQLite. SQLite is fine for development and the n8n docs list it as a supported production database. For anything that matters, use Postgres. It is what the queue mode story assumes, it is what the backup tooling assumes, and it is what the scaling story assumes.
Backups, automated, with restore testing. Back up the n8n database and the credentials file. Test the restore procedure once a quarter. The most common cause of data loss on a self-hosted n8n instance is a Postgres disk fill that nobody noticed, not a security event.
Updates, on a schedule, with a notification. Subscribe to the n8n releases feed (GitHub) and pin a monthly maintenance window. Security patches go in the next window. Major versions wait for a planned upgrade with a backup taken first.
Reverse proxy with TLS and a real auth layer in front. n8n's built-in user management is fine for small teams. For anything that touches production data, put it behind a reverse proxy with rate limiting, fail2ban, and SSO (OIDC or SAML). The Enterprise license unlocks some of this in-app, but a proxy is the simpler layer for most teams.
<figure> <img src="/blog/img/n8n-self-hosted-automation-when-it-makes-sense-2.webp" alt="Vintage tin-toy robot sitting at a developer desk in front of a large monitor displaying a node-based visual workflow canvas, claw hand reaching toward a node on the screen" width="2000" height="1125" loading="lazy"> </figure>A minimal docker-compose.yml that hits the main requirements:
services:
n8n:
image: n8nio/n8n:latest
restart: always
environment:
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
- DB_POSTGRESDB_USER=${POSTGRES_USER}
- DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
- QUEUE_BULL_REDIS_HOST=redis
- EXECUTIONS_MODE=queue
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
- WEBHOOK_URL=https://n8n.example.com
volumes:
- n8n_data:/home/node/.n8n
depends_on:
- postgres
- redis
postgres:
image: postgres:16
restart: always
environment:
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
volumes:
- pg_data:/var/lib/postgresql/data
redis:
image: redis:7-alpine
restart: always
volumes:
n8n_data:
pg_data:
This is the shape, not a copy-paste recipe. Generate the N8N_ENCRYPTION_KEY with openssl rand -hex 32 and store it in a secrets manager, not in the same file as the compose config.
When to stay hosted
You should not self-host n8n if any of these describe your situation.
You are running fewer than 10,000 executions a month, and your workflows do not touch regulated data. The cost savings will not pay for the operational burden. Use n8n Cloud, Make, or Zapier and move on.
You do not have a team member who can run a Linux server. The "I'll figure it out when something breaks" approach is how self-hosted automation instances become attack vectors. If you do not have the operational depth, hosted is the right call.
You need an SLA for a customer-facing automation. Self-hosted n8n is as reliable as the team that runs it. Hosted platforms are as reliable as the platform company. Pick the one that matches the stakes of the workflow.
You want to spend your time on workflows, not on infrastructure. Self-hosting is a side project disguised as a tool. Hosted is a tool. Both are valid choices, and pretending the operational work is free is how automation projects stall.
When to self-host
The case flips, hard, in three situations.
You are in a regulated industry and your data cannot leave your perimeter. Healthcare, finance, legal, government, defense. The compliance case is the entire case.
You are running 50,000 or more executions a month and the hosted bill is meaningful. At that volume, the cost math is unambiguous, and the operational burden is amortized across the work it does.
You have an engineering team that treats automation as part of the platform. For a team that already runs Postgres, Redis, and Docker in production, adding n8n is a small increment. For a team that does not, it is a different story.
The decision matrix
If you have read this far and you are still unsure, the table below is the short version.
| Situation | Recommendation | Why |
|---|---|---|
| Under 10,000 executions/month, no compliance pressure | Hosted (n8n Cloud, Make, or Zapier) | Operational cost exceeds subscription cost |
| 10,000 to 50,000 executions/month, no compliance pressure | Either, depending on engineering capacity | Cost is a wash once you count time |
| 50,000+ executions/month, no compliance pressure | Self-host | Direct cost is 4x to 30x lower |
| Any volume, regulated data (HIPAA, GDPR, SOC 2) | Self-host with a hardened setup | Data residency is non-negotiable |
| Customer-facing automation with an SLA | Hosted Enterprise or managed self-host | You need a phone number to call |
| No one on the team has run a Linux server in production | Hosted | The operational cost will be larger than the subscription cost |
| Engineering team already runs Postgres and Docker in production | Self-host | The operational delta is small |
Where to go from here
If you are leaning toward self-hosting, the fastest way to validate the decision is a one-week pilot. Spin up the smallest VPS your provider offers, deploy the compose stack above, move over one non-critical workflow from your hosted platform, and watch what breaks. Most teams learn in a week whether the operational fit is right.
If you are leaning toward hosted, the question is which platform. n8n Cloud is the obvious choice if you want to keep the workflow definitions portable. Make is the cheapest at low volume. Zapier has the broadest integration catalog. All three are fine for most small businesses.
The decision is not really about the tool. It is about what your team is set up to operate. Pick the one that matches your real constraints, and stop overthinking the framework question. The workflows are what matter.