n8n’s Pro plan and Make’s Core plan will both sell you a “10,000” on the label. On n8n, that is 10,000 runs of your scenario, at any number of steps. On Make, for an 11-module scenario, it is about 900 runs before the month is over.
Short version: if your scenarios are short and your team is non-technical, Make is the cheaper and faster place to start. If your workflows run long, or at real volume, n8n’s flat meter wins as the workflow grows, and the gap compounds every month you keep running.
That answer is not a preference. It falls out of one structural difference in how the two platforms bill, and almost every other tradeoff in the n8n vs Make decision is downstream of it.
We run over 200 n8n workflows in production and 89 AI agents live. We also build on Make for clients who are right for it. This is what we have learned choosing between them on real budgets.
What is the actual difference between n8n and Make?
n8n charges per workflow execution. One run of an entire workflow counts as one execution no matter how many steps it contains, and n8n says so explicitly in its own definition: it does not matter how many steps are in the workflow or how much data it processes. In one sentence: n8n bills the run, not the work inside it.
Make charges per module action. In Make’s own list of what consumes a credit, that covers reading data from an app or webhook, searching, creating, updating, deleting, transforming, aggregating, and iterating, one credit each. Routers and error handler modules are free, which is a sensible piece of design. Everything else on the canvas has a meter on it, and most billable modules bill per bundle of data they process rather than per module, so one that handles ten records costs ten credits, not one. (Make renamed operations to credits in 2025. Same unit, new label, and it is why older comparison articles read as if they are describing a different product.) In one sentence: Make bills the work, not the run.
Hold those two sentences next to each other and the whole comparison resolves.
What does each one actually cost at real volume?
Take a scenario that is boring and typical: a form comes in, you enrich the record, check it against a CRM, branch on the result, write to two systems, and send a notification. Call it 12 modules, one of which is the router doing the branching. The router is free, so 11 of them are billable. It runs 3,000 times a month, one record at a time.
On n8n, that is 3,000 executions. Starter’s 2,500 executions a month will not cover it, so the plan that fits is Pro: 10,000 executions at EUR 50 a month billed annually (prices as published August 2026). You are using less than a third of the plan.
On Make, that is 33,000 credits. There is no tier at exactly that number: the next one up is 40,000 credits at $29 a month on Core’s annual pricing. At the August 2026 exchange rate, 50 EUR is roughly $55, so at this volume Make, at $29, is plainly the cheaper platform. A reader who stops at the plan-price table and picks Make because “Core starts at $9” gets the right answer here, for the wrong reason: the entry price is not what is being paid at 3,000 runs a month, the 40,000-credit tier is.
The same scenario, priced at four volumes:
| Monthly volume for an 11-module scenario | Make Core (annual billing) | n8n Cloud (annual billing) |
|---|---|---|
| up to 900 runs (10,000 credits) | $9 | 20 EUR (Starter, to 2,500 runs) |
| 3,000 runs (33,000 credits) | $29 (40,000-credit tier) | 50 EUR (Pro, to 10,000 runs) |
| 3,637 to 7,272 runs (40k to 80k credits) | $55 (80,000-credit tier) | 50 EUR (Pro) |
| 7,273 to 10,000 runs (80k to 110k credits) | $99 (150,000-credit tier) | 50 EUR (Pro) |
Run your own numbers in the cost comparator: enter your step count and monthly runs and it prices all three platforms from the same table above.
That is also where most comparisons stop, and it is why they get the recommendation backwards for anyone running more volume than this example. The two meters do not grow at the same rate, so a conclusion true at one volume stops being true at the next.
Run the arithmetic forward from here. n8n Pro is flat at 50 EUR for up to 10,000 runs a month, at any number of steps. Make’s cost moves with steps times runs, and the table above shows where the two lines cross: past roughly 40,000 credits a month the two platforms are about level on cost, and past 80,000 the gap opens in n8n’s favor. Change the step count and the crossover moves with it, because n8n has a cliff of its own. Pro stops at 10,000 executions a month, and the next tier up, Business, is 667 EUR for 40,000. A three-module scenario running 20,000 times a month is 60,000 credits on Make, which is the $55 tier, and 20,000 executions on n8n, which is the 667 EUR tier. Short scenarios at high run counts are the one shape where Make stays dramatically cheaper on cloud pricing, and self-hosting is the only thing that removes that cliff.
The 33,000-credit example is also the charitable version, because it assumes every module handles exactly one record per run. Feed a module a batch of 20 and it bills 20 credits, not one. Scenarios that fan out over lists are where Make bills surprise people.
Make’s meter runs on complexity. n8n’s does not. That holds at every volume, and it cuts both ways: at low step counts and moderate volume, Make’s meter is the cheaper one to be on, exactly as the math above shows. It stops being the cheaper one once either the step count or the volume climbs far enough, and the crossover point is arithmetic, not opinion.
The practical consequence is that on Make, every billable module you add to a scenario raises its running cost forever, and that pressure changes how people design.
Some of that pressure is useful. Processing a thousand webhooks as a thousand separate runs and handling the same thousand records in one batched run are genuinely different architectures, with different failure behavior and different load on the systems downstream, and the batched version is often the better build regardless of price. That is a logic decision, not a cost decision, and it should be made on whether the business needs records handled individually or in bulk.
The trap is the version where the invoice makes the decision. Restructuring a working scenario to shave modules, when the current shape is the one the business actually needs, is optimization that buys nothing. There is no point making a system prettier if the change does not serve a business goal. A meter that rewards fewer steps quietly pushes teams toward that second kind of rework, and it takes discipline to notice which kind you are doing.
When is Make the right choice?
Plenty of the time, and we say that as an n8n shop.
Make wins when the people maintaining the automation are not engineers. The visual builder is genuinely better at showing you what a scenario does at a glance, the module library is enormous and the connectors are polished, and a marketing ops person can open a scenario six months later and understand it. That is worth real money. An automation nobody on the team can read is a dependency, not an asset.
Make also wins on short scenarios at low volume. Three modules firing 500 times a month costs 1,500 credits. It fits inside a cheap plan, there is nothing to host, nothing to update, and no server to be responsible for at 2am.
And Make wins when there is no technical owner at all. Self-hosted n8n is software you run. Somebody has to patch it, back it up, and notice when it stops. If that person does not exist and you are not paying for n8n’s cloud, the honest recommendation is Make. We build on it for clients who fit that description, and we say so on our Make integration page, which also covers the point at which volume makes moving worth the disruption.
When is n8n the right choice?
n8n wins on long workflows, high volume, custom code, and anything with an AI model in the middle of it.
The step-count independence is the headline, but the code node is what actually changes what you can build. Real business logic tends to be ugly: date math that respects the client’s fiscal calendar, a matching rule with four exceptions, a retry rule that treats a rate limit differently from a server crash. In a pure visual builder those get expressed as long chains of filter and router modules, which is both harder to read and, on Make, directly more expensive. In n8n you write eight lines of JavaScript and move on.
The AI side is where the gap has widened most in the last year. n8n’s agent and tool-calling nodes let you build a workflow where a model decides which tools to call, rather than one where you hard-code the branch logic yourself. Make has AI modules, but they are modules in a scenario you designed, which is a different shape of system. The distinction matters more than it sounds: one adapts to inputs you did not anticipate, the other does exactly what the diagram says.
Self-hosting is the other lever. Running n8n on your own server means the execution meter disappears entirely: your cost is the box, plus the person who looks after it, and a box does not care how many times a workflow ran last night. Put a number on both sides before deciding: a small virtual server typically runs on the order of 10 to 20 dollars a month, and the real line item is however many hours a month of someone’s time it takes to patch it, watch it, and fix it when it breaks, at your own hourly rate. For a team at high volume that is still the difference between a bill that grows with the business and one that does not. It also means your data never leaves your infrastructure, which decides the question outright in healthcare and financial services.
This is the build we run most often for clients past the volume where Make’s meter stops making sense. If that is where you are, our n8n development work covers what we build and how we scope it.
Can you use self-hosted n8n commercially for free?
Mostly yes, and the exact boundary matters enough to state plainly, because it is the most common piece of misinformation in this comparison.
n8n is fair-code under the Sustainable Use License, not open source. You may use and modify it free for your own internal business purposes. A solo operator, an agency, and a Fortune 500 can all self-host it to run their own operations at no license cost. n8n’s published licensing guidance also treats commercial consulting and workflow-building for clients as permitted without a separate agreement, which is what makes an agency model like ours viable.
What you cannot do is build a business around n8n itself: reselling it, offering it as a hosted service to your customers, or using it to build a competing automation platform. The line is whether n8n is running your business or being sold as your product.
Make has no equivalent question. It is SaaS, you rent it, that is the whole model. If license ambiguity is something you do not want to think about, that simplicity has value.
Which one breaks less in production?
Neither platform fails often. What differs is what happens on the day one does.
Make gives you scenario-level error handlers and its own execution history, and error handler routes do not consume credits, which is a genuinely sensible design choice. For a scenario a human checks weekly, that is enough.
n8n gives you more surface to build real monitoring on, because you can reach outside the tool. Failed executions can trigger another workflow that writes to your incident channel, opens a ticket, and retries on a spacing schedule. You can keep versioned copies of every workflow the way developers keep code and run separate dev and production instances. On self-hosted, you own the logs.
What actually determines uptime, though, is not the platform. It is whether anyone gets told when a workflow stops. The most expensive automation failures we get called into are not crashes. They are workflows that quietly stopped firing weeks earlier while everyone assumed the data was still flowing. That failure mode is available on both platforms, and we wrote about why automations break silently because it is the single most common reason a working system stops being one.
How should you choose between them?
The rule we apply, in order:
Count the billable modules in your typical scenario and multiply by monthly runs, then do the same count as executions for n8n, which is just the monthly runs. Compare each against what the two plans actually include: n8n Pro covers 10,000 executions, Make’s paid tiers start at 10,000 credits. Whichever meter you blow through first is the platform that is about to get expensive. For anything past a handful of modules that is Make. For a very short scenario at high volume it is n8n, whose Pro tier stops at 10,000 executions.
Ask who maintains this in a year. If the answer is a non-technical operations person and there is no engineering support, weight Make heavily regardless of the math.
Check whether the logic needs code. Custom data mapping, non-trivial branching, or an AI model making decisions instead of following a script all point to n8n.
Check where the data has to live. Regulated data on your own infrastructure means self-hosted n8n, and that ends the discussion.
Ask what happens when volume triples. This is the one teams skip. Make’s bill scales with steps and runs together, so a 3x in volume on a complex scenario is not a 3x in cost from where you thought you were standing.
Most of the migrations we run are teams who chose correctly for the business they were, and are now the business they became. There is nothing wrong with starting on Make and moving later, as long as you build in a way that makes moving possible: keep credentials centralized, keep business logic out of the visual layer where you can, and document what each scenario is for. If you are already at that point, migrating off Zapier to n8n covers the same mechanics, and the sequencing is what keeps production intact during the cutover.
The wrong version of this decision is picking the tool first and discovering the cost model at month nine. Count your steps before you commit.
Prices and platform terms verified against n8n and Make published documentation, August 2026. Both vendors change pricing; check current figures before budgeting.