n8n vs Make: How Each One Counts a Run, and What That Costs

In n8n vs Make, the deciding question is how many records one run touches. Pick Make when the builders do not write code, the workflows run in a straight line, and nobody wants to look after a server; a scenario with a trigger and five actions costs six credits per run and the Core plan buys 10,000 credits for $10.59 a month. Pick n8n when a run loops over lists, when you need code steps or AI agents without per-step metering, or when the data has to stay on your own servers, which Make cannot do and only a few n8n alternatives can. If you are unsure, price your busiest workflow on both before choosing, with the counting rules below.

All prices in this article come from n8n.io/pricing and make.com/en/pricing, read on 2026-10-07. n8n prices in euros and Make in dollars; neither figure below is converted.

Pricing pages read 2026-10-07. The Atlas cards for n8n and Make carry the pricing history.

How does each one count usage?

This is the whole comparison, and most of what follows is a consequence of it.

n8n's pricing page says it plainly: an execution is a single run of the entire workflow, and the number of steps and the amount of data do not change that. A workflow with forty nodes that processes five hundred rows is one execution.

Make counts operations and bills one credit per operation by default. Its help centre defines an operation as one module run to process or check data, and a module runs once for each bundle it receives. A trigger is the exception: it runs once per check, however many bundles it returns. So a scenario whose trigger returns ten form responses and then runs three modules on each uses 1 + 30 = 31 operations for that run. That example is Make's own, and it is the multiplication to watch for.

Three things in Make do not follow the one-credit rule. Routers and error handlers are free. The Make Code app costs 2 credits per second of execution time. Modules that use Make's own AI Provider are billed on tokens as well as operations, so their credit use varies run to run.

Which is cheaper at low volume, and which at high volume?

Two workflows, priced from the published terms.

Workflow A: a lead form, five actions per lead. A webhook receives the lead, then five modules run once each: look up the contact in the CRM, create or update it, post to Slack, append a row to a sheet, send a confirmation email. In Make that is 1 trigger operation plus 5 actions = 6 credits per lead. In n8n it is 1 execution per lead.

• 1,000 leads a month. Make: 6,000 credits, inside Core's 10,000, so $10.59 a month billed monthly. n8n: 1,000 executions, inside Starter's 2,500, so €24 a month billed monthly. Make is cheaper.
• 20,000 leads a month. Make: 120,000 credits. The 80,000 tier is too small, so the next is 150,000 credits: Core at $116.47 a month billed monthly ($99 billed annually). n8n: 20,000 executions is above Pro's 10,000 tier; the pricing page's Pro plan data lists a 50,000-execution option at €145 a month billed monthly. Close, with Make slightly ahead before currency.

For short linear workflows, per-step billing does not punish you much. Six credits a run is cheap.

Workflow B: an hourly sync, 100 records per run. A schedule fires every hour, the trigger module fetches up to 100 changed records, and three modules run on each record (transform, update the target system, log the change). In Make each run is 1 + (100 × 3) = 301 credits. A month of hourly runs is 720 runs, so 720 × 301 = 216,720 credits. That needs the 300,000-credit tier: Core at $214.31 a month billed monthly ($182.16 billed annually). In n8n it is 720 executions, which fits inside Starter's 2,500 at €24 a month.

Where the arithmetic is uncertain. Make's help centre says a trigger that only checks for data still runs once per check, so a scenario polling every minute spends credits even when nothing arrives; an instant (webhook) trigger runs once per arriving request, which is how Workflow A counts it. Your own scenario's run history shows operations and credits per module, so confirm there. On n8n, the 50,000-execution Pro price comes from the pricing page's plan data rather than a printed table row. Run your real workflow on each trial and read the counters before trusting any estimate, including this one. If you are deciding what to automate before choosing a tool, what to automate first in a small company is the earlier question.

Is n8n really free if you self-host it?

The licence fee is zero. n8n's documentation recommends the self-hosted Community edition to anyone who wants to run n8n for free, with almost the complete feature set. The cost moves elsewhere: a server, a database, backups that are actually restored now and then, and someone who applies updates and answers when the instance stops at night.

Two limits are worth knowing before you commit. The Sustainable Use License allows use for your own internal business purposes or non-commercial use; selling access to a hosted n8n is outside it. And team features on a self-hosted instance (SSO, multiple environments, Git version control, queue mode) sit in the Business plan, which is self-hosted only and costs €667 a month billed annually or €800 billed monthly for 40,000 executions. A Business licence key pings n8n's licence server daily with production execution counts, so self-hosting with a paid plan is still metered.

