Zapier or n8n? Where it runs decides it.
The choice is not about features — the node lists converge. It is about where the automation runs and how it is metered. Zapier is hosted only and bills per successful task. n8n offers a self-hosted option alongside its cloud, with a free Community edition. Both are in production at Kindra.
The two differences that actually decide it
Everything else is noise at the scale most Australian SMBs operate at. Feature lists converge, both have large connector libraries, and both will move a record from one system to another without complaint.
What does not converge is the deployment model and the billing model, and those two facts determine the cost curve you are signing up to.
| Zapier | n8n | |
|---|---|---|
| Runs on your own infrastructure | No Hosted service only. No self-hosted or on-premises option is offered. | Yes Documented as one of two deployment choices — "deploy on your own infrastructure" — alongside a managed cloud. |
| How usage is metered | Partly Per successful task. Tasks are shared across the account; polling for new data is not charged, only completed actions. | Yes Self-hosted Community edition is free indefinitely with, in n8n’s words, "almost the complete feature set". Paid tiers add SSO and environments. |
| Cost behaviour as volume rises | No Rises with successful actions. Predictable, and it scales with the thing you were trying to make cheaper. | Yes Self-hosted cost is the server, so it is largely flat as volume rises. You take on the running of it in exchange. |
| Who carries the operational burden | Yes Zapier does. Upgrades, uptime and connector maintenance are theirs. | No You do, on the self-hosted path — patching, backups, monitoring. That is a real cost even when the licence is free. |
| Per-connector reliability at scale | Not assessed Not measured. The register publishes what each vendor documents; observed reliability at scale is the column still empty. | Not assessed Same. Anyone comparing this from marketing pages is guessing. |
Where the cost curves cross
Task-based billing is cheap at low volume and stops being cheap at exactly the point automation starts working. That is not a criticism — it is a genuinely fair model, and it means you pay in proportion to value received. But it does mean success costs more.
A self-hosted instance inverts that: the cost is a server, so it barely moves as volume rises. What you pay instead is attention — someone has to patch it, monitor it and restore it when it breaks. If that someone is you and you did not budget for it, the "free" option is the expensive one.
The honest framing is that Zapier converts operational risk into a bill, and self-hosted n8n converts a bill into operational risk. Which trade suits you depends on whether you have anyone to carry the second. If the answer is us, that is a line on what recurs rather than a hidden cost.
When we reach for each
Zapier where the workflow is small, the volume is modest, and nobody at the business wants to be responsible for a server. It is also the right answer when the client will maintain it themselves after we leave, because the failure modes are visible in a UI.
n8n where volume is high enough that per-task billing hurts, where the logic is complex enough to want real branching and code steps, or where data residency matters and it needs to run on infrastructure we control — see where things actually run.
- KNDR·01Low volume, no ops capacityZapier. The bill is small and somebody else carries the uptime.
- KNDR·02High volume, repetitiven8n self-hosted. This is where task billing starts to compound against you.
- KNDR·03Complex branching or custom coden8n. More room to work, at the cost of more to understand.
- KNDR·04Client will maintain it themselvesUsually Zapier. Legibility beats capability when you are handing over.
- KNDR·05Data must stay on known infrastructuren8n self-hosted, on our servers or yours.
What neither of them fixes
Both are plumbing. Neither will fix a process that changes every month, and neither will make a decision that needed judgement. Put an unstable process into either one and you get unstable output on a schedule — which is the first item on what not to automate.
And past a certain complexity, a platform stops being cheaper than a small purpose-built service. Fifteen chained steps with error handling bolted on is usually a sign you have outgrown the visual builder — where that line sits is its own page.
What we won’t claim here
We have not published rate limits, per-connector quirks or failure rates for either platform, and you should be suspicious of any comparison that does without saying how it measured them.
The capability register now publishes what each vendor documents about its own API, which fills in some of what those rows want. What it does not publish is measured behaviour under load, because publishing a figure we cannot show the working for is the same as making it up. Treat this as a decision framework with verified structural facts in it, not a benchmark.
The questions people actually ask.
01Isn’t self-hosting always cheaper?
On the licence, yes. On the total, frequently not — you have taken on patching, monitoring, backups and the 2am restore. If nobody at your business owns that, the hosted option is cheaper in the way that matters.
02Why not just pick the one with more connectors?
Because you will use four of them. Connector count is the easiest number to market and the least predictive of whether the two systems you actually run will talk cleanly.
Stop bending.
Start shipping.
Bring the one flow that keeps costing you a Tuesday afternoon. We map it live and tell you what we'd build, what we wouldn't, and what it costs.