n8n vs Make for agencies: an opinionated take

The honest tradeoff

Most "n8n vs Make" articles are a feature table with a winner decided by who's paying for the post. Here's the real axis for an agency: Make sells you speed and support; n8n sells you control and margin. Make is a hosted product — you log in, connectors just work, and someone else runs the servers. n8n is software you can self-host — nothing to log into that you don't own, no per-operation meter, and you can crack open anything, but the running of it is now your job. Every other difference is downstream of that one.

I build primarily on n8n and I'll tell you exactly when that's the wrong call. This isn't a pitch for one tool; it's the decision I actually make per engagement.

Where Make wins

Time-to-first-automation. If a non-technical operator needs to wire two SaaS tools together this afternoon, Make's hosted connectors and cleaner visual builder get there faster with less that can go wrong. There's no server, no database choice, no version to pin.

Breadth of maintained connectors. Make maintains a large library of polished, first-party integrations. n8n has a big node library too, but the long tail leans more on community nodes of varying quality — and when a community node lags an API change, fixing it is on you.

You don't want to run infrastructure. Self-hosted n8n means you own uptime, backups, the Postgres database, and upgrades. If nobody on the account will own that, Make's "it's just handled" is worth real money — an automation that silently dies because a self-hosted instance ran out of disk is more expensive than any subscription.

Where n8n wins

Cost at volume. Make meters by operation. A workflow that fires tens of thousands of times a month has a bill that scales with it. Self-hosted n8n's cost is the box it runs on, roughly flat as volume grows. Past a certain throughput the economics aren't close.

Real code when you need it. n8n has a Code node and, more importantly, lets you build custom nodes in TypeScript and call anything. When an integration doesn't exist or an API is weird, you write it instead of filing a feature request and waiting. For an agency whose value is doing the thing the no-code tool can't, that's the whole game.

Data residency and control. Self-hosting means client data flows through infrastructure you control, in the region you choose. For agencies with clients who have compliance or data-locality requirements, that's not a nice-to-have — it's the difference between being able to take the contract or not.

It's yours. No per-seat pricing on the fulfillment side, no vendor deprecating a feature you built a client deliverable on, and workflows you can version-control and move between environments. The production reliability patterns are the cost of that ownership — you're taking on the operations, and doing it well is a skill.

The agency-scale decision

For a GoHighLevel or automation agency the calculus is specifically about margin on white-label fulfillment. If you're reselling automation to clients, Make's per-operation cost comes straight out of your margin on every client, forever, and it compounds as you add clients. Self-hosted n8n moves that to a fixed infrastructure cost you amortize across the whole book. Add the ability to build custom nodes for the integrations your niche needs, and data residency for the clients who ask, and n8n is usually the better business under an agency — provided you can operate it.

That proviso is the whole thing. n8n's advantages are real only if someone owns the instance competently. An agency that picks n8n for the margin and then runs it like a hobby project loses more to downtime than it ever saved on operations fees.

My default recommendation

Start clients on n8n when the work is ongoing, high-volume, or needs custom integrations — which for a fulfillment agency is most of it — and put it on infrastructure that's actually maintained, whether that's n8n Cloud to skip the ops or a properly-run self-host to capture the full margin. Reach for Make when a client's operator will own simple internal automations themselves, or when a one-off needs to ship today and will never scale. The tool is a consequence of who maintains it and how much it runs, not a religion. When I scope an engagement, that's the question I answer first — and it's why the same person recommends different tools to different clients.

If you've already started on Make and are feeling the per-operation bill, moving the high-volume workflows to n8n is a standard migration — the GHL→n8n webhook guide is where most agency migrations start, because the CRM trigger is the hub everything else hangs off.

Browse 4,900+ ready-to-import workflow templates →