n8n vs Make — the full comparison

What each one is — in 30 seconds

Make (formerly Integromat) is a cloud (SaaS) automation platform with a colorful visual editor based on "Scenarios." It's aimed at people who want to start fast without dealing with infrastructure — you sign up, connect apps, and build automation by dragging.

n8n is a node-based automation platform with an emphasis on developers and flexibility. You can run it on their managed cloud or self-host it — which gives full control, data privacy, and a fixed cost instead of paying per operation. n8n is also open (fair-code).

Comparison table

Pricing — where the real difference is

This is usually the deciding factor. Make prices by operations (each module action = one op). It's cheap at first but climbs quickly as scenarios get complex and run often. n8n in the cloud prices by executions (running a whole workflow = 1, no matter how many nodes) — very efficient for heavy workflows. And with self-hosting the cost is only your server — a small VPS — with no operation limit.

• Make: a free tier with a monthly operation allowance, then paid tiers that scale with volume.
• n8n Cloud: paid tiers priced by executions rather than by operations.
• n8n self-hosted: the software costs nothing; you pay for a server, with no operation limit.
• Check both vendors' current pages before deciding — the tiers and allowances in this category are restructured often, and the shape below matters more than any figure.

When to choose each

Choose Make if…

• You're non-technical and want to start today, without servers
• You need a rare integration they have ready-made (2,000+ apps)
• The priority is a pleasant visual UX and a minimal learning curve
• Monthly volume isn't huge, and ease > control

Choose n8n if…

• You're a developer / technical team that wants flexibility and custom code (JS/Python) inside the flow
• Data privacy matters to you — that data shouldn't pass through a third-party cloud
• You want to build AI agents and complex pipelines (n8n is especially strong here)
• There's high volume and self-hosting will save you a lot of money over time
• You need full control: versioning, Git, dev/prod environments

Operations versus executions, worked through

This is the single most consequential difference and it deserves the arithmetic, because the same automation can cost very different amounts depending on which model you are on.

Per operation means every module action is billed. Per execution means one workflow run is billed once, however many nodes it touches.

Take a realistic job: fetch 200 rows from a spreadsheet, for each one call an API and write a result. On a per-execution model that is one run — one unit. On a per-operation model it is the trigger, plus the fetch, plus two operations for each of the 200 rows: several hundred units for the same work, every time it runs.

That is not a criticism of either model — it is a shape you need to match to your workload:

• Many simple workflows, each a few steps, running occasionally. Per-operation pricing is fine and often cheaper, because you are billed for the little you do.
• Few workflows that loop over lots of data. Per-operation billing punishes you severely. This is the case people get wrong, and they discover it in month two.
• High frequency, small payloads — a webhook firing constantly. Both models add up; count the runs before committing.

Before choosing, sketch your busiest workflow and count: how many steps, how many items it loops over, how often it runs. Multiply. That figure, not the headline tier price, is what your bill will look like.

Self-hosting is cheaper, not free

"Free plus a small server" is the strongest argument for the self-hosted route and it is incomplete in a way that matters for a small business deciding between them.

What you also take on:

• Updates. The software releases frequently. Staying current is a routine chore; falling behind turns into a difficult upgrade and, eventually, a security question.
• Backups you have tested. Your workflows and credentials live in a database. A backup nobody has restored is a hope, not a backup.
• Uptime. If the server goes down at 3am, the automations stop and nobody is paged unless you built that.
• Security. An automation platform holds credentials to everything it connects to. That server needs to be locked down, patched and not exposed more than necessary.
• Someone who owns it. The real cost. If that person leaves or gets busy, the system decays quietly.

The honest comparison is not "server cost versus subscription". It is server cost plus a few hours a month of competent attention, against a subscription. For a technical team that is clearly worth it. For a business with no one to own it, a managed platform is cheaper than it looks, because the alternative is an unmaintained system holding your credentials.

Error handling is what separates a toy from a system

Both platforms build a working automation in an afternoon. The difference between that and something a business relies on is entirely in what happens when a step fails — and this is where most self-built automations are unfinished.

What a production workflow needs, on either platform:

• A dedicated error path. When a run fails, something must notify a human somewhere they will see it. The default on both is that the run stops and the failure sits in a log nobody opens.
• Retries with backoff on anything touching an external API, because transient failures and rate limits are normal rather than exceptional.
• Idempotency. A retried run must not create the record twice. Search-then-update rather than create, keyed on something stable.
• Partial-failure handling in loops. If row 47 of 200 fails, does the workflow stop, skip it, or process the rest and report? All three are valid; not deciding is not.
• A run-count check. The quiet failure is a trigger that stops firing — nothing errors, the work simply stops happening. A weekly glance at whether the execution count looks normal catches it.

Neither platform gives you these by default. Both support all of them. Whether they exist in your workflows is a discipline question, not a product one.

Working on this as a team

A consideration that does not matter at all for one person and becomes decisive at three.

Automations are production systems edited in a graphical interface, which historically meant no diffs, no review and no way to test a change before it affected real data. Both platforms have moved towards addressing this, and it is worth checking the current state on the tier you would actually buy:

