n8n Self-Hosted: The Real Cost and Maintenance Tax After Day One (2026)

n8n self-hosted is free the way a puppy is free. The licence costs nothing, the VPS costs about the price of a coffee, and the install genuinely does take an afternoon. Then day two arrives, and you find out what you actually signed up for.

I run automation in production on my own box. Not a demo, not a tutorial — a fleet of autonomous brand containers that published this post while I was asleep. So this is not a “5 ways to deploy” article. The deploy is the easy part, and I will give it to you fast. The rest of this guide is the part nobody on page one publishes: what n8n self-hosted costs you in hours, where it quietly walls you off, and when n8n Cloud is simply the cheaper answer.

Every number below was measured on the day of writing — 2 October 2026 — against n8n’s own docs, its pricing page, and the n8n GitHub release feed. Where I disagree with a page currently ranking for n8n self-hosted, I name it.

What “n8n self-hosted” actually gets you (and what the official docs’ 514 words leave out)

n8n self-hosted means you run the n8n service on infrastructure you control — your VPS, your container, your database — instead of paying n8n to run it for you. You get the full workflow editor, unlimited workflows, and almost the entire feature set, with no execution cap and no per-seat bill. That part is real, and it is the reason I do it.

Here is the part that surprised me. The official “Host n8n” page — the number-one result in Google for this term — is 514 words and three headings. I counted it the morning I wrote this. It is a menu: Docker, npm, or one of the cloud marketplaces, pick one. Searched for the words a self-hoster actually needs, it returns nothing at all:

• “backup” — 0 occurrences
• “upgrade” — 0
• “queue mode” — 0
• “credential” — 0
• “Postgres” — 0
• “maintenance” — 0

Those words live on other pages in the docs, and I will link the good ones as we go. But the page that ranks for “how do I self-host this” answers only “here is how to start it,” and that framing propagates. It is also why the number-two result in Google is a disappointed Reddit thread — “anyone using n8n self-hosted? I tried it and I’m disappointed” — sits directly beneath the official documentation. When a forum complaint outranks six vendor guides, the guides are answering the wrong question.

If you are still deciding whether n8n is the right tool at all, start with my operator’s field guide to what n8n is and come back. This page assumes you have decided yes and are now asking where should it run.

The day-one deploy: Docker, Postgres, and a reverse proxy

I am going to be honest in a way the hosting companies cannot afford to be: the install is easy. It is genuinely a one-evening job for anyone who has used a terminal. Padding this section would be dishonest, so here is the whole shape of it.

You need four things on a small VPS:

1. Docker, running the official n8n image.
2. PostgreSQL instead of the default SQLite — do this on day one, not later. SQLite is fine until it is the thing standing between you and a restore, and migrating a live instance is strictly worse than starting right.
3. A reverse proxy with automatic HTTPS — Caddy or Traefik will do it in a few lines. n8n needs a real hostname for OAuth callbacks and webhooks to work.
4. A persistent volume for n8n’s data directory, and a real backup of your Postgres database. More on that in a moment, because this is where people get hurt.

Sizing: a solo operator’s workload runs comfortably on a 2 vCPU / 4 GB box. A 1 GB instance will work right up until two workflows with large payloads overlap, which is a miserable way to learn about memory.

That is the part every page-one result covers, and most cover it well. Every one of them also ends there — Northflank’s guide finishes with “Deploy on Northflank for free,” Sliplane’s with “Deploy n8n without managing Ubuntu,” and Hostinger’s headings are literally VPS plan names. Their tutorials are accurate; the omission is structural. Nobody on page one gets paid for the chapter about month six.

The maintenance tax nobody quotes you: 49 releases in 30 days

Here is the number that reframes the whole decision. I pulled the n8n GitHub release feed on 1 October 2026 and counted:

• 49 releases in the previous 30 days.
• 100 releases since 24 July 2026 — roughly ten weeks.
• Latest stable at the time of writing: n8n@2.41.5, published that morning, with 2.42.2 already in beta.
• And a still-maintained 1.x line — n8n@1.123.83 shipped the day before — so there are two active major branches to have an opinion about.

That cadence is a sign of a healthy, fast-moving project. It is also your problem now. On n8n Cloud, 49 releases in a month is someone else’s deployment pipeline. Self-hosted, it is a standing decision you have to make: pin a version and consciously fall behind, or track :latest and accept that a workflow you depend on can change behaviour on a Tuesday.

Pin your version. Use a specific tag, never :latest. This is the single highest-value habit in self-hosting anything, and the reason is not theoretical: :latest means your next unrelated docker compose pull silently becomes a major upgrade. Pin the tag, read the release notes, upgrade deliberately, and keep the previous tag so a rollback is one line instead of one evening.

