n8n vs Make: the billing unit decides everything

The one difference that decides the bill

Both platforms sell monthly quotas. They do not count the same unit, and that is where everything is decided.

At n8n, the pricing documentation is explicit: "An execution is a single run of your entire workflow. It doesn't matter how many steps are in the workflow or how much data it processes, it's still a single execution." A three-step flow and a forty-step flow consume the same.

At Make, the unit is the operation: "Each module action in your scenario, like adding a Google Sheet row or fetching Gmail account data, counts as one credit." Every block traversed counts.

The gap is therefore not a percentage, it is a factor, and that factor is exactly how many steps your flows have.

This table does not say n8n is cheaper, it says the comparison is meaningless until you have counted your steps. On short, infrequent flows the question does not arise. On long ones, it decides alone.

Both grids, checked on 3 August 2026

Prices published by the vendors. n8n quotes in euros with annual billing, Make in dollars per month. They change often, hence the date.

Two honest notes on these figures. The Make tiers shown are for 10,000 credits and the amount then follows the volume purchased: beyond that the vendor publishes no readable grid, so no figure is quoted here rather than estimated. And annual commitment saves "15% or more" without the annual prices being detailed.

The minimum interval on Make's free tier deserves reading before building on it: fifteen minutes between triggers, which rules out anything that has to react quickly. Getting down to the minute is the real reason to leave the free tier, ahead of the credit count.

On the n8n side, the step from Pro at €50 to Business at €667 is steep, and what it buys is mostly enterprise control: single sign-on, Git, separate environments. If none of those three words concerns you, the step is justified only by execution volume.

The n8n licence is not what you think

n8n is very often presented as the open-source alternative to Make. The repository says otherwise: "n8n is fair-code distributed under the Sustainable Use License and n8n Enterprise License". Source available, self-hostable, extensible, and not Open Source Initiative approved.

For an SME self-hosting n8n for its own flows, the distinction changes nothing in practice. It becomes central in one case only: reselling n8n hosting to clients, which is precisely the kind of use the fair-code model restricts. If that is your plan, settle it with the vendor before the first invoice, not after.

Make raises no such question since it is an avowed online service with no self-hosted edition. So the choice also turns on this: n8n leaves you the option of bringing everything back in house, Make does not offer it.

What actually decides, once prices are set aside

Three things weigh more than the price gap over the life of an automation.

• How many exceptions your process has. A chain working for 90% of cases and breaking on the remaining 10% costs more in repairs than in subscription. That is the real cost driver, and neither platform changes it.
• The quality of the input data. A badly filled form produces an automation writing nonsense faster than a human would. That is settled upstream of the tool choice.
• Who repairs it in six months. An automation with no named owner degrades quietly. It is the question tool comparisons never ask and the one that decides the value after a year.

On those three points, n8n and Make are equivalent. What separates them is the billing unit, the option to self-host, and the fact that n8n asks for more technical skill to be operated properly.

When neither one

Both platforms live on the same promise: connecting tools without writing code. Three situations fall outside it, and forcing them costs more than admitting it.

When the business logic runs past thirty-odd modules, the scenario becomes harder to read and fix than a two-hundred-line script, and the operating cost flips. When volume runs well past the top tiers, the subscription ends up above the cost of a service you host. And when the processing has to decide rather than execute, you need an agent and not a flow: a predictable chain does the job perfectly well without a model, and adding one adds risk without gain.

Moving to a custom build is not a judgement on no-code tools, it is a threshold. Spotting it early saves building twice.