n8n, Zapier or Make, and the four questions that decide which you build on

The answer in three lines

Pick Zapier when the connection you need already exists in its catalogue and a non-technical person will be the one maintaining it. Pick Make when the workflow branches, loops or processes a list of records inside a single run. Pick n8n when the workflows have to sit on infrastructure you control, when parts of the logic want real code, or when the volume makes per-step pricing uncomfortable.

One factual difference outranks every feature comparison. n8n can be self-hosted; Make and Zapier cannot. If a contract, an auditor or an internal policy requires that credentials and data stay on servers you control, the decision is already made and the rest of this page is background reading.

If none of those constraints applies, the real choice is about who can still change the workflow in two years, which is a question about your team rather than about the software.

What each one is built around

The three are not competing on a single axis, which is why feature grids comparing trigger counts are so unhelpful. Each was designed around a different assumption about who is building and what the logic looks like.

Zapier assumes the builder is not an engineer and the workflow is mostly a straight line. Make assumes the builder will happily think about data structures and wants the entire flow visible on one canvas. n8n assumes the builder is comfortable dropping into code when the visual approach runs out, and that somebody wants the whole thing running on their own server.

Those assumptions show up most clearly in how each behaves when something goes wrong at three in the morning. A linear tool tells you which step failed. A canvas tool lets you attach a handler to the step that failed and route the record somewhere a person will see it. A self-hosted instance gives you the logs, the database and the ability to replay the run, which is more power and more responsibility in the same gesture.

• Zapier: the widest catalogue of ready-made connections, and the shortest distance from an idea to something running today.
• Make: a canvas built for branching, iteration over collections, aggregation back into one record, and error handlers attached to individual steps.
• n8n: self-hostable, with code available wherever the visual nodes run out, and AI agent orchestration handled natively rather than bolted on.
• All three: retries, scheduling, webhooks and a run history you can inspect. The basics are not the differentiator anyone thinks they are.

The four questions that actually decide it

Answer these in order and the platform usually names itself. Skipping the first one is how businesses end up rebuilding a year later.

The maintenance question matters most and gets asked least. An automation nobody inside the business can open and understand is a dependency rather than an asset, and it does not matter how elegant it was on the day it shipped.

• Who maintains it after handover? If that is an operations manager with no engineering background, weight heavily towards the platform they can read.
• Does the logic stay in a straight line? Once there are several paths, a loop over line items and its own error handling, a simple step-based tool becomes hard to read, and hard to read is where automation quietly dies.
• What does the bill do at volume? Hosted platforms count steps or operations, so one business event that fans out into a dozen actions is a dozen units. Comfortable at low volume, a different conversation at high volume.
• Where must the credentials and the data sit? If the answer is on infrastructure you control, self-hosting is the requirement and the shortlist has one name on it.

Where each one wins and what it costs you

Read this by finding the row that describes your situation rather than by comparing every cell. The last row is there because it is a real answer and it is rarely offered.

Option	Strongest case for it	What it costs you
Zapier	Mainstream apps, linear logic, a non-technical maintainer	Branching gets awkward fast, and per-task counting punishes fan-out
Make	Branching flows, lists of records, one visual picture of everything	A steeper first week, and a team unwilling to think in data structures will struggle
n8n, self-hosted	Data and credentials under your control, code where you need it, predictable running cost	You now own a server, its updates, its backups and its certificates
n8n, hosted for you	The same workflow model without the server administration	You give up the residency argument that made self-hosting attractive
None of them	The feature already exists inside your CRM or helpdesk	Less flexibility later, which is often a fair trade for one fewer system

Where none of the three belongs

Some requirements sit outside what any workflow platform does well, and arguing about which of the three to use is the wrong argument to be having.

Heavy data processing is the clearest case. Moving large files or transforming very many records is faster and cheaper written as code and run on a schedule. So is anything that has to answer in a fraction of a second, because that is an application concern rather than a workflow one. Review and rollback discipline is another: none of the three gives you what a proper codebase gives you, and complicated logic eventually wants it.