Then there is the work that has no release notes at all:

• Postgres backups you own. Nobody is taking them for you. A nightly pg_dump to off-box storage is twenty minutes of setup and it is the difference between an incident and a catastrophe. Test the restore — an untested backup is a rumour.
• Credential rotation. Every OAuth token and API key your workflows use expires on somebody else’s schedule. This is the genuinely absent topic: I searched every page ranking for this term and found zero coverage of credential rotation.
• The encryption key. N8N_ENCRYPTION_KEY is what decrypts the credentials stored in your database. Rotate it after you have saved credentials and you silently orphan all of them — n8n will still start, and nothing will work. Back that key up separately from the database, because together they are the whole vault and either one alone is useless.
• OS patching, disk, TLS renewal, and the 3am reboot. Does your stack come back up unattended? If you have not tested docker compose restart policies by actually rebooting the box, you do not know.

Credit where it is due: two pages do cover some of this, and both sit lower in the results than they deserve. vps.us runs 3,700 words with a section honestly titled “The PostgreSQL Gotcha Nobody Sizes For,” plus real maintenance and security checklists; Sliplane covers updating and backups properly.

What survives is narrower and more useful: they price the work in checklists, not in hours. The word “hour” does not appear once in that 3,700-word guide. A checklist tells you what to do; it does not tell you that you are now the on-call engineer. That is the number that decides an n8n self-hosted deployment, so I put one on it below.

The Community edition walls nobody mentions until you hit one

“Self-hosted n8n is the full product” is almost true, and the almost is expensive. From n8n’s own edition comparison, the free Community edition excludes:

• Sharing workflows and credentials. In n8n’s words, only the instance owner and the user who created them can access them. This is the wall that bites hardest and gets mentioned least — the day you want a contractor to touch one workflow without handing over your whole instance, you are on a paid plan.
• Projects — no folder-level separation of client or team work.
• Git version control and environments — no staging-to-production promotion, no workflow history in a repo.
• SSO (SAML, LDAP) — fine solo, a blocker the moment a compliance questionnaire appears.
• External secret stores and external binary-data storage.
• Log streaming to an external system. Ordinary logging is included.
• Multi-main mode — the high-availability setup where more than one main instance runs at once.

One free win most people miss: register your Community instance with an email address and you get a free licence key that unlocks folders, debug-in-editor, and custom execution data. It costs nothing and takes a minute, and no page in this SERP mentions it.

Read that exclusion list as a forecast, not a feature table. Solo, almost none of it matters. The moment a second human needs access, three of those lines become the reason you upgrade — and the trigger is team shape, not workflow volume.

When queue mode stops being optional (and the €667 confusion worth clearing up)

By default, your single n8n process handles triggers and runs the workflows. Queue mode splits that: one main instance receives triggers and queues executions through Redis, and separate worker processes pick them up and run them. You add workers to scale out, remove them to scale in.

You need it when any of these is true: executions start queueing behind each other and latency becomes visible; a single long-running workflow blocks everything else; or you need to restart the main instance without killing in-flight work. Below that, queue mode is three more moving parts for no benefit — do not deploy it because a tutorial made it look impressive.

Now the confusion, and it is n8n’s own documents disagreeing with each other. The pricing page lists “Queue mode for scaling” as a feature of the Business plan at €667/month. The edition docs say the opposite, explicitly and in parentheses: Community edition excludes multi-main mode — “Queue mode is included.”

What Business actually adds is multi-main — redundancy for the main instance itself — not the worker split. But the docs page also tells you “the pricing page is the source of truth,” and a reader following that instruction concludes they must pay €8,000 a year for something already sitting in the free edition. Queue mode works on Community. Multi-main does not. I checked both pages the day I published this; re-check before you budget, and believe the docs on what the software does.

Three sharp edges in the queue-mode setup, all from n8n’s own documentation:

• Every worker needs the same N8N_ENCRYPTION_KEY as the main instance, or workers cannot decrypt credentials from the database. Symptom: the queue drains and every execution fails on authentication.
• Queue mode with SQLite is not recommended by n8n. In practice, queue mode means Postgres — another reason to start there.
• Queue mode does not support filesystem binary-data storage. If your workflows persist binary files, you need S3 external storage — and external binary storage is not in Community edition. That is a chain worth tracing before you commit: scale out, hit the binary-data wall, and the fix is a paid plan.