The honest version: self-hosting is free for a team that already runs servers. For a team that does not, the server is the small part of the cost, and the hours are the large one. That is the same trade described in in-house developer vs agency for automation, applied to infrastructure.

Which one suits visual building, and which suits code?

Make is the more visual of the two. Its scenario canvas, routers, filters and data mapping are built for someone who thinks in boxes and arrows, and its free plan is enough to learn the tool. Custom JavaScript or Python runs through the Make Code app at 2 credits per second, and custom functions are an Enterprise feature. Code is possible on Make, and it is priced per second, so it stays occasional. Against Zapier's step list it is also the harder editor to learn, as make vs zapier explains.

Make.com used to drive me bonkers when it took 10+ minutes to create all the nodes in the UI to handle loops, errors, etc. when I could normally just write a few lines of code to handle it.

• simple10, Hacker News, 3 May 2025 (link)

n8n is visual too, but it assumes someone on the team is comfortable with JSON and expressions, the same test that decides n8n vs Zapier. Its pricing page lists JavaScript and Python code steps, custom HTTP and GraphQL requests, cURL import and webhook triggers on every plan, with bash scripts and custom nodes available when self-hosted. Code steps cost nothing extra per run, which is why n8n workflows tend to carry more logic per node.

If the person who will own the workflow after it ships cannot read a code step, the code-friendliness of n8n becomes a liability: the workflow works until it breaks and then nobody can open it. That ownership question matters more than the editor, and it belongs in the contract before the tool is chosen: how to read an automation quote lists handover and ownership among the lines a quote should name.

Where does the data live, and can it stay in the EU?

n8n Cloud stores data in the EU, on servers in Frankfurt, according to its pricing page. Self-hosted n8n stores data wherever you put it, which is the only arrangement of the two where the automation platform itself never leaves your infrastructure.

Make lists its hosting as AWS in the EU or North America on all plans, operated by Make. There is no self-hosted Make. The Enterprise plan adds an on-prem agent so scenarios can reach systems inside your network, such as SAP, but the scenarios still run in Make's cloud.

For most small companies either cloud region is acceptable. For a company whose contracts require processing on its own servers, the choice is already made. Check the region claim against your own data processing agreement, since a pricing page does not list sub-processors, and every AI step sends data to a model provider as well.

How do they compare for AI agents?

Both platforms now treat agents as a main feature, and both list them on every plan.

n8n's pricing page lists an AI Agent node and AI steps, MCP server and client nodes, human approval for tool calls, hosted and embedded chat, and evaluations; agents are marked as a preview. On cloud plans you can use models from OpenAI, Anthropic, Google and others without your own key through prepaid gateway credits, or bring your own keys. The Assistant that helps build workflows comes with 1,600 credits a month on Starter and up to 9,600 on Pro; self-hosted, you bring your own key and no credit limit applies.

Make lists Maia (building scenarios and agents by conversation), Make AI Agents in beta, an MCP server, and over 350 AI apps on all plans. With Make's own AI Provider, credits are based on tokens and operations; with your own OpenAI or Anthropic connection on a paid plan, credits follow operations and you pay the provider for tokens. An agent that calls several tools per conversation spends credits per call, so agent-heavy work inherits the same multiplication as loops.

Whichever you choose, the expensive part of an agent is rarely the platform. It is deciding where a person reviews the output before it reaches a customer; keeping a human in the loop covers where those checkpoints go.

Who maintains it once it runs?

On Make, Make maintains the platform. You maintain the scenarios, and the main ongoing work is watching credit use and fixing scenarios when a connected app changes its fields or API. Execution logs are kept 30 days on paid plans and 7 on Free.

On n8n Cloud, the split is the same: n8n runs the platform, you run the workflows. Saved execution history is kept 7 days on Starter and 30 on Pro, and Starter caps a single run at 5 minutes.

On self-hosted n8n, you maintain everything: the version, the database, the backups, the credentials store and the uptime. A self-hosted instance that is not updated drifts away from the nodes that talk to other apps. Apps change underneath both platforms, and when the integration changes underneath you, somebody has to notice. On self-hosted n8n, that somebody is also responsible for the server.

How should you choose?

Write down the workflow you expect to be busiest and answer three questions.