Zapier or n8n? Where it runs decides it.

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.

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.

• Low volume, no ops capacity Zapier. The bill is small and somebody else carries the uptime.
• High volume, repetitive n8n self-hosted. This is where task billing starts to compound against you.
• Complex branching or custom code n8n. More room to work, at the cost of more to understand.
• Client will maintain it themselves Usually Zapier. Legibility beats capability when you are handing over.
• Data must stay on known infrastructure n8n 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.