The honest answer to n8n vs make vs zapier is that all three will run your first workflow fine. The choice only starts to matter around the point where you have thirty of them, one has been failing quietly for a fortnight, and the invoice has stopped looking reasonable. Picking on features is how teams end up migrating a year later.
We build automation for clients on all three, and we also maintain our own. The differences that have actually cost people money are pricing model, what happens when a run fails, and how hard it is to leave.
The Pricing Model Decides More Than The Price
These tools bill on different units, and the unit matters more than the number attached to it.
Zapier bills per task, where a task is roughly one action. A workflow with six steps that runs a thousand times costs you six thousand tasks. That is predictable and it scales linearly with volume, which is comfortable until volume arrives.
Make bills per operation, which is a similar idea at a lower unit price, so it usually works out cheaper at the same volume. The complication is that iterators and aggregators consume operations per item, so a workflow that processes a hundred-row spreadsheet can quietly consume a hundred times what you estimated.
n8n bills per workflow execution on cloud, and self-hosted it bills nothing at all beyond the server. One execution can contain thousands of steps for the same price. That difference is not marginal. For high-volume or loop-heavy work it is often an order of magnitude.
So the first question is not which tool is best. It is whether your workloads are loop-heavy. If they are, per-task billing will punish you and the decision is largely made for you.
Zapier: The Widest Catalogue, The Lowest Ceiling
Zapier has the largest integration catalogue by a distance, and the integrations are generally the most polished. If you need to connect two mainstream tools and move on with your day, nothing beats it for time-to-working.
The ceiling arrives when a workflow needs real logic. Branching exists but is awkward. Loops are limited. Error handling is thin. Once a workflow needs to make decisions rather than pass data along, you find yourself building around the tool rather than with it.
It suits small teams with straightforward connections and no engineering resource, where the cost of the subscription is obviously less than the cost of someone's afternoon. That is a real and common situation.
Make: More Power, More Rope
Make gives you a visual canvas with genuine control flow. Routers, iterators, aggregators and error handlers are first-class, and you can build things in it that Zapier simply will not express.
The trade is complexity that grows faster than the diagram suggests. A scenario with several routers and nested iterators becomes genuinely hard to read, and because the logic is spatial rather than textual, you cannot diff it, review it or search it the way you would code. Handing a complicated Make scenario to a colleague is a slow conversation.
It fits teams who need real branching, are comfortable in a visual builder, and have workflows complicated enough to justify the learning curve but not so complicated that they want version control.
n8n: Closest to Code, With The Obligations That Brings
n8n sits nearest to writing software. Nodes are composable, you can drop into JavaScript wherever you need to, and workflows are JSON you can commit to a repository, review in a pull request and deploy through a pipeline.
Self-hosting is the part that changes the economics and the responsibility at the same time. There is no per-task meter, and there is also nobody else keeping the instance patched, backed up and running. That is a fair trade for a team with engineers and a poor one for a team without.
It fits teams who already run infrastructure, whose workflows loop over large sets, or who want automation to live under the same review process as everything else they ship.
The teams that regret their choice almost never regret the features. They regret the bill at volume, or discovering that a workflow had been failing silently since March.
David Kwon, Head of Automation, Engineered With AI
What Happens When A Run Fails
This is the question nobody asks during evaluation and everybody asks during an incident. Automation fails constantly. APIs time out, credentials expire, a field changes name. What separates these tools is what you learn afterwards.
- Can you see the exact data that entered each step of the failed run, or only that it failed?
- Can you re-run the failed execution with the original payload, or must you recreate the trigger by hand?
- Does a failure alert someone, or does it sit in a log nobody opens until a customer notices?
- How long is execution history retained on your plan? Short retention means a problem reported a week late is unfixable.
All three can answer these adequately, and none of them answer them by default. Whichever you choose, set up failure notifications on day one. The most expensive automation failures we have been called in to fix were not complicated. They were simple failures nobody was told about.
The Cost Of Leaving
Every one of these keeps your logic in a proprietary format, so migration means rebuilding rather than exporting. Thirty workflows is a serious project regardless of which direction you are moving.
n8n's JSON export is the most portable of the three and it is still n8n's JSON. Self-hosting reduces vendor risk in a different sense, since the software keeps running whatever the company does, but it does not make the workflows portable to a competitor.
The practical mitigation is not to pick the most portable tool. It is to keep genuinely important business logic out of the automation layer entirely. Use these tools to move data and trigger things. Keep the rules that matter in a service you own, so a migration is a plumbing job rather than a rewrite of how your business works.
A Straight Recommendation
- Few workflows, mainstream apps, no engineers, simple logic. Zapier. The catalogue and the polish are worth the premium and you will not hit the ceiling.
- Real branching, moderate volume, comfortable in a visual tool, no appetite for infrastructure. Make. Best power-to-effort ratio in the middle of the range.
- Loop-heavy work, high volume, engineers on the team, or a desire to review automation like code. n8n, self-hosted. The economics are decisively better and you inherit the running of it.
- Genuinely unsure. Start on the managed tool that fits today and keep the important logic outside it. That keeps the decision cheap to revisit.
The Question Underneath
Most teams asking which tool to pick are really asking how much of their operation should live in a visual builder at all. Our answer, after building a good deal of it, is less than people expect. These tools are excellent at connecting systems and poor at being the place your business rules live.
Use them for what they are good at, put a real service behind anything that matters, and the tool choice stops being a decision you can get badly wrong.
If you are weighing this up for a specific set of workflows, we can usually tell you which way it falls in one conversation, including whether the answer is that you should not be using any of them for that particular job.
Not sure which way your automation should go?
Describe the workflows and the volume. We will tell you which tool the economics favour, and whether any of this should be sitting in a builder at all.