• Can you export a workflow as a file and keep it in version control? This is the minimum, and it makes review and rollback possible even if it is manual.
• Are there separate environments — a place to build and test that is not the one connected to your live customer data?
• Who can edit what, and is there a record of who changed a live workflow at 5pm on Friday?
• Are credentials shared or personal? A workflow running on a departed colleague's connected account is a common and avoidable outage.

If the answer to most of these is no on both, the practical compensation is process: export after every meaningful change, keep the files somewhere shared, and agree who touches production.

Credentials are the real security surface

Whichever you choose, the platform ends up holding tokens for your email, your CRM, your payment system and your files. That concentration is the point and it is also the risk.

• Use dedicated service accounts, not a person's login. When someone leaves, their account gets disabled and you find out which automations depended on it the hard way.
• Scope every credential down. A workflow that reads a calendar does not need permission to delete files. Most integrations request more than they use.
• Know where credentials are stored and encrypted. On a self-hosted instance that is your database and your encryption key — back up both, and understand that losing the key means re-entering every credential.
• Restrict who can see execution data. Run logs contain whatever flowed through the workflow, which frequently means customer records.
• Do not expose the editor to the internet without authentication in front of it. This is the single most common self-hosting mistake.

The AI question

Both platforms now market AI capabilities heavily, and it is worth separating what is genuinely different from what is a node calling an API.

Calling a model from a workflow is the same on any platform — an HTTP request or a wrapper around one. Where platforms actually differ is in the machinery around it: whether there is real support for multi-step agent loops, holding conversation state, connecting tools the model can choose between, and vector storage for retrieval.

That matters if you are building an agent. It matters not at all if what you want is "when a form arrives, summarise it and put it in a sheet" — which is most of what people actually build, and which any platform does well.

A caution that applies to both: a workflow that sends data to a model is sending your data to a third party. The same questions as everywhere else — retention, training, region — apply, and self-hosting the automation platform does not change where the model call goes.

Counting integrations is the wrong comparison

Marketing pages lead with the number of supported apps, and it is close to meaningless for deciding between these two.

What matters is whether the handful you need are supported, and how well. A catalogue of two thousand integrations helps nobody whose particular CRM is not among them, and a platform with fewer native connectors plus a competent generic HTTP node can reach anything with an API — which is nearly everything.

So do the check that actually applies: list the five or six systems you need to connect, and look up each one on both platforms. Then look past the tick:

• Which operations does the connector support? "Supports Gmail" can mean send only, or the full mailbox. The gap between them is your project.
• Does it have a trigger, or only actions? A connector you can write to but not listen to forces you into polling, which is slower and consumes your operation or execution budget continuously.
• How does it handle pagination and rate limits? A naive connector that fetches only the first page is worse than no connector, because the failure is silent.
• How recently was it updated? APIs change; an abandoned connector breaks eventually.

And be realistic about the generic HTTP node. Using it means reading the vendor's API documentation and handling authentication, pagination and errors yourself — perfectly doable for a developer, and a genuine wall for someone who chose a no-code platform precisely to avoid that. That difference, not the catalogue size, is what the integration count is really a proxy for.

Moving between them

Workflows are not portable. Both export to a file, and neither can import the other's — the node types, the data shapes and the expression syntax are all different. A migration is a rebuild.

That is not a reason to agonise over the decision, because the rebuild is usually faster than the original build: you already know what the workflow should do, which was the hard part. But it does mean picking deliberately once rather than drifting, and it argues for keeping your business logic simple enough to re-express — a workflow with forty nodes of intricate branching is a workflow you will never move.

Building the first one so it survives

Whichever platform you pick, the first workflow sets the habits for everything after it. A sequence that produces something you can rely on rather than a demo:

1. Write the process on paper first, including what should happen when each step fails. If you cannot describe the failure behaviour, you are not ready to build it.
2. Build the happy path only, with test data and a test destination. Confirm it does the right thing before it touches anything real.
3. Make it idempotent — search before you create, keyed on something stable. Ten minutes now, and it is the difference between a retry being safe and a retry duplicating a customer.
4. Add the error path. A failed run notifies a person somewhere they actually look.
5. Break it deliberately. Revoke a credential, feed it a malformed record, submit the trigger twice in a row. Fix what you find. This step is the one that gets skipped and it is where the value is.
6. Let it run on real data while you watch it for a few days before anyone depends on it.
7. Export it and put the file somewhere shared, so the workflow exists outside one account.

Then resist adding the second feature to it. A workflow that does one thing reliably is worth more than one that does three things and fails in a way nobody can diagnose — and the platform choice matters far less than this discipline does.

When the answer is neither

• A native integration exists. If the two apps connect directly, use that. A workflow platform in the middle is one more thing to break.
• The logic is genuinely complex. Past a certain branching depth, a visual graph is harder to read and maintain than the twenty lines of code it represents. If your team writes code, that threshold arrives sooner than you think.
• High-volume, latency-critical work. These platforms are orchestrators, not application servers.
• The process is not settled. Automating a process nobody has agreed on produces a fast version of an argument.

The regional angle

Both tools have integrations for WhatsApp, Google Workspace, Telegram and webhooks — so you can build customer-service and lead automations for a local business with either. n8n has an edge when you need to connect local systems through a generic API (the HTTP node) or when you want to keep customer data on a server in your own region for regulatory and privacy reasons. Make wins when you need a ready-made integration for a popular service without writing a line of code.