n8n or Make: which to choose for automating your processes in 2026?

The classic mistake is to compare the monthly subscriptions on display. That is not where the bill is decided.

Make bills per operation. An operation is the execution of a module, not of a scenario. A scenario containing eight modules and running 1,000 times a month consumes 8,000 operations, not 1,000. Add an iterator processing fifty rows and you multiply again. It is mechanical, and it is what comes as a surprise in the third month.

n8n bills differently. In the cloud, billing is per workflow execution, whatever the number of nodes inside. Self-hosted, you only pay for the server: the cost becomes fixed, and it only moves if you run short of resources.

The consequence is simple. At low volumes, Make costs less than a server. Past a certain volume, Make's curve crosses n8n's fixed cost, then moves away from it. The work to do before choosing comes down to three questions: how many modules per scenario, how many triggers per month, and will those volumes grow with the business. Multiply, compare with the cost of a server and of administration time. You have your answer, in figures, in twenty minutes.

It is n8n's headline argument, and it is also the one that is sold worst. Self-hosting is not free, it is moved.

You no longer pay a subscription, but you take on the server, which has to grow with your volumes. The updates, because n8n publishes often and an instance left un-updated becomes a security risk. The backups, because your workflows and their connection credentials are a database. And the monitoring, because a scenario failing silently for three days costs more than the subscription saved.

It is perfectly manageable, and it is exactly the kind of thing we set up and then document so that you stay self-sufficient. But it has to be decided knowingly, not because it is open source and therefore free. Conversely, if nobody at your end wants to hear about a server, Make is the right choice and the debate is closed.

If your automations handle health data, legal data, accounting records or sensitive personal data, the question of where processing happens comes before cost.

With n8n self-hosted on a server in France, the data does not leave your infrastructure. With a SaaS, it passes through the publisher's infrastructure. That is not disqualifying in itself, serious publishers are compliant, but it is a point your data protection officer or your own client may raise. In regulated sectors, this criterion decides before all the others.

This criterion has the particularity of making the others secondary. When it applies, it decides on its own, and no gain in convenience will offset it.

It applies in three situations we meet regularly: health data, data subject to a contractual commitment on location, or a flow carrying information a client entrusted to you without knowing it would pass through a third party.

In those cases the question is no longer the convenience of the tool but where the data passes and where it settles, even temporarily. A hosted platform keeps execution logs containing the content of the messages processed, and it is that detail, rarely read, that causes the problem.

If none of those three situations applies to you, this criterion should not weigh on the decision. Invoking it on principle leads to self-hosting without needing to, and to paying for maintenance that serves no purpose.

An automation flow never breaks while you are watching it. It breaks on a Friday evening, on a case nobody planned for.

Make offers error handling per scenario, with dedicated routes and retry attempts. It is sound and readable. n8n allows the same, with the added possibility of writing the retry logic in JavaScript and plugging in your own monitoring. You go further, in exchange for more setup work.

In both cases the rule is the same: a scenario in production with no alert on failure is not finished. It is the first reflex we put in place.

The point to settle before building is not raw capacity, which both reach, it is what happens when an execution fails.

A silent automation that falls over on a Friday evening produces incomplete data all weekend, and nobody finds out before the client points it out. It is the most expensive scenario, and it has nothing to do with volume.

Our requirement on this kind of project: any automation touching a client or an invoice must raise an alert visible to a human, not just a line in a log nobody opens. And any step that writes into a system must be replayable without creating a duplicate.

Those two rules are set at the design stage. Adding them afterwards means going back through every scenario one by one.

It is the most frequent risk on these projects, and it appears in no feature comparison.

An automation is software written by somebody. If that person leaves, what remains is a sequence of steps with no comment, whose intent has to be guessed. So the question is not only which tool, but who will open that scenario in a year and whether they will understand what they are looking at.

Self-hosting adds a layer to that dependence: on top of the scenario there is the server, its updates and its backups. An automation running on a machine nobody knows how to administer any more is a debt, even if it works.

Our rule on deliverables: every scenario carries an explicit name, a description of what it does and what happens if it fails, the list of systems it touches, and for self-hosting, the restore procedure. Ten minutes at build time, and the difference between an automation that survives a departure and one that dies with it.

You are starting out, your team is not technical, your volumes are moderate: Make. You will be operational faster, and the cost stays under control as long as volumes do not run away. You can migrate later, the concepts carry over.

Your volumes are climbing, or your automation bill is becoming a visible line in the budget: n8n. The calculation is done over twelve months, server and administration time included.

You handle sensitive or regulated data: n8n self-hosted, and the cost question comes second.

You want to bring it in-house gradually: n8n. Workflows export as JSON, can be versioned, and your team builds skill on a tool you keep control of.

A very small company starting out, with a few flows between common tools and nobody technical in-house: the hosted platform. Getting going is immediate, and at that volume the cost question does not arise yet.

A mid-sized company scaling up, whose scenarios process lists and fire hundreds of times a day: that is the moment when the billing mechanics become the project's largest line, and when self-hosting deserves to be costed seriously rather than dismissed by reflex.

A team bringing it in-house, with somebody able to maintain a server and the intention of covering complete business processes: self-hosting becomes worthwhile, provided maintenance is a budget line you accept and not a hope.

If data sovereignty applies to your case, it decides before all these criteria, and the discussion stops there.