Zapier or n8n: where the automation runs, and who owns it

Zapier is the better answer when the automation is a mapping between two services you do not control, nobody on your team wants to run a server, and the volume is modest. n8n is the better answer when the data cannot pass through somebody else's infrastructure, when the flow carries code you want kept in a repository, or when volume turns per-task pricing into a line someone signs off. Underneath both, the real question is the same one: who is on call when a run fails at two in the morning.

What each of them actually is

Zapier is a hosted runner. A trigger arrives from an application, a few steps reshape the data, an action calls another application, and the vendor keeps the logs, the credential store and the uptime. You never see a server, you are charged per task, and the catalogue is the product: almost every service you already pay for has a maintained connector, and somebody else fixes it when that service changes its API.

n8n is a node graph you can install. It does the same work — trigger, transform, act — but it can run on a machine you control, it can execute code inside a step, and a workflow can be exported and versioned like a file. It also offers a hosted version, which removes most of the "you run it" argument; what remains is licence and location rather than effort.

One clarification, because it is repeated everywhere and it matters if procurement asks: n8n is source-available under its own licence, which is not the same thing as an OSI-approved open-source licence. Read the licence itself, not a comparison article — including this one.

Where Zapier is the right answer

• Breadth. The specific app your accountant uses is probably supported. That is not a small thing: the alternative is writing and maintaining that connector yourself.
• Nobody runs infrastructure. No server to patch, no certificate to renew, no backup to test. For a team without an operations function, that is the whole argument.
• A non-technical owner can maintain it. The person who understands the process changes the flow without a ticket. That is real leverage, and it is why these tools spread inside companies.
• The failure is somebody else's problem. When a connector breaks because a vendor changed something, you are not the one debugging it on a Friday evening.

Where n8n is the right answer

• The data stays where it is. If the flow touches payroll, patient records or identity documents, "it passes through a third party's servers" is a decision, not a detail.
• You already have somewhere to run it. A server, a container platform, a machine in the office. If that exists, the marginal cost of hosting a workflow engine is close to nothing.
• Code belongs in the flow. A step that needs a real conditional, a checksum, a retry policy or a call to your own database is where a visual builder becomes a cage.
• The workflow is a file. Export means it can be reviewed, diffed and restored. A flow that exists only inside a vendor's account is a process you cannot back up.

The comparison that decides it

Question	Zapier	n8n
Who runs it	the vendor, always	you — or the vendor, on the hosted option
Where the data passes	their infrastructure	your network, when self-hosted
Writing real code	as far as the step allows	a code step that runs what you write
Year two	they update, you adapt	you upgrade, you test
What to verify on the vendor's page	plan limits, the apps you depend on, licence terms	hosting and licence terms, and whether the version you install is supported

That last row is not a formality. An article cannot tell you the price, the plan limits or the licence terms of a product that keeps changing them; if it does, it is describing a previous version of the product.

What neither of them fixes

Both are glue, and glue has a ceiling:

• Atomicity. An order created in the shop and reserved in stock is one decision with two effects. A connector retries; it does not compensate. When the second write fails, the first stays, and the record is half true.
• Idempotency. Triggers fire more than once — a retry, a replay, a user pressing the button twice. Without a key you control and a check before the write, the second run creates the second invoice.
• Permission. A flow runs as one connected account, usually an administrator's, with rights far beyond the task. When the log says the integration changed a price, nobody can tell which person meant it.
• Partial failure. When a flow half completes, one system has moved and the others have not. Survivable if a human is told; corrosive if the only trace is a log nobody opens.

None of that is a defect in either product. It is what "connector" means: a tool that moves a record and tells you it happened, not a system that guarantees a transaction.

The honest default for a single integration

If the task is "each morning, take what changed in the export, put it into the other system, and mail me when the totals disagree", that is a script: one input, one rule, one output, and a failure that lands in an inbox. Not because a script feels more professional, but because the specification fits on a page.

A platform earns its place when many small flows, owned by people who are not developers, change often — an operations team wiring a form to a sheet to a courier. There the visual editor is the point, and neither Zapier nor n8n is the wrong purchase. The mistake is buying the platform for a job that never changes.

How to decide, in order

1. Write the rule in one sentence: the event, the effect, and who notices when it does not happen. If it needs a paragraph, model it before you automate it.
2. Ask whether the data may leave your infrastructure. If it may not, the hosted option is out and the argument ends there.
3. Name who maintains it in year two. A flow only one person understands, in a tool nobody else opens, is a dependency with a subscription.
4. Count the writes into systems of record. More than one in a single flow is a transaction question, and neither product is the answer to that.
5. Test the one flow that matters, including a deliberate failure. A demo that succeeds proves nothing about a retry.
6. Estimate the volume and the cost of a failed run. Low and irregular favours a hosted tool; high and regular may favour a scheduled job that is neither product.
7. Build the smallest version first. Move it when a signal appears — volume, a duplicated record, a data-residency objection — not because a script feels more serious.

Where this goes wrong

• Flows calling flows. A chain nobody can trace, where a record's path is reconstructed from logs read backwards.
• The connector as the source of truth. A lookup table in a spreadsheet the flow reads, unbacked up and unowned, quietly deciding what the automation believes.
• One administrator account for everything. When that person leaves, every flow breaks at once — or keeps working with their rights.
• No alert to a human. Silent failure found at month end, when the totals no longer reconcile.
• A connector used as a queue. Flows are not built to hold work under load, and a backlog inside one is invisible until it is a week long.
• Rebuilding a flow as a script and dropping the retries. Retrying was the gift; a script without it is worse than what it replaced.

When neither fits

If two systems both claim the same record, the fix is ownership — one writes, the other reads — and no flow repairs it. If the rule is genuinely your competitive advantage, it belongs in code you own, with the connector left at the edges where the mapping is trivial. When the automation must be transactional, or runs at a volume where per-run cost dominates, the answer is a small service you own and can test: one writer, a queue, and a reconciliation report.

That is not a better product; it is a different shape of work. It is what we build when the integration carries money rather than notifications.

Where this advice stops

No prices, plan limits or integration counts appear here on purpose: they change faster than a page can be corrected, and a stale figure is worse than none. It assumes both systems expose an API and that somebody answers when one of them changes it. It does not cover regulated data, where the question is not where the flow runs but who may see the payload, nor jobs that must complete in order with money attached.

We build and integrate systems around tools like these, we resell neither product, and we take no commission, so the recommendation carries no commercial interest.