There is also the case where you should not buy an automation platform at all. If the process runs a handful of times a month, or your CRM already has a rule engine that does the job, adding a fourth system to the estate makes the business harder to run rather than easier. Count the repetitions honestly before you count the connectors.

The order to decide in

Start with the constraint, not the preference. Four checks settle the choice between n8n, Zapier and Make, and an earlier answer overrules a later one.

1. Where must the data and the credentials sit? If they have to stay under your control, self-host n8n and stop here.
2. Who maintains it after handover? A non-technical owner points to Zapier, a builder willing to learn a canvas points to Make.
3. What shape is the logic? Branching and lists will push you off Zapier eventually, whatever your team looks like.
4. What is the volume? This is the last check and the one that most often forces a rebuild, so estimate it for two years rather than for next month.

One more habit is worth adopting whichever you choose. Keep the accounts in your own name, export the workflow definitions somewhere you control, and write a paragraph explaining what each one does and who to call when it stops. Platforms are replaceable. Undocumented workflows are not.

The fifth question, and what the self-hosted answer really costs

There is a fifth question the four above do not cover, and it does not depend on which platform wins: what happens when a step fails. All three will retry, and all three will happily retry all night. Decide instead that a step failing twice halts and hands it to a person with the state at the moment it failed, and that money, pricing, anything published in your name and any serious complaint wait for human approval. That rule is portable across all three, which is more than can be said for the workflows themselves.

The first question is about credentials and it is really the ownership question wearing different clothes. Self-hosted n8n means the instance, the credentials and the execution history sit on infrastructure you control, and the workflow definitions are files you can read, version and hand to somebody else. On the hosted platforms you own the account and the logic inside somebody's product. Both are legitimate. It is worth knowing which one you chose before the fourth question rather than after the rebuild.

The last row of the comparison exists because a non-technical person maintaining a workflow in-house is a real answer and often a good one. Where that person exists, the platform question is already settled and a supplier adds cost rather than capability. Where they do not, the published version of the other end is Quillon, whose delivery line runs as a single audited automation of 34 AI nodes. Ibrahim owns build and workflows at Wobble, which works from Karachi, bills month to month and carries 25 engagements across six countries.

Common questions

Can n8n really be self-hosted, and does that matter?

Yes, and it matters whenever somebody has asked in writing where your data and credentials live. Self-hosting puts the workflows, the stored credentials and the execution history on infrastructure you control. It also makes you responsible for updates, backups and certificates, which is a genuine operational cost rather than a footnote.

Which is cheapest at high volume?

Hosted platforms charge by tasks or operations, so cost tracks how many steps run rather than how much value the workflow creates. A self-hosted instance moves most of that to fixed infrastructure cost. Model your own fan-out first: count how many actions one business event triggers, then multiply by your monthly event count.

Is Make better than Zapier?

For branching logic and for anything that processes a list of records inside one run, Make is built for the job and Zapier is not. For a straight-line connection between two mainstream applications, maintained by somebody non-technical, Zapier is easier to live with. Neither is generally better.

Can I mix platforms?

You can, and plenty of businesses do, but treat it as a decision rather than an accident. Two platforms means two bills, two places to look when something breaks and two sets of credentials to manage. A defensible split is one platform for the operational core and another only where a connector exists nowhere else.

How hard is it to move workflows between them?

There is no reliable automatic path. Moving means rebuilding, testing and re-authorising every connection, and the effort scales with the number of workflows rather than their complexity. That is the strongest argument for answering the hosting and volume questions before you build the first one.

Do I need an automation platform at all?

Not always. If your CRM or helpdesk already has a rules engine that covers the job, use it. Platforms earn their place when a process crosses several systems, runs often enough to matter, and needs logic that no single application can express on its own.