Compare Self-hosted n8n vs. an owned operating platform
Self-hosted orchestration is the honest version of owning your automation: your server, your data, your credentials, no per-task meter. The difference here is not ownership at all. It is whether what you need is somewhere to run connections or somewhere the work itself lives.
Side-by-side comparison
| An owned operating platform | Self-hosted n8n | |
|---|---|---|
| Who holds the keys | You do - code, database and infrastructure | You do - that is the entire point of self-hosting |
| What it is built to do | Hold the record: jobs, customers, status, history and the screens people work in | Move things between systems, on a trigger or a schedule |
| Where the team works | Screens built for the job, with permissions per role | In the tools it connects; the canvas is for whoever maintains it |
| Who maintains it | Your team from the documented handoff, or us at $450/month | Somebody technical, permanently - upgrades, backups, secrets, broken nodes |
| Cost shape | A build from $5,000, then hosting and upkeep from $80/month | A server and a license that is usually free or cheap, paid for in engineering time |
| Best when | The work needs a system of record and people outside engineering run it | You have technical staff and the job really is orchestration |
Where the difference actually shows up
Self-hosting answers the ownership question honestly
A lot of shops say you own it and mean you own a login. A team running its own n8n instance owns the server, the workflow definitions, the credentials and every record that passes through, and can move the whole thing to a different host on a Saturday. That is real, it is a stronger position than a rented automation account, and it deserves credit rather than a counter-argument.
Orchestration is not a system of record
What an orchestrator does not give you is somewhere for the work to live: a job with a status, a customer with a history, a screen a dispatcher opens on Monday, a permission model for a subcontractor who should see one thing and none of the rest. Connect enough systems and you still answer where a job stands by inferring it from the systems you connected. That gap is what the platform fills, and it is the only good reason to replace something that already works.
Count the engineer, not the license
The software is close to free. The cost is that somebody owns it forever - upgrades, backups that have actually been restored, credential rotation, a node whose API changed underneath it overnight. If you have that person and they enjoy the work, this is a genuinely cheap operation and hard to beat on price. If the person is a developer who is leaving, the free license was the least interesting number in the decision.
When the other option is right
If you have technical staff, self-hosting is a legitimately good answer and we will say so on the call. An in-house developer or a sysadmin who can run a container, restore a backup and read a failing workflow already gives you the things that matter - your data on your own infrastructure, no per-task billing, nobody able to change the terms, and the ability to wire almost anything to almost anything by the end of the week. For a team like that, paying a firm to rebuild what they could assemble themselves is a bad purchase, and sitting in a different city than your engineer is not a disadvantage we can argue away. It stays the right call in two more situations: when the job really is orchestration between systems that each hold their own records, and when you want to prove a workflow is worth automating before anyone pays for a build. Self-hosting only becomes the wrong answer when nobody actually owns the instance, or when what you needed was a system of record and you have been assembling one out of connections.
FAQ
Common questions
Is n8n a worse tool than what you build?
No - it is a different kind of tool and a good one. It orchestrates: it triggers, transforms and moves data between systems, reliably, on hardware you control. What it does not do is hold your operation, with screens, roles and a record per job. Quality is the wrong axis to compare them on. Compare them on what the work needs.
We already run n8n. Does a build throw it away?
Usually not. Instances doing real integration work often stay exactly where they are, with the platform becoming the record they read from and write to. What gets retired is the part where workflows were carrying state they could not see, because that is where the failures get expensive.
What does it take to self-host well?
One person who owns it, and the habit of testing restores. Past the install, the ongoing work is upgrades, backups you have proven you can recover from, credential rotation, and a plan for the day a connector changes under a workflow. None of it is hard. It just never stops, and that is the part most teams underestimate.
Could you build on our instance instead of a new platform?
Sometimes, and we start by looking. If the need is a handful of integrations your team can carry, the honest answer is a Workflow Map at $500 and a short list of what to build yourselves - which is a better outcome for you than a project.
Or explore Process Automation.