The axis these three actually differ on
Almost every three-way comparison of these tools ranks them on features and price, and produces the same conclusion: n8n is cheaper and more powerful, Zapier is easier, Make is in the middle. That conclusion is not wrong and it is not useful, because it leaves out the variable that determines whether the decision was right — who carries the operational burden.
Zapier and Make are products. You pay someone and automation happens. When something breaks in their infrastructure, a team you will never meet fixes it while you are asleep. That is a service, and the money buys you the absence of a job.
Self-hosted n8n is not a product in that sense. It is software you run. The license is generous and the software is genuinely good — and you have just acquired a production system. It needs a host, updates, monitoring, backups, a secrets story, a TLS certificate that expires, and a restore procedure that only counts if you have tested it. Nobody puts that on the comparison table, and it is the single largest cost of the choice.
n8n also offers a cloud version, which collapses this whole distinction and is the option most founders should be comparing — at which point n8n competes with Make on execution model rather than on economics, and the argument gets much simpler. The confusion in this entire category comes from comparing self-hosted n8n's license cost against Zapier's subscription and calling that a price comparison. It is not. It is comparing a subscription against a subscription plus a job.
Where each one sits, structurally
Zapier is a line: a trigger, then steps, in order, once. The linearity is the product and it is a good constraint, because most automations really are lines. It is legible — you can read a Zap top to bottom — and it is fast to build, which means it actually gets built, by the person who understands the process, on the day they thought of it. Its billing is per task, so cost scales with how many things you do, which means it rewards few steps at low volume and gets uncomfortable exactly as an operation matures.
Make is a graph: modules connected by routes, with data flowing as bundles, and native iteration — a module emits many bundles and everything downstream runs once each. That makes 'for each line item' the default behavior rather than a loop step and some cleverness. It has routers, per-route filters, error handlers attached to specific modules, and aggregation. It is harder to learn — bundles are a real concept and until you have it, the tool feels arbitrary — and a thirty-module canvas is hard to read no matter how nicely it renders.
n8n is a graph too, with a crucial difference: it is closer to code. Nodes on a canvas, but with a real JavaScript execution environment inside them, sane data structures, proper error branches, and — if you self-host — no per-task meter breathing on your architecture. That last point changes what you build. When every step costs, you design around the meter, which is a bad reason to design anything. When steps are free, you build the automation the process actually needs.
So on shape: Zapier for lines, Make and n8n for graphs. On capability: n8n goes furthest, because at the point where a graph tool runs out you can just write code inside it, and that is a materially different ceiling. On burden: Zapier and Make carry it, self-hosted n8n does not, n8n cloud does.
The honest cost of self-hosting
Enumerate it, because the enumeration is the argument. A host. Upgrades, which you will postpone until a security note forces you to do it at a bad time. Monitoring — and note that 'monitoring' here means knowing that your automation platform stopped running, which is a thing you will otherwise learn from a client. Backups, and a restore procedure, and the restore procedure is worthless until you have run it once on purpose. Secret storage that is not a text file. A TLS certificate. Queue mode and workers when a single process stops keeping up, which is a real architectural change and not a setting.
None of that is hard for someone who does infrastructure. All of it is a job, and the job does not pause when you are in delivery. The question that resolves the whole decision is the one at the top: when this goes down at 2am on a Saturday, who gets up? If you cannot name a person, you do not have a self-hosting plan — you have a plan to find out.
There is a second, subtler cost. The moment your automation platform is infrastructure you own, your automation platform is in scope for every conversation you did not want to have: security review, data residency, access control, what happens when the person who set it up leaves. Those are the same conversations that make people buy software, and they will find you.
The version of this that is genuinely correct: self-host when you have a real reason. Data that cannot leave your environment. Volume where the meter has become architecturally distorting. A genuine need for the code-level control. Or a person on the team who does this professionally and for whom it is twenty minutes a month. Those are all legitimate and we build there. 'It is cheaper' is not one of them, unless you have priced your own Saturday.
The stack we actually run, and why it is three tools
We use all three, deliberately, and the split is not indecision. Zapier for the small linear seams at the edges of a business — the twenty things that connect one system to another with no branching, built quickly, read easily. Make for scenarios with real shape: iteration over collections, branching with different behavior per branch, error handling that does not kill the run. n8n or custom code for the parts with opinions — anything with state across runs, idempotency keys, retries with backoff, reconciliation across three systems, or a silent failure mode that costs money.
That last category is worth naming precisely, because it is the boundary that matters. If an automation fails and everybody finds out immediately, put it wherever is fastest. If an automation can be *wrong* without anybody finding out, it belongs where you have error semantics and something you can read six months later. The cost of the mistake is the design input, not the step count.
The rule for mixing, and it is hard: one process, one tool, one owner. The specific catastrophe is a process that starts in a Zap, hands to a Make scenario, and returns to a different Zap. Nobody can trace it, no error surfaces coherently, and the person debugging it at 11pm does not know there are three tools involved. Cross tools at a system boundary, never in the middle of a thought.
And under all of it, the thing that is true of all three: each of these tools lets you encode a business policy in a place with no memory of why. A filter is a decision. A delay is a decision. Every automation gets a page in Notion with an owner and a stated assumption, or your automation layer is a body of undocumented law that executes itself. The tool choice on this page is a much smaller decision than that one.
How to choose without regretting it
Say the automation out loud. One sentence, no 'for each,' no 'unless' — Zapier, today, done. Iteration and branching — Make. State, idempotency, real retries, reconciliation, or the ability to drop into code when the canvas runs out — n8n.
Then, and only then, decide the hosting question separately from the tool question, because they are separate questions and merging them is where the regret comes from. If you chose n8n, choose n8n cloud unless you can name the person who gets up at 2am and can say what your restore procedure is. Choosing n8n cloud is not a defeat. It is buying back the job you were about to give yourself for free.
Do not choose on price. Every one of these vendors will change their pricing, and a decision made on a number from a comparison post you read at midnight is a decision made on a fact with an expiry date. Choose on shape and on burden. Those two do not change when a pricing page does, which is why they are the only two things on this page worth writing down.
And keep the frame straight: none of these three is an operations strategy. They are all good at moving data on a trigger. Efficiency asks how can I do this faster; leverage asks should I even be the one doing this at all — and no automation platform has ever asked the second question, because none of them knows what your business is. Doing more doesn't create growth. Designing better does. If you want the design mapped before you pick a tool, that is an OPERATE Report ($1,997). If the design is clear and you want it built in the right one, a Build Day ($5K/day) or a Custom Build, quoted per engagement, is the route.
The real axis is not features or price — it is who carries the operational burden. Zapier and Make are products where a vendor gets up at 2am; self-hosted n8n is software you run, and you just hired yourself as its ops team. Choose the tool on shape (line, graph, or application) and choose hosting as a separate decision. If you cannot name the person who gets up at 2am, use n8n cloud.