Self-hosted n8n: when data rules force it

Self-host n8n when a contract, a regulator or a data-residency requirement means workflow payloads cannot sit on a vendor’s infrastructure. Otherwise, hosted is usually the better trade. Self-hosting costs roughly $20-80 a month in infrastructure and considerably more in the engineering attention nobody budgets: backups, upgrades, queue mode, and being the person paged at 3am.

The honest framing is that self-hosting solves one specific problem very well and adds four others. If you do not have that one problem, you are buying the others for nothing.

Key takeaways

Self-hosting the orchestrator does not keep your data in your estate. Your workflows still call outward.
The server is cheap. The operational attention is not.
Without queue mode, one long workflow blocks the others.
Back up the database, not the container. The workflows and credentials live in Postgres.
If nobody owns upgrades, you will be running a version with a known vulnerability within a year.

Who this applies to

You have decided on n8n and are choosing between n8n Cloud and running it yourself. Or someone has told you self-hosting is required and you want to know whether that is true.

When it is genuinely required

Four cases where self-hosting is the correct answer rather than a preference.

A contractual data-processing restriction. An enterprise customer’s contract names where their data may be processed and by whom. Adding a workflow vendor to that chain requires an amendment nobody wants to negotiate.

Regulatory data residency. The workflow handles personal data of people in a jurisdiction with residency requirements, and the hosted region does not satisfy them.

Reaching systems with no public endpoint. The automation must query an internal database, an ERP on a private network, or a service behind your VPN. A hosted platform cannot reach it without exposing it, and exposing it is a worse decision than self-hosting.

Payload sensitivity that survives scrutiny. Health records, full card data, legal documents under privilege. Note “survives scrutiny”: a lot of data described as too sensitive for a vendor is already in a hosted CRM.

The distinction that catches people

Self-hosting the orchestrator is not the same as keeping data in your estate.

Your self-hosted n8n still calls the CRM API, still sends text to a model provider, still posts to the messaging platform. Those payloads leave your network exactly as they would have from hosted n8n. What changes is that the workflow engine and its execution logs are yours.

That is a real reduction in exposure and it is narrower than most people assume when they say “we self-host for compliance”. If the requirement is that a document never reaches a third party, self-hosting the automation tool does not achieve it - you need the model and every integration inside the boundary too, which is a much larger project.

Be precise about which requirement you are satisfying, because auditors are.

What it actually costs

Line	Typical	Note
Compute	$20-60/mo	A small VM handles modest workloads
Managed Postgres	$15-50/mo	Do not run the database in the same container
Backups and storage	$5-15/mo	Cheap, and the thing people skip
Reverse proxy and TLS	$0	Caddy or nginx, plus a certificate
Monitoring	$0-30/mo	Uptime and disk at minimum
Infrastructure total	$40-155/mo
Engineering attention	2-6 hrs/mo	Upgrades, incidents, capacity

The last row is the real cost, and it is the one that never appears in the comparison against a hosted plan. At a loaded engineering rate, two to six hours a month is comparable to or larger than the infrastructure line, and it does not scale down when things are quiet - it arrives in lumps when something breaks.

Everything in the picture fits on one small VM with Docker Compose. The two boxes people skip are the tested backup and the disk alert, which between them cover most self-hosted outages.

The four things people forget

1. Queue mode

By default, n8n executes workflows in the main process. One workflow that takes four minutes blocks the ones behind it, and a burst of webhooks can queue up behind a slow run.

Queue mode splits execution across worker processes with Redis coordinating. It is the difference between a toy deployment and one that survives concurrency, and it is not the default.

The signal you need it: workflows that used to run in seconds start reporting minutes, or webhooks time out under load. If you are running anything webhook-triggered with real traffic, configure it before launch rather than after the first incident.

2. Backups of the right thing

Workflows, credentials and execution history live in the database, not in the container image. Snapshotting the VM is not a backup strategy if the database is managed separately, and re-creating credentials by hand across forty workflows is a genuinely bad afternoon.

