n8n is the right choice when data can’t leave your infrastructure, when per-operation pricing has become the problem, or when a workflow needs more code than a visual tool comfortably allows.
These come up repeatedly. If yours isn’t listed, it’s usually still possible — describe it and I’ll tell you honestly.
For businesses that can’t send customer records through a third-party cloud, n8n runs on infrastructure you control.
Where a Zapier or Make bill has grown faster than the value, moving high-volume workflows to n8n usually pays for itself quickly.
Function nodes handle transformations that would take a dozen awkward steps elsewhere.
Model calls inside a workflow with proper error handling, retries and a human checkpoint where one is needed.
Anything with an API can be reached, and reused across workflows as a proper node.
Rebuilding existing automations in n8n without losing the error handling and edge cases the originals accumulated.
The usual reason a self-hosted build gets difficult isn’t the workflow — it’s everything around it. Queue mode and worker configuration for anything with real volume, credential management so secrets aren’t sitting in plain nodes, and a monitoring path, because a self-hosted instance that stops has nobody to email you about it. Those three are what separate a demo from something a business can rely on.
If you’re weighing n8n against Make or Zapier, I’ll give you a straight answer about which fits — including when it isn’t n8n.
Self-host if data residency matters or volume is high. Cloud if you’d rather not maintain a server. The workflows themselves are identical.
More capable, and more to look after. If nobody on your team is technical, that’s a real consideration — which is part of why the documentation matters.
Yes. The rebuild is usually straightforward; the part worth paying attention to is carrying over the edge cases the old builds learned the hard way.
Describe it in a paragraph. I’ll tell you what it would take — or tell you honestly it isn’t worth it.