The three platforms in one paragraph each
Zapier is the most polished and the most expensive. It has the widest app catalogue, and an operations person with no engineering background can build something genuinely useful in an afternoon. Make is the visual middle ground: cheaper per operation, far better at branching and iteration, with a canvas that keeps complex scenarios readable. n8n is the engineer’s option — fair-code licensed, self-hostable, with a code node for when the visual approach runs out of road.
All three run the same basic shape: a trigger, some steps, error handling. The differences show up at the edges. What happens when a run fails at step seven of nine? Can you loop over 800 invoice lines without paying for 800 tasks? How do you test a change without firing real webhooks at a live customer? Those three questions separate the platforms far better than any feature list does.
Cost: where per-execution pricing hurts
Pricing models differ in a way that matters at scale. Zapier charges per task, and a task is any step that runs. A five-step Zap processing 4.000 orders a month is 20.000 tasks, which puts you well past the entry tiers and into several hundred US dollars monthly. At 50.000 tasks you are looking at Rp 5 to 10 juta a month, indefinitely, for automation logic you would also have to rebuild if you ever left.
Make counts operations in a similar way but prices them lower, so the same workload often costs about a third of Zapier. Self-hosted n8n changes the shape of the cost entirely: a 4 GB VPS in a Jakarta data centre runs Rp 300 to 600 ribu a month whether you execute a thousand workflows or a million. The variable cost disappears and reappears as engineering time.
Self-hosting, residency, and compliance
Where the data lives stops being an abstract question the moment a workflow touches customer records. Under UU 27/2022 you need a documented basis for sending personal data outside Indonesia, and financial institutions carry additional expectations from OJK about where certain systems and their data sit. A cloud automation platform means every payload passes through servers in Ireland or Virginia, including the ones carrying NIK and account numbers.
- Self-hosted n8n keeps webhook payloads inside your own network and your own audit logs
- Managed platforms require a transfer basis, a signed DPA, and a line in your processing record
- Check whether credentials for core systems may leave the company at all under your infosec policy
- Regulated clients often accept a managed tool for internal data and self-host anything with PII
There is a pragmatic middle path we use often: self-host n8n for anything touching the ERP and personal data, and keep a cheap managed plan for marketing and internal notifications where the payload is harmless. Splitting platforms by data sensitivity is far easier to defend to an auditor than splitting them by whoever happened to build the workflow first.
Reliability is the other half of the residency question. A managed platform absorbs its own outages and retries; a self-hosted instance is yours to keep alive. Run it with Postgres behind it, queue mode with Redis once volume grows, an uptime check that actually pages somebody, and a restore you have tested. Otherwise the compliance win arrives with an availability loss nobody agreed to.
Team capability is the real constraint
The honest constraint is rarely technical. Self-hosted n8n assumes somebody on your side can read a stack trace, run docker compose, apply an upgrade that occasionally changes node behaviour, and configure queue mode with Redis when a single process stops keeping up. If that person does not exist and you are not paying a partner to be that person, n8n becomes shelfware within a quarter no matter how good the demo looked.
The opposite failure is just as common. We have found finance teams running genuinely critical reconciliation logic in Zapier because it was the tool they could use, with no version control, no test environment, and no way to explain why a run failed last Thursday. Accessibility is a real benefit right up to the moment the automation becomes load-bearing.
A useful test before committing: ask the person who would own the platform to describe exactly what they would do if a workflow silently stopped firing at 03:00 on a Sunday. The quality of that answer tells you more about the right choice than any trial account or vendor demo ever will.
A decision matrix you can use tomorrow
Most decisions collapse into a handful of patterns once you stop treating this as a feature comparison. Run your own numbers through the list below — monthly execution volume, the sensitivity of the data moving through each workflow, and whether anyone on staff can be paged about it. Those three inputs decide it more reliably than any scoring matrix.
- Under 5.000 tasks a month, no engineering team, mostly SaaS to SaaS: choose Zapier and stop optimising
- High volume with heavy branching and data transformation, nothing regulated: choose Make
- Any workflow touching NIK, NPWP, salary, or core banking data: self-host n8n in a Jakarta region
- Deep ERPNext integration with custom API calls and long-running jobs: n8n, for the code node alone
- A regulated client under OJK scrutiny: assume self-hosting and budget the operational overhead honestly
- Most mid-market companies end up mixed: n8n for the core, one managed platform for marketing edges
One last rule that applies to all three. Whatever you choose, put the workflow definitions in version control — every platform exports JSON. A weekly export committed to a repository has rescued more client projects than any feature on any comparison page, because the failure that actually hurts is not the platform going down. It is somebody editing a live workflow at 16:00 on a Friday.