Back up Postgres on a schedule, store it somewhere else, and restore it once to prove the backup works. An unrestored backup is a hypothesis. The workflows themselves belong in git as well - see version controlling n8n workflows - though a repository is not a substitute for the database backup, because credentials are never in the export. Self-hosting is also the prerequisite for shipping a custom node, which is the other reason teams end up here.

The encryption key deserves its own mention: credentials are encrypted with a key held in the environment. Lose that key and your backup restores workflows with unusable credentials. Store it in your secrets manager, not only in the deployment config.

3. Upgrades

n8n releases frequently. Self-hosting means you decide when to take those releases, which sounds like control and behaves like deferral.

Set a cadence - monthly is reasonable - and treat it as maintenance rather than a project. Read the release notes for breaking changes to nodes you use, upgrade a staging instance first, and keep the previous image tag so a rollback is one command.

The failure mode is not a dramatic outage. It is being eighteen months behind, on a version with a published vulnerability, with an upgrade path that now spans several breaking changes at once.

4. Somebody is on call

A hosted platform has an operations team. Self-hosted, that is you.

Decide explicitly who is notified when the instance is down and what their response is. “We will notice” is not a plan for something running your nightly reconciliation.

A workable baseline

For most self-hosted deployments, this is enough and less than people build:

Docker Compose on a single VM: n8n, Postgres, Redis, and a reverse proxy handling TLS
Queue mode with two workers
Managed Postgres if your provider offers one, rather than a container
Daily database backup to separate storage, retained a month, restored once as a test
Uptime monitoring, plus a disk-space alert - full disks are the most common self-hosted outage
The encryption key in a secrets manager
Monthly upgrade window

Kubernetes is rarely justified for this. If your organisation already runs it and has the operational muscle, fine. If adopting it is part of the automation project, that is a much larger commitment than the automation warranted.

Where we land on this

We self-host for clients when one of the four conditions at the top is genuinely met, and we recommend hosted when it is not - which is more often than clients expect when they arrive asking for self-hosting.

The reasoning is that self-hosting relocates a cost rather than removing one. The hosted subscription becomes infrastructure plus an operational obligation that outlives the engagement. When we hand over a self-hosted deployment, we are handing over something that needs upgrading, monitoring and occasionally rescuing, and if there is no named person on the client side who owns that, we have built a liability with a good-looking architecture diagram.

The version of that conversation that costs us: a client wants self-hosting for reasons that turn out to be preference rather than requirement, and the honest answer is that hosted is better for them. Saying so trims the scope of the engagement. It also avoids the call eight months later where nothing has been upgraded and something has stopped.

When not to self-host

When the requirement is vague. “We are quite security-conscious” is not a data-residency requirement. Find out what actually constrains you before designing around it.

When there is no owner. Repeated because it is the deciding factor. An unowned self-hosted deployment decays predictably.

When your volume is small. A few hundred executions a month on hosted costs less than the attention self-hosting demands.

When you are still deciding what to build. Self-host later if you must. Starting hosted and moving is straightforward, because the workflows export.

Frequently asked questions

Does self-hosting make n8n free?

The software is free to run under its licence for internal use. Total cost is infrastructure plus operational time, which is often comparable to a hosted plan at modest volume and much cheaper at high volume.

Can we self-host and still use AI nodes?

Yes, and note what that means: those nodes call an external model provider, so your payloads leave your network at that point. If the requirement is that content never reaches a third-party model, you need a self-hosted model too, which is a substantially larger undertaking.

How much traffic can a single instance handle?

More than most businesses generate, provided queue mode is on and workflows are not doing heavy processing in the main process. The constraint is usually a specific slow workflow rather than aggregate volume.

What breaks most often?

Disk filling with execution history, and credentials expiring. Set an execution-data retention policy on day one - unbounded history is the most common cause of a self-hosted instance falling over.

Is Docker Compose really enough?

For most business automation, yes. Reach for anything larger when you have a specific requirement it solves, not on principle.

Next step

If you are not sure whether your requirement genuinely forces self-hosting, that question is worth settling before the build rather than after. The n8n and Make engagement covers it, including the answer that hosted is fine.