Zapier vs n8n

Self-hosting is the headline reason people reach for n8n, and it is worth being precise about what it buys, because the honest answer is that most people asking for it do not need it.

Start with what an automation platform touches. It is not only the small piece of data you were thinking about. The trigger payload arrives in full, every intermediate step keeps a copy while the workflow runs, and the execution history holds those copies afterwards so you can debug a failure — which is the whole reason the history exists. If your workflow moves patient records, legal files, payroll or anything covered by a contract that names which processors may hold it, the question is not whether the vendor is trustworthy. It is whether a third party is permitted to hold that data at all, and who you can point to in an audit.

The genuine cases are recognisable: a regulator or a client contract that restricts where records may be processed, a data-residency requirement tied to a specific country, an internal policy written before anyone thought about automation, or a system that lives behind a firewall and simply has no public endpoint for a hosted service to call. In those situations n8n is one of the few credible options, and its own write-up on this site says exactly that.

Now the counterweight, which most comparisons skip. If the apps at both ends of your workflow are already hosted by other companies — your CRM, your email, your spreadsheet, your ticketing system — then self-hosting the orchestrator moves the boundary a surprisingly short distance. The records were in someone else's cloud before the automation ran and they will be in someone else's cloud after it finishes. You have removed one processor from the middle of a chain of several. That can still be the difference between compliant and not, and it is a real improvement in blast radius. But if the motivation is a general unease rather than a written obligation, be honest that you are buying a feeling and paying for it in maintenance.

The other thing self-hosting genuinely buys is independence from a pricing change. Nobody can reprice a server you already own, and nobody can retire a plan you are on. Whether that is worth the work depends on the next section.

Running the software yourself is free in the same sense that a second-hand car is cheap. The purchase price is not the number that matters.

The recurring work is unglamorous and never finishes. Somebody applies updates, and occasionally an update changes the behaviour of a step in a way your workflow did not expect. Somebody renews certificates. Somebody takes backups, and — the part that is routinely skipped — restores one occasionally to check the backups are real. Somebody notices when the machine runs out of disk because months of execution history accumulated. Somebody restarts the service after an unplanned reboot and confirms the workflows came back with it. Somebody keeps credentials for a dozen connected apps safe on that box, because a self-hosted automation server is a concentrated pile of access tokens and is therefore worth attacking.

None of that is hard. It is simply continuous, and it needs an owner with a name. The failure pattern is predictable and common: one capable person sets it up, everything works, they change jobs, and eighteen months later there is a small unpatched server quietly holding credentials to the company's systems that nobody remembers deploying. If you cannot answer the question of who maintains this after the person who built it leaves, the managed cloud option is the better decision even when self-hosting is technically available to you.

This is also why the n8n write-up here recommends starting on the cloud trial. Learn the tool first, move it later if you must. A migration from hosted to self-hosted is a known, bounded task. Learning an unfamiliar platform while also learning to operate it is two problems at once, and you will blame the wrong one when something breaks.

No prices here, and not out of caution alone: automation pricing gets restructured often enough that a number would mislead more than it helps. What is stable is the shape of the curve, and the shapes are genuinely different.

A hosted service meters what it runs for you, so your bill tracks volume almost directly. Double the number of things that happen and you roughly double the cost. That is fine when volume is small and predictable, and it stops being fine at a threshold most people meet by accident rather than by planning — a trigger that fires on every row instead of every batch, a workflow that turns out to run on weekends too, a step added to a chain that already ran thousands of times a month. Zapier's own limitations list on this site names this plainly: costs scale with volume and busy workflows get expensive faster than expected.

The detail that catches people out is what each platform counts. Metering can be based on individual steps or on whole workflow runs, and the two produce very different bills for the same work. One eight-step workflow running once looks cheap under one model and expensive under the other. At the time of writing these platforms do not count the same unit, which makes any head-to-head cost claim unreliable in the abstract — the only sound method is to estimate your own monthly run count, multiply by the steps in your actual workflows, and read both pricing pages against those two numbers.

Self-hosting has a different shape entirely: mostly flat, set by the size of the server rather than by how often the workflow fires, and rising in steps when you outgrow the machine. That is why it becomes attractive at high volume and is poor value at low volume. There is a crossover point, and it sits wherever your run count meets the cost of the hours you will spend maintaining the thing. People comparing a subscription against a small server bill usually forget to price the second half of that, which is why self-hosting looks like an easy win far earlier than it actually is.

One cost applies to both and is easy to miss when budgeting. AI steps consume model credits from whichever provider you connect, on top of whatever the platform charges. An automation that calls a model once per record has a second meter running that scales the same way the first one does.

This matters to a minority of readers and matters a great deal to them, so it is worth stating carefully.

Source-available is not the same as open source, even though you can read the code in both cases. Open-source licences, in the sense the term is normally used, do not restrict who may use the software or for what purpose. A source-available licence publishes the code while keeping conditions on some uses — commonly the ones where you would be offering the software to other people rather than running it for yourself. n8n sits in that second category, and its own entry on this site flags it as a limitation for exactly this reason.

In practice the distinction rarely bites for internal use. A company running workflows for its own operations is the ordinary case the licence anticipates. The questions start when the automation stops being your back office and becomes part of what your customers buy: embedding the workflow builder in your own product, running instances on behalf of clients, reselling access, or building a service whose value is largely the platform you did not write. If any of that describes your plan, read the actual licence text before you build the roadmap around it, and get proper advice if the answer is commercially significant. Nothing on this page is legal advice.

Zapier does not present this question because there is nothing to self-host: you use a hosted product under its terms, and if you want to extend it you do so through the routes the platform provides. Simpler, and a different kind of constraint — you are working inside somebody else's product either way, but with a hosted service the boundaries are set by terms of service rather than by a licence attached to code you are running.

Both tool write-ups on this site list the same weakness, and it is the single most useful thing to understand before you automate anything: a workflow that stops working does so silently.

The mechanism is structural rather than a defect in either product. A working automation produces no signal — that is what you wanted, and it is why it saves you time. A broken one produces the same absence of signal. There is no moment where a person notices, because the entire point was that no person was involved. So a token expires, a connected app renames a field, someone edits a column header in a spreadsheet, a rate limit trips during a busy hour, and the workflow begins failing at a step that used to work. You find out weeks later through a downstream absence: the report nobody filed, the leads that never reached the sales inbox, the backup that has not run since spring.

Debugging when you do notice is slow on either platform, and it gets worse as workflows grow. You are reading an execution log to reconstruct what a chain of third-party APIs did days ago, with no ability to reproduce the exact input that failed. This is the part that people underestimate most, and it is one of the few places where self-hosting is genuinely harder: you also have to rule out your own server before you start blaming the workflow.

A handful of habits make it survivable, and they are the same on both platforms. Turn on failure notifications the day you build the first workflow, not after the first incident. Automate something small and boring first so you learn how the platform reports errors before you need that knowledge under pressure. Build one workflow with no AI step in it at all, so you have seen the platform's ordinary retry and error behaviour on its own. Where an automation matters, add a positive heartbeat rather than relying on error alerts — a weekly line in a log you actually read is better than an alert that depends on the failing thing being able to report its own failure. And audit occasionally: delete the workflows nobody needs any more, because an unused automation still costs money and still holds credentials.

When an AI step is in the chain, the stakes change slightly. A broken connector stops; a model that misreads its input keeps going and produces confident nonsense at speed. The guardrails and human-in-the-loop lesson covers where to put a checkpoint, and the delegate a task safely template is a reasonable way to think through what an automated step is allowed to do before you let it run unattended.