n8n or Make: Which to Choose for Business Automation
Per-operation against per-execution billing, data that leaves or stays, and who maintains this in six months. The questions that decide, without prices that age.
1. The question everyone asks, and the one they should
"Which is better, n8n or Make?" has no answer, because they solve the same problem from opposite ends. **Make** is a hosted service. You open an account, connect your apps and build the flow on a visual canvas. No server, no upgrades, nothing to maintain. You pay per operation executed. **n8n** is software you can also host yourself. There is a paid cloud version, but what sets it apart is running the community edition on your own server, with no execution cap and with data never leaving your infrastructure. The useful question is a different one: **which costs you more, the monthly bill or the maintenance hours?** If it is the bill and you can run a server, self-hosted n8n wins by a wide margin. If it is the hours, Make. The rest of this article is the detail behind that decision.
2. How each one charges, and why that changes everything
This is the difference with the most practical consequences. **Make** charges per **operation**. Every step executed in a scenario counts: reading an email is one operation, filtering is another, writing to the sheet is another. A ten-step flow running a hundred times a day burns a thousand operations daily. People who design without counting operations find out on the first invoice. **n8n cloud** charges per **execution** — one execution is the whole flow, whether it has three steps or thirty. For long flows the difference is large. **Self-hosted n8n** counts nothing. You pay for the server and run what you like. I am not quoting prices: they change, and both companies have restructured plans more than once. Check the official tables on the day you decide. What does not change is the **model**, and the model is what decides whether your case is cheap or expensive. Do the arithmetic first: how many steps the typical flow has, how often it runs per day, and multiply. It is half an hour that avoids a surprise.
3. Comparison by criterion
The table compares what stays stable. Integration counts and prices are left out because they age month to month.
| Criterion | Make | n8n (cloud) | n8n (self-hosted) |
|---|---|---|---|
| Billing unit | Por operação | Por execução | Nenhuma |
| Maintenance | Nenhuma | Nenhuma | Servidor é seu |
| Code inside the flow | Limitado | JavaScript e Python | JavaScript e Python |
| Where data travels | Servidores do fornecedor | Servidores do fornecedor | Só pela sua máquina |
| Ready-made integrations | Muito amplas | Amplas | Amplas |
| Calling an API with no integration | Módulo HTTP | Nó HTTP | Nó HTTP |
| Learning curve | Mais suave | Média | Média, mais servidor |
| Version control | Limitado | Exportação JSON | JSON em Git |
4. When Make is the right choice
**When nobody on the team codes.** Make’s editor is more approachable, the library of ready integrations is larger, and a non-technical person can change a flow without breaking it. **When you need to be running today.** No server to provision, no certificate, no backups. Open the account and start. **When the integration you need already exists.** If Make has a ready module for the niche application you use, that saves hours — and probably exists nowhere else. **When volume is low.** At a few executions a day, the entry plan costs less than any VPS, and you spend no time on maintenance. There is nothing wrong with paying not to manage infrastructure. It is a legitimate trade, and for many businesses it is the right one.
5. When n8n is the right choice
**When flows are long.** Charging per operation penalises exactly the kind of automation that saves the most work. A thirty-step flow costs thirty times more on Make, and the same as a three-step one on n8n. **When data cannot leave.** Self-hosted, nothing passes through third-party servers. If you process customer data, contracts or internal records, this stops being a preference and becomes a requirement — and it simplifies the GDPR conversation considerably. **When you need code in the middle.** n8n lets you write JavaScript or Python inside the flow. Transformations that would need chained modules on Make take ten lines. **When volume is high and steady.** Past a certain point, a VPS costing a few euros runs what would cost far more in operations. **When you want flows in Git.** Export as JSON, version them, review in a pull request. For anyone treating automation as software, this changes how you work. The cost is real: upgrades, backups, monitoring and downtime become yours.
6. Installing n8n to try it
Before deciding, run it locally for half an hour. With Docker it is immediate, and trying it answers better than any comparison. For production add a reverse proxy with TLS, a PostgreSQL database instead of SQLite, and backups of the volume — the same pattern described in the article on running models on your own VPS.
services:
n8n:
image: docker.n8n.io/n8nio/n8n
restart: unless-stopped
ports:
- "127.0.0.1:5678:5678"
environment:
- N8N_HOST=automacao.seudominio.pt
- WEBHOOK_URL=https://automacao.seudominio.pt/
# Sem isto, qualquer pessoa que alcance a porta entra.
- N8N_BASIC_AUTH_ACTIVE=true
- N8N_BASIC_AUTH_USER=admin
- N8N_BASIC_AUTH_PASSWORD=${N8N_PASSWORD}
- GENERIC_TIMEZONE=Europe/Lisbon
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:7. Mistakes that cost in both
**Not handling failures.** A flow with no error handling fails silently, and you find out when a customer asks about something that never arrived. Add failure notification on day one. **Polling instead of listening.** Checking a mailbox every five minutes burns executions all day for nothing. If the application supports webhooks, use them: they react in real time and consume nothing while there is no work. **Storing credentials inside the flow.** API keys pasted into nodes end up in exports and screenshots. Both have their own credential management. **Automating a process nobody defined.** Automating a mess produces a faster mess. Write the steps on paper first; half the time you discover the process itself was wrong. **Not testing with real data.** Flows that work on the perfect example break on the first empty field or unexpected accent.
8. Moving from one to the other
There is no automatic import. The formats are incompatible and migration means manual rebuilding. In practice migration is less bad than it sounds, because flows rarely survive intact anyway: rebuilding shows you steps that are no longer needed. But budget the time. What reduces the cost of switching later: document what each flow does and why, keep business logic outside the tool where you can — in an API of your own that either can call — and avoid depending on features only one of them has. If you are starting and unsure, start with Make. It is faster at validating whether the process is worth automating at all. If volume or cost later justify it, you migrate already knowing exactly what you need.
9. How to decide in twenty minutes
Answer four questions in writing. **Who maintains this in six months?** If it is not someone who codes, Make. **Is the data passing through sensitive?** If so, and if that forces you to justify where it is processed, self-hosted n8n. **How many steps does the typical flow have, and how often does it run?** Multiply. If it comes to thousands of operations a day, Make’s model will hurt. **Do you have somewhere to host and someone to maintain a server?** If not, self-hosted n8n is not an option, however attractive the cost looks. In most cases the answers converge. When they do not, start with Make, validate the process is worth automating, and migrate when cost justifies it.
Frequently Asked Questions
Is n8n free?
The community edition is free to self-host, under an open licence with usage restrictions — read it before embedding it in a product you resell. The cloud version is paid. "Free" means no licence fee, not no cost: the server and the maintenance are yours.
Can I use both at once?
You can, and sometimes it makes sense: Make for what needs ready integrations with niche applications, n8n for what is high-volume or touches sensitive data. The cost is maintaining two tools and always knowing where each flow lives.
Which connects better to language models?
Both connect to the usual APIs and both can call any API over HTTP. The practical difference is that n8n lets you write code in between, which helps when the model’s output needs handling before use.
Do I need to code to use n8n?
For simple flows, no — the editor is visual. But the curve is steeper than Make’s, and self-hosting needs comfort with Docker, DNS and certificates. Without that, the cloud version or Make will save you frustration.
What happens if my n8n server goes down?
Flows stop and webhooks arriving in that period are lost, unless the sender retries. That is the trade-off of self-hosting: availability becomes yours. Monitoring and alerting stop being optional.