Make.com vs n8n: Which to Pick

I get asked this question almost every week, usually by an owner who got two quotes from two different automation people and can't figure out why the numbers look so different for what sounds like the same thing.

The honest answer is that Make and n8n are not competing on quality. Both are capable, mature platforms. They're competing on a completely different axis: how you pay, who hosts it, and how much technical comfort the build assumes. Get that axis wrong and you either overpay for headroom you'll never use, or you save $20 a month and end up locked out of your own automation six months later.

I run both. Not because I can't pick a favorite, but because the right answer depends on the business, not on the tool. This guide is the framework I actually use, not a marketing comparison.

The one distinction that explains almost every price difference you'll see

Before anything else, you need to understand this, because it's the root of nearly every confusing quote you'll get: Make charges by operations. n8n (cloud) charges by executions, and self-hosted n8n charges nothing per run at all.

• An operation (Make) is one action inside your workflow. If your automation reads a new lead, checks it against a list, formats a message, and sends it, that's four operations, for one lead.
• An execution (n8n) is one full run of the whole workflow, start to finish, no matter how many steps are inside it. That same four-step automation, run for one lead, is one execution.

This is the whole game. A workflow with 8-10 steps that runs 500 times a month is roughly 4,000-5,000 operations on Make, but only 500 executions on n8n. The more steps your automation has, the more the math tilts toward n8n. The fewer steps, the less it matters.

What this looks like in real dollars

If you already have a quote in hand and can't tell whether the pricing tier makes sense, this gets you a straight answer fast:

I got a quote for an automation and want to sanity-check the pricing tier.

Here's what the automation does, step by step:
[LIST EACH STEP, e.g. "1. New form submission comes in. 2. Check if email exists in CRM. 3. If new, create contact. 4. Send welcome email. 5. Add to follow-up sequence."]

It's expected to run about [NUMBER] times per month.

If this is a Make.com quote: estimate the monthly operations count (remember every step counts once per run, and routers/filters count their branches too) and tell me which pricing tier that lands in.

If this is an n8n quote: this counts as 1 execution per run regardless of steps, so tell me if [NUMBER] executions/month is closer to a free tier, a paid cloud tier, or would be cheaper on a self-hosted instance.

Show your math.

Hosted vs self-hosted, and why it matters more than the sticker price

Make is hosted only. You don't manage a server, you don't do updates, and you don't think about uptime. You log in, you build, it runs. That's the entire deal, for better and worse.

n8n gives you a real choice: pay for n8n Cloud (hosted, same deal as Make) or self-host it on your own server. Self-hosting is where n8n's pricing story gets genuinely different, because a self-hosted instance has no per-execution fee at all. You pay for the server, not the runs.

1. n8n Cloud is the closest apples-to-apples comparison to Make. Same convenience, same 'someone else handles the infrastructure' tradeoff. Priced on executions, tiers scale up as volume grows.
2. Self-hosted n8n runs on a VPS you (or your automation person) manage. A small droplet running 24/7 typically costs $5-20/month in server fees, and it doesn't matter if that server runs 500 executions a month or 50,000. The ceiling on runs effectively disappears.
3. The catch with self-hosting is that 'you manage it' is not a small phrase. Someone has to keep the server patched, watch for it going down, back it up, and fix it when it breaks at 11pm on a Sunday. That someone is either you, or someone you're paying to be on call.

Before you agree to a self-hosted build, get the maintenance ownership in writing. This is the message I send every self-hosting client before we start:

Before we move forward with self-hosted n8n, I want to confirm ownership of these in writing:

1. Who patches the server and n8n version updates, and how often?
2. Who gets alerted if the server goes down, and how fast is the response time?
3. Where are backups stored, and how often are they taken?
4. If the server needs to be rebuilt from scratch, how long would my automations be down?
5. Is ongoing server maintenance included in this price, or billed separately?

Please answer each one directly so I know exactly what I'm responsible for versus what you're responsible for.

Learning curve: what you're actually signing up to maintain

This section matters most for owners who want to eventually touch their own automations, not just receive them finished. If you're never going to open the builder yourself, skip to the next section. If you might, read this one twice.

Make

Make's canvas is visual and modular, closer to following a flowchart than reading code. Modules connect with literal lines you drag between bubbles. Most small business owners can understand what an existing Make scenario is doing within 20-30 minutes of guided walkthrough, even if they couldn't build one from scratch yet. It's the friendlier on-ramp of the two.

n8n