And one security trap that is genuinely nobody’s fault but will absolutely be your incident. n8n’s docs start Redis with docker run --name some-redis -p 6379:6379 -d redis, and note that Redis by default runs with no password. Meanwhile Docker’s published ports bypass ufw — Docker’s own networking documentation says traffic to a published container port “gets diverted before it goes through the ufw firewall settings.” Put those two facts together on a public VPS and you have an open, unauthenticated Redis holding your execution queue, behind a firewall that reports itself as closed. Bind it locally (-p 127.0.0.1:6379:6379), set QUEUE_BULL_REDIS_PASSWORD, or keep Redis on a private network. I found this edge auditing a popular n8n starter template, and wrote it up in detail in my teardown of the self-hosted AI starter kit.

What n8n self-hosted really costs vs n8n Cloud, in dollars and in hours

Dollars first, from n8n’s pricing page on the day of writing. Annual billing, which saves 17%:

• Starter — €20/month: 2,500 workflow executions, 5 concurrent, 1 shared project.
• Pro — €50/month: 10,000 executions, up to 50 concurrent, 3 projects, workflow history, 7 days of insights.
• Business — €667/month: 40,000 executions, SSO, Git version control, multiple environments. Note this one is marked self-hosted only; the Cloud version is a waitlist form.
• Enterprise — contact sales: 200+ concurrent, external secret stores, log streaming.

Two things about that meter: n8n bills per workflow execution, not per step, so a twenty-node workflow is one execution — exactly why heavy automators migrate to it. And under 20 employees, check the Start-up plan: n8n advertises 50% off.

Self-hosted, the dollar side is almost trivial. A small VPS runs roughly $5–$20/month, the licence is free, and I have published my own figure before: about $5/month for one self-hosted instance in my stack. Full breakdown in my n8n pricing guide for solopreneurs, which owns the arithmetic so I will not re-run it here.

Now the column nobody publishes. Being straight about my own numbers rather than inventing yours: a stable, pinned, Postgres-backed n8n instance costs me on the order of one to two hours a month in steady state — upgrade review, backup verification, occasional credential re-auth. Call it two to four hours in the first month while you build the backup and get the proxy right, and budget a bad afternoon once or twice a year when an upgrade or an expired credential breaks something that matters.

Which turns the comparison into one honest sentence. Self-hosting saves you roughly €15–€45 a month and costs you one to two hours. If an hour of your time is worth more than about €20, the Starter and Pro tiers are not expensive — they are a wage you are paying yourself to not be on call.

So the crossover is not volume. It is whether owning the box buys you something money cannot: data residency, unlimited executions, filesystem access, custom nodes, or the simple fact that you enjoy it and will keep it patched. Those are good reasons to run n8n self-hosted. “It’s free” is not one.

If reading that made you realise you want the automation without the pager, that is the thing I actually do for people — book an automation strategy session and we will work out which half of this you should own.

The failure modes I’ve actually hit in production

I run a fleet of autonomous brand containers on my own infrastructure — Docker, cron, agents that publish without me. I re-derived the numbers from my own run logs while writing this: 419 scheduled runs in the last 30 days across 19 job types — 324 succeeded, 61 skipped deliberately, 2 failed, 2 ran degraded, and 30 finished without writing a status line at all.

Look at that last figure. Thirty runs produced no outcome record. They did not crash and nothing paged me — they simply finished without saying what happened. An n8n self-hosted stack that fails quietly is more dangerous than one that falls over loudly, because you find out from a customer. Here are the shapes that takes:

The silent success

A workflow runs green, and the step that mattered did nothing — an API returned 200 with an empty body, a filter matched zero rows. n8n reports success because the workflow completed. Fix: assert on the outcome, not the exit. Add an explicit check that the thing you wanted actually exists, and make the workflow fail loudly when it does not.

The expired credential

OAuth tokens expire on the provider’s schedule, not yours. On Cloud you get a tidy notification; self-hosted, you get a workflow that has been failing since Tuesday. Fix: an error workflow wired to a channel you actually read. Mine posts to Telegram. Any channel beats email you have muted.

The upgrade that moved the furniture

At 49 releases a month, a node’s behaviour or an output shape can change under you. Fix: pinned tags, release notes read before pulling, and the previous tag kept so rollback is trivial.

The reboot nobody tested

The VPS restarts for a kernel patch at 3am. Does everything come back — n8n, Postgres, Redis, the proxy, in the right order? If you have not tested it by actually rebooting, that is a hope, not an answer. Fix: explicit restart policies, then reboot the box on purpose, in daylight.

The firewall that lies

Covered above, and worth repeating because ufw status showing a port closed while Docker happily serves it is the most confident wrong answer in this whole stack.

