n8n vs Make vs Zapier: picking the layer everything else runs on

Somewhere between the tools your company already pays for and the AI work you want done, there’s a layer that moves data around and decides what happens next. Pick it once and you live with it for years, because everything you build sits on top of it.

Three products dominate that decision. We run n8n, we’ll explain why, and we’ll be specific about the situations where recommending it would be wrong.

The short version

Zapier if the people maintaining the automations don’t write code and never will. Make if you want visual building with real branching and you’re watching the bill. n8n if you need self-hosting, EU data residency, agent loops rather than linear steps, or you’re running enough volume that per-task pricing starts to hurt.

For a German Mittelstand company doing anything with customer data, that mostly resolves to n8n, and the reason is residency rather than features. Everything below is the argument.

What they’re actually competing on

They all connect apps and run workflows. The differences that matter after month three:

Where it runs. Zapier and Make are cloud only. Your data goes through their infrastructure, on their terms. n8n is open source and self-hostable, so it can run on a server you control, in a country you choose.

For a lot of DACH companies that single line decides it before anyone compares features, and no amount of connector count changes it.

What it costs at volume. All three look cheap on the pricing page. They diverge sharply once real traffic arrives, and the shape of the divergence is the most important thing in this article.

Whether it can loop. All three have native nodes for OpenAI, Anthropic and Google models, so “has AI” is not a differentiator anymore. What differs is the control flow. Zapier and Make run AI steps inside linear or conditional workflows: call the model, take the output, move on. n8n supports agent loops, where the model can call a tool, look at the result, decide it needs something else, and go again until it’s done. If you’re building agents rather than pipelines, that’s a structural difference and not a feature-list one.

Head to head

	Zapier	Make	n8n
Entry price	~$19.99/mo	~$9/mo	~$20/mo cloud, free self-hosted
Self-hosting	No	No	Yes, open source
EU data residency	Vendor-controlled	Vendor-controlled	Yours, if self-hosted
Pricing model	Per task	Per operation	Per execution, or unmetered self-hosted
Connectors	Most, by a wide margin	Many	Many, plus generic HTTP
AI model nodes	Yes	Yes	Yes
Agent loops with tools and memory	Limited	Limited	Native
Custom code in workflows	Limited	Some	Full JavaScript and Python
Who can maintain it	Anyone	Ops-minded generalist	Someone technical

The cost curve, which is the real story

Entry prices are close enough to be noise. Here’s what happens as volume grows.

At 10,000 tasks a month, a small-business load, Zapier lands somewhere around $69 to $299 depending on plan and how many steps each task has. Make handles the same volume for roughly $16 to $29. Self-hosted n8n handles it on a VPS costing $5 to $10, because you’re paying for a server rather than for events.

At 50,000+ runs a month, self-hosted n8n can come in 80 to 90 percent below the equivalent Zapier bill.

The billing unit is the whole difference. Zapier charges per task (one step), Make per operation (one module run), n8n per execution (one whole workflow, however many steps).

Published pricing, all three vendors, checked July 2026

The mechanism is worth understanding rather than just the numbers. Zapier and Make charge per task or per operation, and a “task” is one step, not one workflow. A seven-step automation firing a thousand times a month is seven thousand tasks. That’s why people’s Zapier bills jump in ways they didn’t predict: the pricing scales with workflow complexity and with volume at the same time, and complexity is exactly what grows as your automations get good.

Self-hosted n8n has no such meter. A workflow with forty nodes costs the same as one with three, which quietly changes how you build. You stop optimising workflows to save money and start optimising them to be correct, which is the better use of anyone’s afternoon.

The honest counter: self-hosting isn’t free, it’s just billed differently. You’re paying in operations. Someone has to run the server, apply updates, hold backups, and be reachable when a workflow queue backs up at 23:00. If nobody on your team owns that, n8n’s cost advantage is theoretical and your real total cost is higher than Zapier’s, not lower. That’s not a footnote, it’s the actual decision.

When Zapier is the right answer

When the person maintaining it is in marketing, ops or sales, and the whole point is that they don’t need engineering to change something.

Zapier’s connector library is the largest by a distance, its interface is the most forgiving, and the failure mode is mild: something breaks, you get an email, you go and fix it in a UI that explains itself. For a ten-person company wiring a form to a CRM to a Slack channel, Zapier is correct and the money is well spent.

When it’s wrong: high volume, many-step workflows, anything where data residency is a requirement, or agent behaviour more complex than “call model, use output”. You’ll feel the ceiling as a bill before you feel it as a limitation.

When Make is the right answer

When you want to see the flow as a picture and you need genuine branching, iteration and error handling, but you don’t want to run infrastructure.

Make’s per-operation pricing is meaningfully cheaper than Zapier’s at mid volumes, and the visual builder makes complex routing legible in a way linear step lists don’t. For a team with someone ops-minded but no engineer, doing moderately complex work, Make is often the best value in the category.

When it’s wrong: still cloud only, so residency is still the vendor’s decision. And at high volume you’re still on a meter, just a cheaper one.

When n8n is the right answer

Four situations, and one is enough.

Data residency is binding. You self-host in the EU, on your own server, and the answer to “where is customer data processed” is a place you can point to on a map. This is the reason most of our DACH clients end up here, and it’s not really a preference.

You’re building agents, not pipelines. Tool calling, memory across executions, retrieval, human-in-the-loop approval steps. n8n’s agent support is built for this rather than adapted to it.

Volume is high or workflows are long. The unmetered self-hosted model changes the economics permanently.

You need real code. Full JavaScript and Python in a node, without the awkwardness of trying to express logic through a UI that wasn’t designed for it.

When it’s wrong: when nobody technical owns it. n8n gives you a server to look after and a tool with sharper edges. Handed to a team that can’t maintain it, it becomes a set of workflows nobody dares touch, which is worse than a Zapier bill.

What we run, and why

We build on n8n, self-hosted, for client work. Three reasons, in order.

Residency, first and mostly. When a German company asks where their customer data goes, “a server in Frankfurt that you can audit” is an answer that survives a procurement review. “A US cloud automation vendor, under Standard Contractual Clauses” is an answer that generates a meeting.

The agent model, second. What we build is rarely a straight line. It’s a thing that reads something, decides, fetches more, decides again. That maps onto n8n’s agent nodes and awkwardly onto the others.

Cost predictability, third and least. It matters, but it’s the reason we’d rank last if the first two didn’t hold.

We’d still put a client on Zapier without hesitation if their situation called for it: a small team, no technical owner, no residency requirement, straightforward workflows they want to change themselves. Recommending infrastructure to a company that can’t run infrastructure isn’t rigour, it’s a handover that fails in month two.

The thing this decision isn’t

Worth saying, because it gets conflated: the orchestration layer is plumbing. It’s a standard, commoditised piece, and all three options are competent. Nobody’s business outcome improved because they picked the better workflow tool.

What changes outcomes is what runs on top: whether the agent classifies correctly, whether the data it reads is clean, whether a human is in the loop at the right step, whether anyone actually uses the output. Those are design questions, and the platform is close to irrelevant to all of them.

So make this decision on residency and on who’ll maintain it, take about an afternoon over it, and spend the saved time on the part that’s actually hard.

If you want the layer above the plumbing built, book a strategy call.

Frequently asked questions about n8n, Make and Zapier