Make vs n8n: Credits, Executions, and Who Runs the Server

Make and n8n look like the same product. Both give you a visual canvas, both handle branching and error paths well, and both attract people who found Zapier too rigid. The difference that matters is metering: Make counts every module run against every item of data, while n8n counts one execution per workflow run no matter what happens inside it.

At low volume the two feel equivalent. At high volume they diverge sharply, and in a direction most people don't anticipate — because Make's cost scales with data, not with workflow complexity.

The short version:

• Make — cloud only, credit-based billing, polished canvas, no infrastructure to run
• n8n — cloud or self-hosted, per-execution billing, source-available licence, more technical
• Volume is the deciding variable. Processing thousands of records per run pushes hard toward n8n
• Ownership is the other one. No server owner on the team pushes toward Make or n8n Cloud

Quick comparison

The metering difference, worked through

Make's terminology changed here, and it's worth being precise. Per Make's credits documentation, credits replaced operations as the billing unit, while operations still describe the underlying activity. For non-AI apps 1 operation equals 1 credit at a constant rate, and Make's pricing page frames it as each module action counting as one credit.

The part that catches people is bundles. Data moves through a Make scenario in bundles, and each bundle causes its own module run. A trigger returning 20 records through a five-module scenario is not 5 credits — it's about 100.

n8n's pricing page states the opposite arrangement: an execution is one run of the entire workflow, and it doesn't matter how many steps it has or how much data flows through it. Twenty records through a five-node workflow is one execution. Two thousand records through a fifty-node workflow is also one execution.

Two rules of thumb fall out:

On Make, optimise the data. Aggregator modules collapse many bundles into one, cutting the credit count for everything downstream. This is the single highest-leverage technique on the platform, and scenarios written without it routinely cost several times what they should. Watch AI steps separately: some Make AI features have dynamic credit usage billed on tokens, file size, pages or run time, so their cost doesn't follow the module count at all.

On n8n, optimise the trigger. Complexity is free; frequency is not. A workflow that fires once per record is expensive. The same logic, batched into one nightly run that loops internally, costs one execution.

Migrating between them without re-thinking this is how people end up disappointed in whichever platform they moved to.

Self-hosting: the real dividing line

Make has no self-hosted option. If your data cannot leave your infrastructure — regulated industry, government contract, a security review that won't approve a third-party processor — Make is out and the comparison ends there.

n8n's Community Edition is free to self-host under the Sustainable Use License, with no cap on workflows or executions. The source is public. Worth being precise about what that licence is: it permits internal use and modification, and it forbids offering n8n to third parties as a hosted service. Because it restricts use, it isn't an OSI-approved open source licence, and n8n doesn't call it one. For internal automation this is a distinction without a difference; for an agency planning to resell managed instances it very much is not.

Self-hosting is not free, though — it's a trade of money for labour:

• Someone owns the server, the upgrades, the backups, the TLS certificates
• Scaling past one instance means queue mode and worker processes
• SSO, log streaming, and external secrets sit behind the Enterprise licence regardless of where you run it
• There's no support ticket when a node misbehaves at 2am

If nobody on the team will own that, n8n Cloud is the honest comparison against Make — same execution billing, none of the maintenance burden.

Where Make is genuinely better

Self-hosting dominates the conversation, which obscures the things Make does well.

The canvas is more polished. Make's editor is easier to read at a glance, and its error-handling routes are more discoverable. For a scenario that a non-engineer will inherit, this matters more than people admit.

Onboarding is faster. You build a working scenario in Make in an afternoon. Self-hosted n8n can consume that afternoon before you've automated anything.

Native modules are better-behaved. Make's per-app modules tend to handle pagination and auth refresh for you. n8n's HTTP Request node will talk to anything, but "anything" means you're reading API docs and handling edge cases yourself.

Nothing to run. Not a small thing. Plenty of teams should not be operating a server for this, and choosing to anyway is how automation projects quietly die.

Where n8n is genuinely better

Long workflows. Per-execution billing means depth is free. Fifty nodes cost what three cost.

High data volume. This is where Make's bundle multiplication bites hardest and n8n's model simply doesn't care.

Code. Real JavaScript and Python nodes, and when self-hosted, npm packages. Make's scripting is comparatively constrained.

AI and agent work. n8n's LangChain nodes and local model support make agent-shaped workflows native rather than bolted on. Agent-shaped work is where that difference shows up most clearly.

Control. Your data, your network, your retention policy, your version.

The problem underneath both

Both tools are excellent once you know what you're building. They're less help when the useful thing already exists somewhere and you just can't run it — a Claude Code setup someone posted, an agent that does exactly your job, a workflow shared as a repo you can't get past the install step.

No trigger configures that. The barrier is environment, not integration. That's what Taku addresses: an AI-native desktop workspace where you mirror an AI app or workflow that already works, run it on your machine, and remix it into your own. Taku is in Beta, and the Mac app is available now. The free app library is the quickest way to see the difference between designing a workflow and borrowing one.

Deciding

• Hard data-residency requirement → n8n, self-hosted. Nothing else on this page matters.
• Nobody owns infrastructure → Make, or n8n Cloud.
• Thousands of records per run → n8n. Make's per-bundle metering works against you.
• A non-engineer maintains it → Make.
• Heavy AI or code steps → n8n.
• Genuinely unsure → build your single heaviest workflow on both. A day of prototyping settles it better than any comparison table, this one included.

If you're still weighing the wider field, n8n alternatives and Make alternatives each cover the rest of the category.

FAQ

Which is cheaper, Make or n8n?

Self-hosted n8n is cheaper at any real volume, because you pay for a server rather than for activity. Between Make and n8n Cloud it depends on shape: Make is competitive for low-volume scenarios, and n8n pulls ahead as data volume or workflow length grows.

Why does my Make credit usage climb faster than my scenario count?

Because credits are consumed per module run per bundle, not per scenario. A trigger returning more records multiplies every downstream module, and an aggregator before the fan-out is the standard fix. AI features are the other cause — several bill dynamically on tokens or run time rather than at a flat credit rate.

Is n8n open source?

No. It's source-available under the Sustainable Use License — free to self-host and modify for internal use, not licensed for reselling as a hosted service. Use restrictions put it outside the OSI definition.

Can I import Make scenarios into n8n?

No supported path exists. Migration means rebuilding, and rebuilding without re-thinking the billing model usually produces a disappointing result.

Does Make have AI features?

Yes, as modules within a scenario. Third-party AI apps bill 1 operation as 1 credit; Make's own AI Provider and its automatic-connection features bill on tokens and other usage factors, so cost tracks volume of text rather than step count. n8n's AI support goes deeper with LangChain nodes and local models. If AI reasoning is the centre of the work rather than one step in it, an AI-native platform is a better shape than either.

What about Zapier?

Different metering again — per successful action step, with free triggers and free built-in logic. Zapier is cheaper than Make for high-volume simple work and more expensive than n8n for long workflows.