n8n scores 8.2 on our 361 score, and most of that comes from a single structural advantage: you can run it yourself. That one fact changes the economics of automation more than any feature comparison, because per-task pricing is what kills automation projects — not capability.
It also introduces a category of problem that hosted tools spare you. This guide is about both halves honestly, because the enthusiastic version of this article gets teams into trouble around month four.
What n8n is actually for
n8n is a visual workflow builder that connects several hundred services, with the escape hatch of arbitrary code in a node when the visual layer runs out. That escape hatch is the important part. Most no-code tools hit a wall where the remaining 10% of your logic is impossible; n8n lets you write it.
The result is a tool that sits between Zapier-style simplicity and writing a service yourself. It is genuinely well suited to internal plumbing: moving records between systems, enriching data on a schedule, reacting to webhooks, fanning notifications out to the right channel.
The cost argument, stated properly
Hosted automation tools charge per task or per operation. That model is fine at low volume and becomes absurd at high volume — a workflow that fires on every row of a nightly sync can cost more than the engineer who wrote it.
Self-hosted n8n moves that cost to infrastructure, which is close to flat. A small instance handles a surprising amount of work. This is the honest reason most teams migrate, and it is a good reason.
What the cost argument leaves out: you now own uptime, upgrades, backups and credential storage. If nobody owns those, you have not saved money — you have deferred it into an outage.
Decision one — self-host or use n8n Cloud
Self-host if you already run infrastructure, have somewhere to put a database, and someone whose job includes noticing when a container dies. Use the cloud version if your automation is important but your team is not operationally staffed.
The failure pattern to avoid is self-hosting because it is free, on a VPS nobody is watching, with workflows that quietly become load-bearing. The month it breaks, it will break during something that matters.
Decision two — treat workflows as code, not as drawings
n8n workflows are JSON. Export them and put them in version control from day one. This sounds fussy for a five-node workflow and it is exactly what saves you when a workflow that has grown to forty nodes breaks and nobody remembers what changed.
A visual editor invites direct editing in production, which is the automation equivalent of editing files on a live server. Keep a staging instance if the workflows matter.
Decision three — decide where the logic lives
The temptation is to put everything in n8n because you can. Resist it for anything with real business rules. A workflow is a good place for orchestration — call this, wait, branch, call that. It is a poor place for the actual rules of your business, because it has no tests, weak types and no code review.
The maintainable shape is thin workflows calling well-defined endpoints. When the rules change, you change a service that has tests, not a diagram someone has to read node by node.
Decision four — credentials and blast radius
Self-hosting means you store API credentials. Encrypt them, restrict who can open the editor, and give each integration the narrowest scope that works. An automation platform is a machine that holds keys to everything you connected — treat it with the seriousness that implies.
Scope tokens per workflow where the service allows it. When something leaks, the difference between a scoped token and an admin token is the difference between an incident and a catastrophe.
Where it disappoints
The learning curve is real. The visual metaphor is easy for three nodes and stops being self-explanatory well before thirty. Debugging a long workflow means stepping through executions, which is slower than reading a stack trace.
Error handling also takes deliberate work. The happy path is quick to build; making a workflow behave correctly when a third-party API returns a 500 halfway through is where the actual engineering time goes, and it is easy to skip until it bites.