n8n vs Zapier vs Make: How to Choose

Every time someone asks me n8n vs Zapier vs Make, they want a winner, and what they actually need is to know which unit each platform bills them in — because that one detail decides the price of everything they will ever build on it. The operator learned this the expensive way on a content workflow that fetched a row, called a model, wrote a file, posted to three platforms, and logged the result. Seven steps. Run it 400 times a month and one platform charges you for 400 things, another charges you for roughly 2,800. Same work. Same outcome. Different meter.

That is the whole comparison, distilled. Everything below is the elaboration.

What n8n vs Zapier vs Make actually differ on

Ignore the feature grids for a minute. All three are the same shape: a trigger fires, data moves through a series of steps, something happens at the end. All three have a visual builder, a few hundred to a few thousand app integrations, error handling, scheduling, and webhooks. If your workflow is “new row in a spreadsheet, send a Slack message,” all three will do it today in under five minutes and you will never notice a difference.

The differences show up in three places, and only three:

The billing unit. Zapier counts tasks — one task per step that successfully acts on data. Make counts operations — roughly one per module call, with iterators and array handling generating operations per item. n8n counts workflow executions — one per run, whether the workflow has three nodes or ninety.

The escape hatch. When the visual builder runs out of road, what do you get? Zapier gives you a sandboxed Code step. Make gives you formula functions and a limited scripting surface. n8n gives you a Code node with real JavaScript or Python, npm modules on self-hosted instances, and direct access to the full item array flowing through the workflow.

The hosting story. Zapier and Make are cloud services, full stop. Your data flows through their infrastructure and that is the deal. n8n ships a self-hostable edition under a fair-code license alongside its managed cloud, which means the same workflow JSON can run on their servers or yours. I have covered that tradeoff in detail in n8n cloud vs self-hosted.

Everything else — the integration counts, the template galleries, the onboarding polish — is real but secondary. Those three axes are what you will still care about in a year.

How much does each one cost?

List prices move, so treat these as the shape of the pricing rather than a quote; check the current page before you commit. As of September 2026 the structure looks like this.

Zapier has a free tier at 100 tasks per month with single-step Zaps, then paid tiers that scale by task volume — the entry paid plan lands around $20/month for a few hundred tasks and climbs steeply. Multi-step Zaps, paths, and webhooks live behind the paid tiers. The thing to internalize: a five-step Zap burns five tasks per run.

Make’s free tier is more generous on raw volume — around 1,000 operations per month — and its entry paid plan starts near $9-10/month for roughly 10,000 operations. Operations are cheaper individually than Zapier tasks, but they multiply fast when you iterate over arrays. A module that processes 50 items can cost 50 operations depending on how the scenario is built.

n8n Cloud starts around €20-24/month for a couple thousand executions, and the self-hosted community edition costs you nothing but a server — a $6 VPS runs a modest instance comfortably. I broke the tiers down properly in n8n pricing explained.

The arithmetic that matters: take your busiest workflow, count the steps, multiply by expected monthly runs. That number is your Zapier bill’s input. For n8n, the multiplier is 1.

Here is the same logic in code, because it is the single calculation most people skip:

runs_per_month = 400
steps_per_run = 7

zapier_tasks = runs_per_month * steps_per_run      # 2800
make_operations = runs_per_month * steps_per_run   # ~2800, plus per-item iteration
n8n_executions = runs_per_month                    # 400

print(f"zapier: {zapier_tasks} tasks")
print(f"make:   {make_operations}+ operations")
print(f"n8n:    {n8n_executions} executions")

This is also why batching behaves differently on each platform. On n8n, collapsing 50 API calls into one workflow run that loops internally still costs one execution. On the per-step platforms, the loop is the cost.

Which one handles AI agents?

This is where the gap is widest, and it is the reason my own stack landed where it did.

Zapier has AI actions and a Copilot that drafts Zaps from a description. It is competent glue: call a model, get text back, put the text somewhere. What it is not built for is a loop where the model decides which tool to call next, calls it, reads the result, and decides again. That distinction — fixed pipeline versus decision loop — is the difference between a workflow and an agent.

