On this page 11 sections
Choose Make when the work is connecting well-known SaaS products with visual logic and nobody on the team writes code. Choose n8n when your data cannot leave your infrastructure, when a step needs real code, when workflows loop over many records, or when you want them in version control. The deciding question is rarely features, since both cover the common integrations. It is where the thing runs, how it bills, and who maintains it after the person who built it has moved on.
Most comparisons of these two list integration counts. That is the least useful axis, because both cover the connectors a typical business actually uses.
Key takeaways
- Self-hosting is the single clearest dividing line. Only n8n offers it.
- Billing shape differs more than billing level. Make charges a credit per module action; n8n Cloud charges per workflow run regardless of steps.
- A workflow that loops over 500 records costs hundreds of times more in Make’s unit than in n8n’s. That is arithmetic, not opinion, and it is shown below.
- n8n gives you a real code escape hatch and workflows as JSON. Make gives you the better visual builder.
- Neither is cheaper in general. Model your own volume shape before believing anyone’s comparison, including this one.
Who this applies to
You are picking an automation platform for a business workflow: syncing systems, processing inbound records, routing work, adding an AI step to something that exists. Somewhere between five and a few thousand workflow runs a day.
If you are evaluating for personal productivity, this is over-specified; either works. If you are wiring core transactional infrastructure that must not drop a record, read the error-handling section and consider whether either belongs there at all.
What each one actually is
Make is a hosted visual automation platform, owned by Celonis. You build scenarios on a canvas, the vendor runs them, and you pay in credits, which since August 2025 replaced operations as the billing unit. The visual builder is genuinely good: branching, iteration and data mapping are legible on screen in a way that helps non-engineers reason about a flow.
n8n is a source-available workflow tool you can run yourself or buy hosted. Workflows are node graphs with a Code node where you write real JavaScript or Python, and the whole workflow is JSON you can commit to a repository. The self-hosted Community Edition is free under n8n’s Sustainable Use License, which is fair-code rather than open source in the OSI sense. Internal business use is fine. Reselling it as a service to your own customers is restricted, so read the licence if that is the plan.
That difference in origin explains most of the rest.
Where they actually differ
| Make | n8n | |
|---|---|---|
| Self-hosting | No | Yes. The main reason people choose it |
| Where data lives | Vendor infrastructure | Yours, if self-hosted |
| Billing unit | Credit per module action | Execution per workflow run, or infrastructure cost if self-hosted |
| Code escape hatch | Limited scripting | Full JavaScript or Python in a Code node |
| Version control | Export a blueprint by hand | Workflow JSON, commits cleanly; git sync on higher tiers |
| Visual builder | Stronger | Adequate |
| Non-technical owners | Better fit | Steeper, and much steeper once code appears |
| Custom integrations | Generic HTTP module | HTTP node, or write your own node |
| Scheduling floor | 15 minutes on the free plan, 1 minute paid | Cron expressions, no floor |
| Licence | Commercial SaaS | Sustainable Use License, read it |
Billing shape is the trap
The published per-unit prices are close enough that comparing them is nearly meaningless. The shape is what bites.
Make bills per credit. Each action a scenario performs consumes credits, most actions one credit, with some AI features consuming more. A scenario with five modules spends about five credits per run. An iterator that loops over an array runs the modules after it once per item, so a scenario that fetches 500 rows and processes each one consumes on the order of 500 times the per-item module count.
n8n Cloud bills per execution. The vendor’s own definition: a single run of the entire workflow, however many steps it has and however much data it processes. That same 500-row loop is one execution.
Self-hosted n8n has no per-run billing at all. You pay for a server and the marginal cost of a run is effectively nothing. That inverts the comparison for high-volume work, at the cost of running infrastructure. See self-hosted n8n for what that actually costs in time.
The published tiers, checked on 6 September 2026
Vendors change these, so the figures carry a date and the vendor pages are the source. The shape matters more than the numbers.
| Make | n8n Cloud | |
|---|---|---|
| Free tier | 1,000 credits a month, two active scenarios, 15-minute minimum interval | None hosted. Community Edition self-hosted is free with unlimited executions |
| Entry paid tier | Core, 10,000 credits a month, unlimited active scenarios, from $9 a month on annual billing | Starter, 2,500 executions a month, unlimited users and workflows, 20 euro a month on annual billing |
| Next tier | Pro, 10,000 credits with priority execution and full log search | Pro, 10,000 executions, 50 euro a month on annual billing |
| Team tier | Teams, shared templates and roles | Business, 40,000 executions, 667 euro a month, available self-hosted |
| What scales the bill | Credits consumed | Executions consumed. Steps and data volume do not count |
Read those two rows against the chart. The 500-record workflow run once a day consumes about 60,000 Make credits a month and 30 n8n executions. The same workflow handling one record per run, triggered 2,000 times a month, consumes 10,000 credits and 2,000 executions. Which platform is cheaper depends entirely on that shape. The platform cost comparison does the arithmetic on your own numbers once its prices are verified.
The code escape hatch
This is the difference engineers care about and buyers underestimate.
Every real automation eventually hits a transformation the visual builder does not express well: reshaping a nested payload, a date calculation across time zones, deduplicating against a fuzzy key. In Make you work around it with chained modules and the scenario becomes hard to read. In n8n you write eight lines in a Code node.
The corresponding cost: a workflow with code in it needs someone who can read code. If your automation is owned by an operations person rather than an engineer, that escape hatch is a liability rather than a feature, and Make’s constraint is protecting you.
Version control and handover
n8n workflows are JSON. They live in a repository, changes come through pull requests, and a rollback is a revert. On the Business and Enterprise tiers n8n adds git-backed environments. See version controlling n8n workflows for the working setup.
Make scenarios export as blueprint files, and you can commit those, but the export is a manual step and the format is not designed to be diffed or reviewed. In practice Make scenarios are versioned by the platform’s own history and by nobody else.
This matters at handover more than at build time. A system whose logic exists only inside a vendor’s canvas is a system you cannot review, test outside the platform, or move.
When each one wins
Make wins when:
- The workflow connects mainstream SaaS products and the logic is visual
- Non-engineers will own and modify it
- Volume is modest and per-record rather than bulk
- You do not want to run infrastructure, at all, ever
- Speed to a working scenario matters more than long-term flexibility
n8n wins when:
- Data cannot leave your infrastructure for regulatory or contractual reasons
- Workflows loop over many records per run
- A step genuinely needs code
- You want workflows in git, reviewed like other changes
- You need to reach an internal system with no public connector
- Volume is high enough that per-unit billing is the largest line
Neither wins when the job is really a small service. Some things people build as 40-node workflows are 120 lines of code with a scheduler, and would be easier to test, version and debug that way. A workflow tool is for orchestrating across systems, not for holding your business logic.
Error handling, which decides more than features do
Both can retry a failed step. The difference is what happens on final failure, and the default in either tool is that a failed run is recorded in a log nobody reads.
| Failure | Make | n8n |
|---|---|---|
| Step errors once | Retry via error handler directive on the module | Retry On Fail setting on the node, with wait |
| Step fails permanently | Scenario stops or continues per error handler; incomplete executions can be stored for manual replay | Error Trigger workflow fires; the failed item can be routed anywhere |
| Nobody is told | Default | Default |
| Partial batch | Whole scenario run marked, per-item state is your problem | Per-item, since the workflow can continue on error and branch |
That is fine for a workflow whose failure is obvious within the hour, and dangerous for anything nightly. Whichever you pick, decide before launch where a permanently failed record goes and who is notified. n8n error handling has the pattern, and why automations fail silently is what happens when nobody does.
Migration between them
Not automatic in either direction. The node graphs do not map, credentials must be recreated, and the data-shaping logic usually needs rewriting because the two express iteration differently: Make with iterators and aggregators, n8n with items flowing through nodes as arrays.
Budget roughly a day per non-trivial workflow, plus testing. That is not a reason to avoid switching. It is a reason to make the choice deliberately rather than defaulting into one and reconsidering at scale, when there are forty workflows to move.
What we default to, and when we do not
Our default for client work is n8n, and the reason is narrower than a preference: the workflows are JSON, so they live in the client’s repository under version control alongside everything else we build. That makes changes reviewable, rollbacks real, and handover an actual transfer rather than a shared login. It matters to us because we hand systems over. See what you own after an AI project.
Where we recommend Make instead, and do so regularly: when the person who will own the automation after we leave is not technical. A beautifully version-controlled n8n workflow that the operations manager cannot safely edit is worse for that business than a Make scenario they can. We have lost the automation portion of engagements on exactly this reasoning and it was the right call both times.
The opinion that costs us more: for a meaningful share of what people ask us to build in either tool, the honest answer is that it should be a small scheduled script instead. Workflow tools are excellent at crossing system boundaries and mediocre at holding logic. When the node count passes about thirty and most nodes are transformations rather than integrations, the tool has stopped helping.
When to use neither
When it is one API call on a schedule. A cron job and fifteen lines is less to maintain than a workflow, a platform account and a billing relationship.
When the process is not agreed. Automating a workflow nobody has settled produces an automated argument. Settle it first.
When failure is unacceptable and undetected failure is likely. For payment reconciliation or anything with a compliance dimension, build it with real observability rather than assuming the platform provides it.
When the volume is tiny. Below a few runs a week, the platform overhead exceeds the work. Do it by hand until it hurts.
Frequently asked questions
Is n8n free?
Self-hosted n8n Community Edition is free to run under the Sustainable Use License for internal business use, with unlimited executions. You pay for infrastructure plus the engineering time to operate it. If you plan to offer it to your own customers as a service, the licence restricts that; read it rather than assuming.
What is the difference between a Make credit and an n8n execution?
A Make credit is consumed by each module action, so a run of a five-module scenario costs about five, and a loop multiplies that by the number of items. An n8n execution is one run of the whole workflow, whatever it does. The chart above shows what that means for a 500-record loop.
Which has more integrations?
Both have several hundred and both cover the common business stack. Counting them is close to meaningless. What matters is whether they cover your specific systems, and both have a generic HTTP option for the ones they do not. Check your three most important systems rather than the total.
Can non-technical people maintain n8n workflows?
Simple ones, yes. Once Code nodes and expressions appear, realistically no. Decide who owns the workflow after handover before you choose the tool, because that answer usually settles the question.
Does self-hosting satisfy our compliance requirement?
It removes one class of concern: data leaving your infrastructure via the automation platform. It does not remove the others. Your workflows still call third-party APIs, and those calls still send data outward. Self-hosting the orchestrator is not the same as keeping data in your estate.
What about Zapier?
Different position: the easiest to start with, the most expensive at volume, and the least flexible. If you are already on it and hitting limits, see migrating from Zapier to n8n. For all three side by side, organised by job, see Zapier, Make or n8n.
Next step
If you want the choice made against your actual workflow shape and volume rather than a feature table, that is where the n8n and Make automation engagement starts, including the version where the answer is a scheduled script.
Related: Self-hosted n8n: when data rules force it · n8n error handling · Version controlling n8n workflows · Zapier, Make or n8n · Business process automation