Self-hosted n8n is usually pitched on one number: no per-task billing. That number is real and it is the least interesting part of the decision, because what you are actually trading is a subscription for a set of operational obligations.
We run it and we deploy it for clients. Here is what the trade actually contains.
Where The Economics Genuinely Win
The saving is largest for loop-heavy work. Most managed automation tools bill per task or per operation, so a workflow iterating over a thousand rows consumes a thousand units. n8n bills a workflow execution as one execution regardless of how many steps run inside it, and self-hosted there is no meter at all.
So if your automation processes batches, enriches lists, or loops over records, the difference is not a percentage. It is frequently an order of magnitude.
If your workflows are a handful of steps running a few hundred times a month, the saving is real and small, and probably does not justify the rest of this article.
What You Take On
This is the part the comparison posts skip.
- Updates. New versions arrive frequently. Skipping them accumulates risk; applying them without testing occasionally breaks a workflow. Either way it is now your calendar.
- Backups. Workflow definitions, credentials and execution history. Untested backups are a belief rather than a plan, so restore one occasionally.
- Uptime. If the server is down, nothing runs. Nobody emails you about it. You need monitoring on the instance itself, not only on the workflows.
- Security. It holds credentials to everything it touches. That makes it one of the more sensitive boxes you operate, and it should be treated accordingly.
- Scaling. Heavy or concurrent workloads eventually need queue mode, Redis and worker processes. That is a real infrastructure setup, not a checkbox.
A Sensible Deployment
Docker with a managed Postgres database behind it is the arrangement that causes the fewest surprises. SQLite is the default and it is fine for evaluation; it is a poor choice for anything you depend on, and migrating later is avoidable work.
Put it behind a reverse proxy with TLS, restrict access properly, and turn on the authentication rather than leaving it open on a port because it was quicker. An unsecured instance holding live credentials is a genuinely serious exposure.
Set the encryption key deliberately and back it up separately. Lose it and every stored credential becomes unreadable, which turns a restore into a rebuild.
The instance holds credentials to your CRM, your accounting system and your email. People deploy it with less care than they would give a staging server.
Sam Ortiz, Director of Engineering, Engineered With AI
The Things That Bite People
Execution history growth. Every run is stored, and a busy instance fills a disk faster than expected. Set a pruning policy on day one rather than discovering it when the disk is full and nothing has run for two days.
Version upgrades that change node behaviour. Read the release notes, and keep a staging instance if the workflows matter. A staging copy is the difference between finding a break on Tuesday afternoon and finding it during month end.
Credential sprawl. It becomes the place every integration is configured, and after a year nobody is certain which credentials are still in use or who rotated them last. Audit periodically.
Cloud Versus Self-Hosted
n8n's own cloud removes all of the above and reintroduces a bill. For many teams that is the correct trade, and choosing it is not a failure of ambition.
Self-host when the volume genuinely justifies it, when you already run infrastructure and have someone who can look after another service, or when data residency requirements mean the workflow data cannot sit with a third party.
Use the cloud when the team has no infrastructure capability, when the volume is modest, or when the automation is important enough to need reliability but not important enough to justify somebody owning a server.
The Honest Test
Ask who patches it. If there is a clear answer with a name attached and time allocated, self-hosting is a sound decision and the savings are real. If the answer is that somebody will get to it, you are choosing a subscription you pay in incidents rather than invoices.
That is not an argument against self-hosting. It is an argument for deciding it deliberately, because the failure mode is quiet: an instance running an old version, unpatched, unmonitored, holding live credentials, until the day it matters.
If you want a view on which side your workload falls, the useful numbers are how many executions a month, how many steps in the heaviest workflow, and whether anyone currently administers a server.
Weighing up self-hosting?
Tell us your monthly execution volume, the shape of your heaviest workflow, and whether anyone currently runs infrastructure. We will tell you which option actually fits.