n8n vs Make: charged for every step you take
Industry & Strategy · By Caleb Sakala · June 20, 2026
Most n8n vs Make comparisons spend two thousand words on the wrong variable. They count integrations, screenshot the drag-and-drop canvas, and hand out points for "ease of use." None of that tells you which platform you will resent in six months. The thing that does is almost never given a section of its own: how each one counts what you owe.
How each one runs the meter
Make charges per operation. Every module that fires inside a scenario costs one operation, and that includes the trigger, and it includes a filter step that burns an operation even when it stops the run before anything happens. A scenario with twelve modules that runs 2,000 times in a month spends 24,000 operations. Make's Core plan, around $9 a month billed annually, includes 10,000 (Make pricing, 2026). So that one workflow already pushes you past the entry tier on its own.
n8n counts differently. One full workflow run is one execution, and the number of nodes inside it does not matter. The same twelve-node workflow running 2,000 times spends 2,000 executions. On the self-hosted Community Edition it spends nothing measurable, because there is no execution cap at all (n8n pricing, 2026).
That single accounting choice decides more about your bill than any feature on the comparison pages.
n8n vs Make on a real workload
Run the numbers on a workflow you might actually ship: twelve steps, triggered 2,000 times a month.
Workflow: 12 steps, 2,000 runs / month
MAKE (per operation) n8n (per execution)
Billable units used 24,000 operations 2,000 executions
Fits entry paid tier? No (Core = 10,000) Yes (Starter = 2,500)
Self-hosted option None, cloud only Free, no execution cap
Bill grows with steps x runs runs onlyMake's Core sits near $9 a month for 10,000 operations; n8n's Starter is about €24 a month for 2,500 executions (Make, n8n). At low step counts and low frequency, Make is often the cheaper and simpler choice, and the self-hosting conversation is a distraction you can ignore. The arithmetic only turns against it as your workflows get bigger and busier.
Add an AI step and the gap widens
AI-heavy automations have more steps. A typical one fetches data, calls a model, validates the output, routes on the result, then posts somewhere. Five operations on Make, every single run. On n8n the whole thing is still one execution. The cost curves pull apart precisely as your automations get more capable, which is the opposite of the direction you want.
This is not a theoretical complaint. A reader summarizing the tradeoff on r/automation noted that Make's credit-based billing "can scale up your monthly costs quickly" on complex or high-frequency flows, a point echoed in Google's own AI overview for the comparison (r/automation discussion). Short scenarios that run rarely never feel any of this. Heavy, constant workflows are where it becomes the first number you should model.
The axis nobody puts in the comparison
Pricing is the visible difference. The harder one to see is where the authority to act actually lives inside a workflow.
When an automation can move money, delete records, or message a customer, the real question is which step is permitted to pull that trigger. On a plain canvas, any node holding credentials can act. A routing mistake three modules upstream can still reach the module that spends the money, because nothing structurally stops it.
A procurement flow makes the stakes concrete. Picture a research step that returns a purchase_recommendation object and a separate orchestration step that is the only thing holding the credentials to place an order. A bad recommendation cannot spend a cent on its own, because the authority to buy never sat with the step that did the reasoning. That action-type routing is how Chase Agents keeps the permission boundary at the workflow level rather than trusting every node that happens to carry a key. Neither n8n nor Make builds that separation for you. You design it by hand, or you ship without it.
Both still make you build it
Both platforms hand you an empty canvas and assume you already know the shape of the workflow. You place the nodes and wire the data paths yourself, then guess the schema for whatever flows between them. The AI assistance in each is mostly node suggestions and field mapping, not construction of the automation itself.
The competing pitch from AI-assisted builders is that you describe the outcome and the platform drafts the steps, the input schema, and the success checks for you to refine (the approach Chase Agents takes, where stating intent returns a multi-step automation instead of a blank grid). Whether that actually saves time depends on how standard your process is. For a bespoke internal workflow with quirks only your team knows, hand-wiring it in n8n is frequently faster than correcting a generated first draft.
Choosing between n8n and Make
Reach for Make when your team is non-technical, your scenarios are short, and you would rather never see a server. The visual builder is genuinely friendlier, the 3,000-plus app library covers most off-the-shelf needs, and per-operation billing stays cheap while your operation counts stay low.
Reach for n8n when you run high-frequency or many-step workflows, when self-hosting to flatten the bill is worth the maintenance, or when you need real code in the middle of a run. The interface is steeper and you will meet JSON sooner than you would like, but the execution-based meter rewards exactly the heavy, branching automations that punish you on Make.
Here is the test to run before you commit. Take your single most important workflow, count its steps, and multiply by how often it will run at the volume you expect a year out, not the volume you have today. Drop that number onto Make's operation tiers and n8n's execution tiers. If the two answers land close together, pick whichever canvas your team likes and stop agonizing. A wide gap settles the choice for you, and it was never about which buttons looked nicer.