Make sits in a similar place. You can wire an LLM module into a scenario, route on its output, and build something quite sophisticated with routers and filters. The visual branching is genuinely the best of the three — if your logic is a shape, Make draws it better than anyone. But the model is a step in your flow, not a driver of it.

n8n ships an AI Agent node with tool-calling, a memory buffer, and a set of LangChain-flavored building blocks. You attach tools as sub-nodes, hand the agent a system prompt, and it runs the observe-decide-act loop natively. You can point it at Claude Opus 4.8, Sonnet 4.6, or Haiku 4.5 through the Anthropic node, or at any OpenAI-compatible endpoint. That is a materially different capability, not a nicer wrapper, and it is why n8n vs Zapier stopped being a close call for me once agents entered the picture.

The honest caveat: agent nodes in any visual builder are harder to debug than agent code. When the loop misbehaves you are reading execution logs instead of stack traces, and the failure modes are the quiet kind — an agent that confidently calls the wrong tool and reports success. I wrote about that whole category in why AI automation keeps breaking.

Self-hosting, data, and the exit cost

If your workflows touch customer records, health data, or anything a compliance officer has opinions about, the hosting axis stops being a preference and starts being a requirement. Zapier and Make both hold enterprise certifications and are perfectly legitimate processors — but the data does leave your perimeter, and for some builds that is a non-starter.

n8n self-hosted keeps every payload on infrastructure you control. The community edition is free under a sustainable-use license that permits internal business use; you pay for an enterprise license if you need SSO, log streaming, or external-facing multi-tenant deployment. The tradeoff is that you now own a Postgres database, a queue, container updates, and backups. That is a real job, not a free lunch.

The under-discussed cost is exit. There is no shared export format between these three. Fifty workflows built on one platform are fifty workflows to rebuild by hand if you switch, plus re-authenticating every OAuth connection. Nobody budgets for this and everybody eventually pays it. The comparison that helped me most before I committed was make vs zapier comparison, because it made clear how differently the two model the same logic — which is exactly the friction you hit when migrating.

The decision framework

Five questions, in order. Stop at the first one that gives you a clear answer.

1. Does your workflow need a model that chooses its own next action? If yes, use n8n. The agent node exists and the alternatives are approximations.
2. Do you have a hard data-residency or self-hosting requirement? If yes, use n8n. It is the only one of the three you can run on your own box.
3. Is your workflow more than five steps, running more than a few hundred times a month? If yes, lean n8n, because per-execution billing removes step count from the cost equation entirely.
4. Is your logic mostly branching, merging, and iterating over messy arrays — and you want to see it as a diagram? Lean Make. Its router-and-iterator model is the clearest visual representation of complex flow logic I have used.
5. Do you need an obscure SaaS integration that must work today, with zero setup, and nobody on the team writes code? Use Zapier. Its integration catalogue is the largest by a wide margin and its onboarding is the smoothest. You are paying a premium for coverage and polish, and sometimes that is the correct purchase.

If you got to the bottom without a clear answer, your workflow is simple enough that the choice does not matter yet — start on a free tier and revisit when volume makes the bill visible.

What I actually run, and where each one wins

My pipelines run on n8n. Not because the other two are bad, but because my workload is exactly the shape n8n is priced for: long multi-node workflows, invoked on a schedule, with model calls embedded in them. The social pipeline that fans one piece of content to five platforms is a single execution regardless of how many nodes it fires. The full breakdown of where n8n has bitten me, including the responseMode incident that double-charged a customer four times, is in my n8n review.

That said, I would not talk a small team out of Zapier if their bottleneck is a niche CRM integration and nobody wants to maintain a server. And Make genuinely draws complex branching better than n8n does — the first time I built a router-heavy scenario there, the diagram explained itself in a way an n8n canvas does not.

n8n vs Zapier vs Make ultimately comes down to matching the platform’s billing unit to the shape of your work, not the one with the best landing page. Everything else you can learn in a weekend.

If you want to see what these workflows look like once they stop being demos, the actual prompt and config files my fleet runs on are in the fleet files — real files, not screenshots, unlocked with an email.

And if reading all that made the build sound like someone else’s weekend, that is what /hire/ is for — tell us the problem and we will wire it up with AI.