Both tools do the same thing on the surface: a trigger fires, data moves through a chain of steps, something happens at the end. Pick either and you can build a working automation in an hour. The differences only surface later — in what breaks, what it costs at volume, and how hard it is to fix at speed.
1. Where it runs
Make is cloud-only. You get an account, a canvas and a bill. n8n can be either: a hosted plan that looks a lot like Make, or a container you run yourself on a VPS.
Self-hosting matters for two reasons. The first is data: if your workflow touches customer records, keeping them on your own infrastructure is a materially easier conversation with a compliance team. The second is cost shape — self-hosted n8n costs the same whether you run a hundred executions a month or a hundred thousand, which changes the economics of anything high-volume.
2. How it is priced
Make charges by operation. Every module call in every run counts, so a workflow that loops over two hundred rows costs two hundred operations. This is fine until you build something that iterates, at which point costs rise faster than most people plan for.
n8n's cloud plans charge by workflow execution rather than by step, so a run that loops a thousand times still counts once. Self-hosted, you pay for the server.
Neither model is dishonest — but they reward different designs, and it is worth knowing which one you are optimising for before you build.
3. What happens when a step fails
This is where the two diverge most, and it is the part a demo never shows.
- Make has error handlers you attach to a module, plus a break/retry directive and an incomplete-executions queue that holds failed runs for you to resume by hand. That queue is genuinely useful.
- n8n gives every node an error output you can wire like any other branch, plus a separate error workflow that fires when a run dies. Because the error path is just another branch on the canvas, it is easier to build something sophisticated — and easier to forget entirely.
Whichever you pick: build the failure branch in the first version. Retrofitting error handling into a workflow that already runs in production is how weekends disappear.
4. Version control and review
n8n workflows are JSON. You can export them, commit them, diff them and review a change before it ships. If more than one person touches your automations, this alone is a strong argument.
Make has version history inside the product, which covers the "what did I break" case but not the "review this before it goes live" one.
5. So which one?
A rough rule that holds up:
- Automating your own or a small team's work, no infrastructure appetite → Make. The canvas is friendlier and there is nothing to run.
- High volume, loops, or data that should not leave your servers → n8n, self-hosted.
- Building automations for clients → n8n. Exportable JSON means you can hand over an asset rather than a login.
- Learning to be employable → n8n first. The concepts are identical and the tool is more common in engineering-adjacent job posts.
The genuinely important skill is not either tool. It is knowing what a robust workflow looks like — idempotency, retries with backoff, a dead-letter path, alerting that reaches a human — and that is the same in both.
Both are taught here with the workflow files included: browse the courses and open a preview lesson before you decide.