The feature comparison is a distraction. All three will connect your CRM to Slack, all three have hundreds of integrations, and all three will demo beautifully. What separates them is what happens to your bill when the thing you built starts working. Zapier bills per task — cheapest to start, brutal at volume. Make bills per operation, and a single multi-step scenario burns several per record. n8n's cloud plans bill per workflow execution regardless of how many steps it contains, and self-hosting flattens the curve entirely, at the cost of your time. Pick by the shape of your workload, not the length of the integrations list.
The billing units, precisely
This is the entire post. Everything else follows from it.
Zapier: the task
A task is an action step that successfully runs. Trigger a Zap with 1,000 new records and run six actions on each, and you are in the neighbourhood of 6,000 tasks. Steps that do not execute an action — a filter that halts the run, for instance — generally do not consume a task, though the details matter and you should confirm them against current billing documentation rather than an article.
The consequence: your Zapier bill scales with volume multiplied by step count. Both dimensions. Add a step to a busy Zap and you have not added a step — you have added a step times every record that flows through it, forever.
Make: the operation
An operation is a module execution. Each module in a scenario that runs consumes one. This sounds identical to Zapier's model, and the difference is in how Make encourages you to build: iterators, aggregators, routers, and HTTP modules are all first-class citizens, and they all execute.
Here is the part that surprises people. Loop over a record with twenty line items, running three modules inside that loop, and you have not spent three operations. You have spent sixty. Make makes complex data manipulation genuinely pleasant, and it meters every piece of that manipulation.
The consequence: your Make bill scales with volume multiplied by module executions, including everything inside your loops. Per unit it is typically cheaper than Zapier. Per record, a complex scenario can consume far more units than the equivalent Zap.
n8n: the execution
This is the structural difference that the feature comparisons all miss. On n8n's cloud plans, one workflow run is one execution — whether that workflow has four nodes or forty. Node count is free.
Self-hosted, there is no execution meter at all. n8n is source-available under a sustainable-use licence, you run it on your own infrastructure, and your cost is a server plus the time of whoever keeps it alive.
The consequence: n8n's cost scales with volume, and is close to indifferent to complexity. For long, elaborate, data-heavy workflows, that is not a small saving. It is a different cost curve.
| Platform | Billing unit | What burns it | Cheapest when | The hidden cost |
|---|---|---|---|---|
| Zapier | Task (each action that runs) | Volume x number of action steps | Low volume, few steps, no engineer | Every step you add is billed on every record, forever |
| Make | Operation (each module execution) | Volume x modules, including loop iterations | Mid volume, complex data transformation | Iterators and aggregators multiply ops invisibly |
| n8n Cloud | Execution (one workflow run) | Volume only; step count is free | High step count at moderate volume | Steeper learning curve; smaller ecosystem |
| n8n self-hosted | Nothing per run | Your server, your time | High volume and you have ops capability | Upgrades, monitoring, backups, and being on call |
Swipe the table sideways to see every column →
Do the arithmetic before you choose
Take a workload and count units. This is an illustration with assumptions I am stating openly, not a benchmark — plug in your own numbers, because yours are the only ones that matter.
Assume: 1,000 records a month. Six actions on each. One of those actions loops over roughly five line items per record, with two modules inside the loop.
- Zapier: roughly 6,000 tasks. The loop is awkward to express and will likely cost you more, not less.
- Make: the six modules give you about 6,000 operations, and the loop adds roughly ten more executions per record — call it 10,000 operations and up. The loop nearly doubled the bill.
- n8n: 1,000 executions on cloud. The six steps and the loop are free. Self-hosted, the marginal cost is zero.
Now multiply each by your plan's current per-unit rate and compare the totals. That number — not the integration count, not the interface — is the comparison nobody publishes, and it is the one that determines what you pay for the next three years.
The pattern holds generally: as step count rises, Zapier gets punished first, Make gets punished second, and n8n barely notices. As volume rises with a low step count, the gap narrows and Zapier's simplicity starts looking like a bargain again.
The crossover points
Rules of thumb, stated plainly enough to disagree with.
Choose Zapier when your volume is modest — a few hundred to a couple of thousand tasks a month — and your workflows are short. At that scale the cost difference between platforms is noise, and you should buy the easiest thing. The Zapier ecosystem is the largest, its integrations are the most reliable, and a non-technical person can build and maintain a Zap without help. That is worth real money. Do not over-engineer a problem you do not have.
Choose Make when your logic is growing faster than your volume. Branching, iterating over line items, transforming payloads, aggregating results — Make's visual model handles this genuinely well, and expressing the same logic in Zapier will be painful and expensive. This is the sweet spot most growing companies land in and it is where Make earns its reputation.
Choose n8n when volume is high, workflows are long, and you have someone who can run a server. The cost curve goes flat, and at sufficient scale that is a decisive advantage. It is also the strongest option if you are building AI agents and chaining model calls, where workflows get long quickly and per-step billing becomes actively hostile.
And the fourth answer nobody wants to hear: write a script. If one engineer can express the whole thing in forty lines of Python, and you already have somewhere to run a cron job, the no-code tax may not be worth paying. The honest case for these platforms is that non-engineers can build and maintain the automations, and that observability and error handling come free. If neither applies to you, you may be buying a wrapper you do not need.
The costs that never appear on a pricing page
- Retries. An action that fails and retries burns another unit. A flaky API endpoint is a line item on your bill.
- Polling. Where a trigger polls rather than receiving a webhook, the polling interval interacts with your billing in ways that are easy to miss. Prefer webhooks wherever the integration offers them.
- Test runs. They consume units on some plans. Building an elaborate workflow is not free, and iterating on it costs more than building it.
- Migration. You cannot export a Zap into Make, or a Make scenario into n8n. Nothing transfers. Whatever you build, you are rebuilding by hand if you move — which is the strongest argument for thinking about the cost curve before you have ninety workflows in production, not after.
- The maintenance tax. APIs change. Integrations break. Someone has to notice, and the failure mode of automation is silence — the workflow stops, and nobody finds out for a fortnight.
- The bus factor. Who owns these workflows when the person who built them leaves? An undocumented automation estate is a liability, and this is the cost that most reliably goes unpriced.
Who should not self-host n8n
Somebody has to say this, so: self-hosting to dodge a subscription and then losing a working day to a failed Docker upgrade is a bad trade, and it is a very common one.
Do not self-host if you have no on-call rotation, no one who is comfortable with containers and backups, compliance requirements that you would now be personally responsible for satisfying, or workflows that touch money and customers where an hour of downtime costs more than a year of the subscription you were avoiding.
The self-hosted cost curve is flat in dollars and steep in attention. That is a great trade for a team with an engineer who enjoys this. It is a terrible one for a five-person company where the person running the server is also the person running sales.
If you start on Zapier, plan to leave
Most companies should start on Zapier. It is the fastest path from idea to working automation, and speed matters more than unit economics at the beginning. But build as though you will migrate, because if it works, you will.
Keep each workflow doing one comprehensible thing. Write down what it is for and who owns it — a one-line description in a shared doc beats a perfectly-named Zap nobody can find. Avoid platform-specific cleverness where a plain sequence of steps would do. Watch your task consumption monthly, and treat a sharp rise as the signal it is, rather than a billing surprise.
The migration will still be manual. It will just be survivable.
FAQ
Is n8n really cheaper than Zapier?
At high volume with multi-step workflows, substantially — because n8n bills per workflow execution rather than per step, and self-hosting removes the per-run meter entirely. At low volume with simple workflows, the saving is negligible and does not cover the setup and maintenance effort. The crossover depends on your step count more than your record count.
What is the difference between a Zapier task and a Make operation?
They are close cousins with one important divergence. A Zapier task is an action step that runs; a Make operation is any module execution — and because Make encourages iterators and aggregators, a scenario that loops over line items can consume many operations per record. Make is usually cheaper per unit and can consume more units per record. Compare on total units for your actual workload, not on the headline rate.
Should a small business use Zapier or Make?
Zapier, in most cases. If your automations are short and your volume is modest, the cost difference is trivial and Zapier's reliability, integration coverage, and approachability are worth more than the saving. Move to Make when your workflows start needing real branching and data transformation, and the Zaps become awkward to express. Our Make vs Zapier comparison goes deeper on the head-to-head.
Can I self-host n8n for free?
You can run it on your own infrastructure under its sustainable-use licence, with no per-execution charge — but "free" means free of subscription, not free of cost. You are paying for a server, upgrades, monitoring, backups, and the hours of whoever keeps it running. If you do not have that person, this is not a saving.
Which is best for AI workflows and agents?
n8n, generally, for the structural reason that AI workflows get long fast — retrieval, several model calls, parsing, branching, error handling — and per-step billing punishes exactly that shape. When one execution covers forty nodes, chaining model calls stops being a billing decision. That said, the model API costs will dwarf the automation platform costs at any real scale, which we broke down in what AI agents actually cost.
Pick the platform whose billing unit matches the shape of your work, and re-check it when your volume changes — the right answer at 500 tasks a month is often the wrong one at 50,000. Browse the AI automation tools and no-code AI tools categories to see the wider field, weigh the rest of the market in Zapier alternatives and our best no-code AI tools roundup, or if you are self-hosting your stack, start with open-source AI agent frameworks. Founders sizing this decision early should also look at the startups page.