n8n's canvas looks similar at first glance, nodes and connecting lines, but the depth underneath is higher. Expressions (the small pieces of logic that pull data from one step into another) use a JavaScript-flavored syntax, and n8n leans harder into 'you can write real code in this node if you need to.' That's a feature for a technical hire and a wall for a non-technical owner. Reading an existing n8n workflow to understand what it does typically takes longer than reading the equivalent Make scenario, especially once expressions are involved.

• If you want to eventually make small edits yourself (swap an email address, change a delay time, adjust a message), Make is the friendlier long-term hand-off.
• If you're outsourcing the automation entirely and never plan to open the builder, the learning curve difference matters to your automation person, not to you.

If you've inherited an existing workflow and just need to understand what it does before you touch anything, this works on either platform:

I'm looking at an automation workflow I didn't build and need to understand it before I touch anything.

Here's what I can see in the builder:
[DESCRIBE EACH MODULE/NODE IN ORDER, e.g. "1. Webhook trigger. 2. Filter: only continue if status = 'new'. 3. HTTP request to an API. 4. Router with 2 branches. 5. Send email in each branch."]

Explain in plain language:
1. What triggers this workflow to run
2. What each step does, in order
3. Which parts look safe to edit (like a delay time or an email address) versus which parts would break the logic if changed
4. What would happen if I disabled or deleted this workflow entirely

Keep it non-technical. I'm not a developer.

Where each one actually wins

No hedging here. These are the situations where I reach for one over the other, based on real client builds.

Make wins when

• The automation is low-to-moderate volume (under a few thousand operations a month) and simplicity matters more than raw cost per run.
• The client wants to eventually poke around inside it themselves.
• You need deep, pre-built integrations with mainstream SaaS tools (CRMs, spreadsheets, form tools, e-commerce platforms) with minimal custom configuration.
• You want zero infrastructure to think about, ever, and are fine paying a premium for that.
• The build needs to look presentable in a screen-share with a non-technical stakeholder.

n8n wins when

• The workflow is step-heavy and high-frequency, where Make's per-operation cost would balloon past what the client wants to spend.
• You need custom logic that goes beyond what a visual builder's native modules offer, custom code nodes, complex conditionals, or unusual API handling.
• Data sensitivity matters and self-hosting keeps everything on infrastructure the client (or you) controls, instead of a third-party cloud.
• You're running high-volume, always-on automations where the flat server cost of self-hosting beats a metered plan by a wide margin.
• The build is going to live inside a broader technical stack that someone will maintain long-term (an agency, an internal ops hire).

The tool isn't the decision. The volume, the maintenance owner, and the client's comfort level are the decision. The tool just follows from those answers.

· Dylan Handy

The 5-question decision checklist

Run through these five questions before you commit to either platform. Answer them honestly, in order. By question 5 you'll almost always already know the answer.

1. How many steps does the automation have, and how often does it run? Rough math: steps x monthly runs = your operations estimate on Make. If that number is climbing into the tens of thousands, n8n's per-execution model or a self-hosted setup starts winning on price.
2. Who is going to maintain this a year from now? If the honest answer is 'nobody technical, it just needs to keep working,' lean Make or n8n Cloud. If the answer is 'me, or a technical hire, and we're fine owning infrastructure,' self-hosted n8n opens up.
3. Does the build need anything a visual builder can't natively do? Custom code, unusual API handling, or complex branching logic pushes toward n8n. Standard SaaS-to-SaaS automation pushes toward Make.
4. Is data sensitivity or data residency a real requirement, not just a preference? If yes, self-hosted n8n is worth the extra maintenance conversation. If the data is routine business ops data, hosted platforms are fine.
5. What's the actual monthly budget ceiling, and is it fixed or does it flex with growth? A fixed, low ceiling with growing volume points toward self-hosted n8n's flat server cost. A flexible budget that values convenience over optimization points toward Make.

I'm trying to decide between Make.com and n8n for [DESCRIBE THE AUTOMATION].

Here's what I know:
- Roughly [NUMBER] steps in the workflow
- Runs about [NUMBER] times per month
- [Who will maintain it: me / a technical hire / you, ongoing]
- [Any custom logic needed: yes/no, describe]
- [Data sensitivity requirements, if any]
- Monthly budget ceiling: [AMOUNT]

Based on this, which platform do you recommend and why? I want the actual reasoning, not just a preference.

What I actually run, and why

I run both platforms across different client builds, and the split isn't random. Clients with straightforward, moderate-volume automations that they might eventually want to peek inside sit on Make. Clients with higher-volume, multi-step workflows, or ones where I'm already maintaining infrastructure for other parts of their stack, sit on self-hosted n8n.

Neither platform is the 'better' one in the abstract. The mistake I see most often isn't picking the wrong tool, it's picking a tool before answering the five questions above. Answer those first. The platform picks itself.