n8n vs Make comes down to who will maintain the automation and how many steps each run has. If a developer or a technical owner will keep it alive and your workflows are long, n8n is usually the better fit. If your team already has working scenarios on Make or wants a hosted tool nobody has to look after, stay on Make.
I build client automations in both, and I lean toward n8n for new custom work. This post explains why, where Make is the better call, and what to check before you choose. If you want a second opinion on your own stack, my n8n build work and my Make.com work cover both sides.
How n8n and Make bill, as of October 20, 2026
This is the section that goes stale, so every price and limit sits here. I read these off n8n.io/pricing, make.com/en/pricing and Make's credits help page on October 20, 2026.
| Item | n8n | Make |
|---|---|---|
| Billing unit | Execution: one run of the whole workflow | Credit: most actions cost 1 |
| Does step count change the bill? | No, per n8n | Yes, a single run can use from 2 credits to thousands |
| Cloud entry price | Starter at 20 euros a month billed annually, 2,500 executions | Not shown on the page when I checked |
| Free option | Self-hosted Community Edition from GitHub | Free plan with 1,000 credits a month |
| Unused allowance | Check the pricing page | Unused credits expire at the end of the term |
Make's page named the Free, Core, Pro, Teams and Enterprise plans but did not list dollar prices or per-plan credit counts in what I could read, so I am not quoting any. Look at the plan you would actually buy before you compare totals. Make also says router modules and the error handler modules (Rollback, Break, Resume, Commit, Ignore) are not counted as credits, and that extra credits come in bundles of 1,000 or 10,000. For n8n's full plan table and what the Community Edition leaves out, my n8n pricing breakdown goes through it line by line.
n8n vs Make pricing: a worked example
This is arithmetic, not a benchmark I ran. Say a workflow takes a form submission, looks the contact up, creates a deal, sends two emails, posts to Slack and writes a row to a sheet. Call it 12 steps, and say it runs 500 times a month.
On n8n that is 500 executions. On Make, if each of those 12 steps is a billable action at 1 credit, that is up to 6,000 credits, a little less if some steps are routers or error handlers. The same flow can sit comfortably inside n8n's smallest plan and still be several times the 1,000 credits Make gives you for free.
Flip it and the gap closes. A 3-step workflow that runs 200 times a month is 600 credits on Make and 200 executions on n8n, and both fit their cheapest tiers. Short, infrequent automations are where Make's billing matters least. Long, busy ones are where it starts to show. That is also why I restructure scenarios to use fewer operations when a client on Make asks me why the bill grew.
Where n8n wins
I reach for n8n when the workflow has real logic in it, like looping over a list of records or calling an API that has no ready-made node. When a node runs out of road I can drop in a Code node or an HTTP Request node and keep going inside the same workflow.
The other reason is ownership. n8n can be self-hosted, so a client whose data has to stay on their own server has a way to do that. It is also a tradeoff, because self-hosting means someone updates it, backs up the database and notices when it falls over. For most of my small-business clients I would rather they were on n8n Cloud and not carrying that.
And there is the execution-based billing above. If I am building a lead pipeline with a dozen steps and an AI classification in the middle, I do not want the client's bill to grow every time I add a step. You can see what that kind of build looks like in the deposit-to-kickoff run, which replays one flow step by step.
Where Make wins
Make is the better pick when the people who will change the automation next year are not technical. Some clients are fine with a visual canvas and nervous about expressions and JSON, and for them a tool they can read at a glance beats a cheaper one they are afraid to touch. That is my read from handing off builds, not something I measured.
It also wins on inertia. If you have twenty scenarios that work, rebuilding them in n8n to suit my preference is a bad use of your money. I would fix the failures with proper error handlers, trim the operations and leave the platform alone. If you prefer a hosted tool with nothing to patch, Make is that by default.
Mistakes I would avoid
- Comparing the entry price of one tool with the entry price of the other. Compare the monthly bill for your busiest workflow at its real step count.
- Polling every minute on either platform. On n8n that burns executions, and on Make it burns credits. Switch to a webhook when the source app supports one.
- Choosing on a feature list. Both can send a Slack message, so test the one awkward step your process has, like a custom API or a messy PDF, and see which tool handles it more cleanly.
- Skipping alerts. A failed run that nobody hears about costs more than either subscription.
What I'd pick
For a new build with more than a handful of steps, or with code and AI in it, I would pick n8n Cloud and move triggers to webhooks. For a team that already lives in Make, or a very simple automation that a non-technical person will edit, I would pick Make. If you cannot tell which group you are in, build the single most annoying workflow you have in both and see which one you would rather open at 9pm when it breaks.
If you are already on Make and the bill is the problem, the answer is often a cleaner scenario and not a new platform. I would tell you that before quoting you a migration. You can browse more finished builds in the automations hub, and the Make.com service page explains how I handle the side-by-side move when switching does make sense.
Frequently asked questions
- Is n8n better than Make?
- For custom builds with branching, code and API calls, I usually pick n8n, and for a team that already runs working scenarios on Make, I keep them there. Neither is better in the abstract. The deciding factors are who maintains the automation after I hand it over, how many steps each run has, and whether you want to host anything yourself.
- Which is cheaper, n8n or Make?
- It depends on how many steps your workflows have. As of October 20, 2026, n8n counts one full workflow run as one execution regardless of step count, while Make bills in credits and most actions cost 1 credit each. Long workflows that run often tend to cost less on n8n, and short ones that run rarely can be cheap on either. Check both pricing pages for current prices.
- Can I self-host Make like I can with n8n?
- I did not see a self-hosted option on Make's pricing page. n8n offers a free self-hosted Community Edition on GitHub. If hosting the tool on your own server matters to you, confirm Make's current options with Make directly before you decide.
- Is Make easier to learn than n8n?
- Many non-developers find Make easier to start with, and n8n gets easier once you are comfortable with JSON and expressions. That is my experience building client work in both, not a measured result. If a non-technical person on your team will edit the automation, let them try both free options before you decide.
- How hard is it to move from Make to n8n?
- You rebuild the logic rather than import it, so the effort scales with the number of scenarios and how much custom logic each one has. The safe way is to run the new n8n workflow side by side with the old scenario on real data, compare the outputs, then switch over and turn the old one off.