None of these are reasons not to self-host — they are the job description. If you read the list and thought “sure, that is a Saturday,” you will be fine. If you felt tired, that is useful information too.

Should you self-host n8n at all? An honest decision rule

Every page ranking for n8n self-hosted is paid, directly or indirectly, when you answer yes. The hosting companies sell the box; n8n’s docs sell Cloud on the next page. Even the result at position 11 that puts “Should You Do It?” in its title never answers the question — I read it, and it is a Docker and Terraform tutorial with zero mentions of upgrades, backups, or maintenance.

I am not neutral either: I sell done-for-you automation, so I profit when you decide this is someone else’s job. Knowing that, here is the rule I actually apply to my own stack.

Is this workflow load-bearing? If it breaking costs you money, customers, or sleep — own it. Self-host it, pin it, back it up, monitor it, and accept the hours. If it is a nice-to-have, pay someone to run it and spend your attention elsewhere. That is the whole doctrine, and the trigger is consequence, not cost.

Self-host n8n when: you are comfortable in a terminal and will stay comfortable; data residency or privacy is a real constraint; your execution volume would be punished by a per-execution meter; you need filesystem access, local services, or custom nodes; or you genuinely want to own the thing.

Pay for n8n Cloud when: your time is worth more than €20/hour; you are the only technical person and also the bottleneck; you are validating whether the automation earns its keep at all; or you would rather call support than read release notes. Start on Cloud, prove the workflows pay for themselves, then self-host if ownership buys you something. That order is cheaper than the reverse in almost every case.

And the answer nobody in this SERP will give you: sometimes neither. I moved a slice of my own load-bearing work off n8n and onto code agents, because for long multi-step reasoning, a workflow canvas became the harder way to express something a script said plainly. n8n stayed exactly where it is genuinely better — clean triggers, tidy integrations, visible state. Both tools, each doing the job it is actually good at. If you are weighing that trade, my honest shortlist of n8n alternatives and my n8n vs Zapier verdict both go deeper, and how I run the agent runtime on one box covers the layer underneath all of this.

n8n self-hosted: frequently asked questions

Is n8n self-hosted really free?

The Community edition licence is free and has no execution cap. You pay for the server (roughly $5–$20/month) and for your own time — budget one to two hours a month in steady state. Free as in “you own it,” not free as in “costs nothing.”

What do I lose on the free Community edition?

Per n8n’s own edition docs: sharing workflows and credentials, projects, Git version control, environments, SSO, external secret stores, external binary storage, log streaming, and multi-main mode. Register your instance by email for a free licence key that adds folders, debug-in-editor, and custom execution data.

Do I need Postgres, or is SQLite fine?

SQLite works for a small single-user instance. Use Postgres anyway — it is barely harder on day one, it is required in practice for queue mode (n8n does not recommend queue mode on SQLite), and migrating later is worse than starting right.

Is queue mode a paid feature?

No. n8n’s edition documentation states queue mode is included in Community edition; what the paid plans add is multi-main mode. The pricing page lists “queue mode for scaling” under Business, which reads as though it is gated. Trust the docs on capability, and re-check both pages before you budget.

How often do I need to upgrade n8n?

There were 49 releases in the 30 days before this was published, so “keep up” is not a realistic goal. Pin a version, review release notes on a cadence you choose — monthly is sensible — upgrade deliberately, and always upgrade security releases promptly.

What is the most common way a self-hosted n8n setup goes wrong?

In my experience, quiet failure — an expired credential, or a step that returns empty while the workflow still reports success. Most n8n self-hosted incidents I have seen are this, not a crash. Wire an error workflow to a channel you read, and assert on outcomes rather than exit status.

Can I move from n8n Cloud to self-hosted later?

Yes — workflows export and import as JSON. Credentials do not travel, so you will re-authenticate each one, and anything relying on a paid-plan feature (projects, sharing, Git) stops working on Community edition. Plan for an afternoon and a list of logins.

Final thoughts

n8n self-hosted is a genuinely good deal for the right operator and a slow-burning tax for the wrong one — and the thing that decides which you are is not your workflow volume. It is whether you will still be reading release notes in month six.

The install takes an evening. Ownership takes one to two hours a month, forever, plus the occasional bad afternoon. That is the honest price of n8n self-hosted, and page one does not quote it because page one is selling the box.

So pick deliberately. Pin your version, back up Postgres and your encryption key separately, bind Redis locally, wire an error workflow to a channel you actually read, and register for the free licence key while you are in there. Do those five things and you have skipped most of the pain in this article.

And if the honest answer is that you want the machine running without becoming its sysadmin — that is exactly what I build for people. Book an automation strategy session and bring your workflow list.