n8n vs Zapier vs Make: A Build Engineer’s Comparison

Three tools, one job: move data between systems without standing up a service for it. The differences that matter are not the app-count numbers on the marketing pages. They are how you get billed, whether you can run the thing on your own infrastructure, and what happens at 3am when a downstream API starts returning 500s.

I ship automation for teams in the US, UK and UAE, and I have run production workflows on all three platforms. This is the n8n vs Zapier vs Make comparison I give when a client asks what to standardise on, written from the maintenance side rather than the demo side.

n8n vs Zapier vs Make: which one should you choose?

Choose Zapier if non-technical staff will own the workflows and you need a long tail of SaaS connectors. Choose Make if an ops person needs branching, iteration and data mapping on a visual canvas. Choose n8n if engineers own the automation, the payloads are large, or the data cannot leave your infrastructure.

How does pricing differ between n8n, Zapier and Make?

The three platforms meter completely different things, and that single fact decides the bill more than the headline tier price. Zapier counts tasks, Make counts credits, n8n counts executions. Most n8n vs Zapier vs Make cost comparisons ignore this and compare tier prices, which is why the invoices surprise people.

Zapier's own guidance is that a task is counted whenever it successfully completes a unit of work, and that triggers, polling and built-in data tools do not consume tasks. Make's pricing page now describes billing in credits, where most actions consume one credit and some AI-backed features consume more. n8n bills per execution regardless of how many nodes the workflow contains.

The crossover point is worth finding before you commit. Multiply your average step count by your monthly run volume, then compare that number against the task or credit allowance on the tier you were planning to buy. If the multiplication pushes you two tiers up, per-execution billing is already the cheaper architecture.

Vendor prices move constantly, so treat the tier numbers on any blog post as stale on arrival, including this one. Check the official pricing pages before you commit. The structural point survives the changes: if your workflows are long and run often, per-step billing compounds against you, and that is the single strongest argument for running automation on n8n instead of Zapier or Make.

"Per-step billing quietly taxes good engineering. The cleanest workflow, with proper validation and error branches, is also the most expensive one."

Can you self-host n8n, Zapier or Make?

Only n8n. Zapier and Make are cloud-only products with no on-premise distribution, so your data always transits their infrastructure. n8n publishes a self-hostable community edition you can run in Docker on your own VPS, in a VPC, or on Kubernetes.

One correction people get wrong constantly: n8n is source available under a fair-code licence, not standard OSI open source. In practice that means you can run it freely for your own business, but you cannot repackage it and resell hosted n8n as your own product. Read the licence before you build a client-facing SaaS on top of it.

Self-hosting is not free, it is a swap. You trade a subscription for a Postgres instance, a queue mode setup, backups, upgrades and someone on call. I have walked through that maths in detail in self-hosting n8n: costs, trade-offs and when not to, and the honest conclusion is that plenty of teams should stay on the cloud version.

Which tool has the best code escape hatch?

n8n, and it is not close. The Code node runs JavaScript or Python over the full item array, and on a self-hosted instance you can allow external npm modules through an environment variable. Zapier offers code steps with per-plan runtime caps. Make is the most constrained: inline functions and mapping expressions, with anything real pushed into a custom app.

This matters more than it sounds. Every integration eventually hits a payload the visual mapper cannot express: a nested array that needs regrouping, a signature that needs HMAC, a date format nobody standardised. On n8n you write eight lines and move on. On the other two you either chain five modules or build a custom app.

// n8n Code node: flatten a nested API response into one item per contact
const out = [];
for (const item of $input.all()) {
  for (const contact of item.json.company.contacts ?? []) {
    out.push({
      json: {
        company_id: item.json.company.id,
        email: (contact.email ?? "").trim().toLowerCase(),
        role: contact.title ?? null,
      },
    });
  }
}
return out;

There is a limit to this, and I enforce it on every build. Once a Code node passes roughly 150 lines or grows its own tests, it stops being automation glue and becomes an application. Move it into a FastAPI service, expose one endpoint, and call it from an HTTP Request node. That is exactly how the distributed web scraping platform is structured: heavy extraction in Python, orchestration and retries in the workflow layer.

How do n8n, Zapier and Make handle errors?

All three can retry and alert. The difference is how much control you get over the failure path, and n8n gives the most: per-node retry settings, an error output branch you can wire like any other connection, and a dedicated error workflow that fires when a run dies.

That pattern is what kept the Indonesia livestock operations dashboard trustworthy: field devices drop off constantly, so the pipeline has to distinguish between a failed ingest and an empty one, then replay the first without corrupting the second.

Which one is actually usable for AI agents?

n8n, if you want to see and control the graph. Its AI Agent node is built on LangChain primitives, so you compose a model, a memory store, and a set of tools explicitly, and you can point it at OpenAI, Anthropic Claude, or a model you host yourself. Zapier and Make both ship agent features, but the orchestration is packaged rather than exposed.

For retrieval work the gap widens. n8n has vector store nodes that talk to pgvector on Supabase, which means your embeddings live in a database you already own and can query with plain SQL. In the packaged tools, the vector layer is usually theirs, and you inherit whatever chunking and retrieval strategy they chose.

The honest caveat: packaged agents are faster to a working demo. If a marketing team wants an assistant that drafts replies from a knowledge base this quarter, Zapier or Make will get there sooner. When the agent needs tool calls with side effects, audit trails and cost controls, you want the explicit graph, which is the architecture behind most of my AI automation work.

How do team workflows and governance compare?

Zapier and Make handle collaboration in-app; n8n handles it like software. Zapier's Team plan adds shared Zap access, folder permissions and shared app connections. Make organises work into teams and organisations with scenario folders. n8n's higher paid tiers add Git-based source control and separate environments, which is what you want once workflows are part of a release process.

On self-hosted community n8n you get none of that automatically, but every workflow is JSON, so exporting and committing it to a repository takes an afternoon to wire up. That is usually enough to get code review and rollback on automations that touch billing or customer data.

Credentials deserve their own thought. All three store secrets separately from the workflow definition, which is the correct model, but only self-hosted n8n lets you keep those secrets inside your own network boundary. For regulated clients that single fact ends the debate.

Portability is the governance question nobody asks until they need it. Zapier and Make workflows can be exported, but only into formats those platforms read, so leaving means rebuilding. n8n workflows are plain JSON you can diff, template and move between instances, which is why agencies deploying the same pipeline to many clients tend to converge on it regardless of price.

My picks by scenario

There is no universal winner in n8n vs Zapier vs Make, so here is the decision I would make in each concrete situation, assuming a team that has to maintain the result for at least a year.

Most teams I work with end up with two: n8n owning the engineered pipelines and one commercial tool covering the odd connector nobody wants to build. That is not indecision, it is scoping. If you are starting from zero on n8n, the beginner n8n tutorial walks through the first workflow end to end, including the error branch most tutorials skip.