Make.com vs n8n: The Self-Hosted Question at 10k+ Operations

The conversation almost always starts the same way. An agency or an ops team built their first serious automation on Make.com back when it was still called Integromat. It worked. It kept working. Then the client roster grew, the workflows multiplied, one scenario started firing every 60 seconds against a 40,000-row dataset, and the monthly ops counter that used to sit comfortably under 10,000 started clearing 200,000 without anyone changing what the automation actually does.

The invoice at that point stops being a rounding error. And the question that follows is always some flavor of the same thing: is it time to look at n8n, do we self-host it, and what does the migration actually cost. This post is the honest version of that answer, with real numbers and the parts where Make.com still wins.

For context on who this is for: agencies running client automations at 100k to 2M ops per month, in-house ops teams whose Make.com bill has become a line item finance asks about, and technical founders who are Integromat alternative shopping because their per-execution cost is climbing faster than their revenue. If your workflows fire a few hundred times a day, none of this applies to you and Make.com is fine.

What Make.com actually costs once ops climb

Make.com publishes its pricing, and the low tiers are genuinely cheap. Core starts around $10.59 per month billed annually for 10,000 operations, Pro is roughly $18.82 for the same volume, and Teams runs around $34.12. These are the numbers most people quote when they say Make.com is affordable, and at 10,000 ops they are correct.

The math that catches teams off guard is what happens above that. At 100,000 ops per month, Pro sits closer to $65 to $75, Teams closer to $130. At 800,000 ops, which a mid-sized agency portfolio hits without much drama once you have 20 or 30 active client scenarios each firing on a schedule, Pro lands in the $450 to $550 range and Teams pushes past $800. Enterprise is quoted, not published, and the answer is generally not smaller than that.

The operations model itself is the part that surprises people. One HTTP call is one op. One iterator step is one op per iteration. One aggregator is one op per bundle processed. A scenario that pulls 500 rows, transforms each, and writes them somewhere is 1,500 ops per run at minimum, not one. If that scenario runs every 15 minutes on a business day schedule, you are at roughly 144,000 ops per month from a single automation.

None of this is hidden. It is documented, and Make.com has an ops usage panel that shows exactly where the burn is happening. The issue is that ops-per-workflow scales with data volume, and when the client's Airtable base doubles in size or their Shopify order volume triples in Q4, the monthly bill does the same without anyone shipping new work. Budgeting for it becomes forecasting the wrong variable.

The other line item worth naming: parallel execution. Higher-tier Teams and Enterprise plans buy you more concurrent scenario slots, which matter when a webhook fires 200 times in a burst and your Pro plan queues them serially. Agencies running real-time integrations often move up a tier not for the ops, but for the concurrency ceiling.

Where Make.com is genuinely good

Before the Integromat alternative case, the honest list of what Make.com does well. This part gets skipped in most comparison posts, which makes the rest of the argument weaker than it needs to be.

The visual builder is legitimately best-in-class. Drag, drop, connect, run. The router and iterator paradigms are cleaner than what n8n offers in the free editor, and the mapping panel between modules is more forgiving when the upstream data shape changes. Non-developers can build production workflows in Make.com in a way that is still harder in n8n, even in 2026.

The app catalog is huge and the connectors are well maintained. If your integration includes anything in the Zoho, HubSpot, Pipedrive, ClickUp, Notion, Airtable, Shopify, Meta, or Google Workspace universes, the modules are already there and they usually just work. Authentication is handled, pagination is handled, rate limits are respected. Rebuilding these against raw APIs is more work than most people estimate on the first pass.

Error handling patterns are mature. Filters, break errors, resume from a specific bundle, incomplete executions dashboard, and retry policies at the module level. When a workflow half-fails at 3am, the recovery flow is well-designed and does not require code. A junior ops person can debug and re-run a broken scenario without help.

Data stores and data structures are underrated. Make.com has a lightweight built-in key-value store that solves a real class of problems (deduplication, session state between runs, cross-scenario coordination) without requiring you to stand up a database. For workflows that need a small amount of state, this alone saves hours of infra work.

If your automation portfolio is stable, the ops burn is predictable, and the team building the workflows is not going to write custom code either way, Make.com is doing real work and the price is fair for what you get. That is the profile where we tell clients to stay put.

Where Make.com starts to break at agency scale

The friction points are not bugs. They are design choices that scale poorly once you cross a threshold. The four that come up most often are these.

The ops model taxes iteration, not complexity. A workflow that loops through 5,000 rows to update a status field is 5,000 ops. A workflow that makes one HTTP call and does 50 lines of complex logic in a single Functions module is one op. This means the pricing structure penalizes exactly the kind of data-heavy work that agencies are hired to build. Rewriting scenarios to bundle iteration into single API calls is often the first optimization pass, and it hides real complexity in mapping formulas that get harder to maintain over time.

Custom code has a ceiling. Make.com Functions module supports a limited JavaScript-like expression language for inline logic, and Iterator plus Aggregator can approximate more complex patterns. But if you need a real npm package, a Python step, a custom parser, or logic that runs across 200 lines of code, you are hitting the wall. The workaround is spinning up a serverless function on AWS Lambda or Cloud Functions and calling it from Make.com, which adds another vendor, another bill, and another failure point to the workflow.

Version control is not first-class. Blueprints can be exported as JSON, and Make.com added templates and better team features over the last two years, but the workflow-as-code experience is still built for the UI-first case. Diffing two versions of a scenario, reviewing changes in a pull request, running a test suite against a workflow, or promoting from staging to production through a CI pipeline are all doable with duct tape, but none of them are native. For agencies with an engineering culture, this is a real ergonomics gap.

Multi-client isolation is workable but expensive. Teams and Enterprise plans give you organization structures, but each client's automations still burn ops from a shared pool by default, and separating billing per client typically means separate organizations, which means multiple subscriptions. Agencies running 15 to 30 active client scenarios often end up either eating the ops overage on their internal margin or building a custom billing model on top of the Make.com admin API, and neither is fun.

What self-hosted n8n actually is

n8n is source-available under a fair-code license, which means you can self-host the community edition for free with almost all core features. The Enterprise offering (SSO, LDAP, advanced RBAC, external secrets, log streaming) is a separate paid tier, and n8n Cloud is a hosted managed version if you do not want to run infrastructure yourself. The self-hosted community edition is what most people mean when they say the phrase "self-hosted iPaaS."

Feature-wise, n8n covers most of what Make.com does plus some things Make.com does not. It has 400+ integrations with the major SaaS platforms, HTTP request nodes with full auth support, a Code node that runs real JavaScript and Python (via Pyodide) with access to npm packages in self-hosted mode, an Execute Command node for shell access, credentials management, a queue mode with Redis and workers for horizontal scaling, and workflow-as-JSON that lives cleanly in git.

The visual editor is a step behind Make.com's for pure UX polish. It works, and it has improved a lot since 2022, but the drag-and-drop feel is not quite as smooth and the mapping panel between nodes takes more clicks. The gap is smaller than it used to be. In 2020 it was significant. In 2026 it is a minor tax that most technical teams stop noticing after a week.

Where n8n pulls ahead for agencies specifically is the code story. The Code node accepts real JavaScript or Python, imports npm packages if you allow them in self-hosted config, and returns data the same way any node does. Complex logic that would have required a Lambda callout from Make.com lives inline in the workflow, which is one fewer moving part in production and one fewer bill to reconcile.

The ops model is also fundamentally different. n8n community edition has no per-execution charge. You pay for the infrastructure it runs on, which scales with actual compute needed rather than the count of loops through data. A scenario processing 40,000 rows costs the same in n8n whether it loops through them or not. That single fact is why the migration conversation happens.

Custom code, in real terms

This is the section where the vertical angle for engineering-heavy ops teams matters. Make.com Functions can do a lot, and the built-in text, math, date, and array functions cover most of what a well-designed workflow needs. The moment your requirement is "run this specific data transformation library" or "call a custom internal validation function" or "parse this proprietary file format," you are outside what Functions module can do.

The Make.com workaround is a serverless function elsewhere. You write the code in AWS Lambda or Google Cloud Functions or Cloudflare Workers, expose it as an HTTP endpoint, and call it from Make.com. This works. It also adds hosting cost, a second deployment pipeline, a second monitoring surface, secrets management in two places, and cold-start latency on every call. For an agency running 30 client scenarios that each need one or two custom functions, this stack gets expensive to maintain within a year.

n8n keeps that code inside the workflow. A Code node takes JavaScript or Python, has access to the workflow's input data, can require npm packages when configured, and returns the transformed data to the next node. Debugging is the same as debugging any other node. Version control is the same as any other node. There is no second vendor, no additional bill, and no cold start.

The trade-off is that a Code node can run arbitrary code, which means the workflow author now has the ability to write bugs that Make.com's constrained expression language would not have allowed. Junior automation builders can ship a Code node that leaks memory or blocks the event loop in ways that a Functions module physically cannot. This is a governance issue, not a technical one, and mature teams handle it with code review and a set of internal patterns.

Real cost math for a migration

Run the numbers for a plausible agency case. Say you have 22 active client scenarios averaging 45,000 ops each per month, for a portfolio total near 990,000 ops. You are on Make.com Teams at that volume, paying roughly $900 to $1,050 a month depending on the annual discount, plus one Enterprise-tier custom quote for the biggest client that pushes total spend past $14,000 a year. Two of the scenarios also call out to AWS Lambda for custom parsing, adding another $80 to $150 a month.

Make.com over three years at this profile. Roughly $15,000 to $17,000 per year all-in, growing 15 to 30 percent annually as clients grow. Three-year run rate lands between $52,000 and $64,000.

Self-hosted n8n build cost. Migrating 22 scenarios of moderate complexity, standing up a production n8n cluster with queue mode and workers, setting up authentication, secrets management, monitoring, backup, and a CI/CD pipeline for workflow deployment, plus documentation and internal training runs $28,000 to $48,000 as a one-time engagement. The range depends on how many scenarios have unusual integrations that require custom node development and how mature your existing infrastructure is.

Ongoing hosting. A right-sized n8n cluster on Hetzner, Fly.io, Render, or a small AWS setup runs $110 to $340 a month for compute, managed Postgres, a Redis instance for the queue, secrets management, backups, and observability. Most of the cost is the database and the always-on worker nodes. If you run bursty workloads, spot-priced workers can trim this by 30 to 50 percent.

Maintenance. The honest line. Either an internal engineering owner handles n8n version upgrades, community edition security patches, occasional node compatibility fixes, and integration work as clients add new SaaS tools, or the agency partners with someone (us or otherwise) on a maintenance contract. A reasonable contract at this portfolio size runs $1,200 to $2,400 a month, covering upgrade cadence, on-call for production incidents, and 4 to 8 hours of new workflow build per month included.

Total year-one cost: $46,000 to $80,000 including the build. Years two and three: $16,000 to $32,000 each in hosting plus maintenance. Three-year TCO: $78,000 to $144,000.

On raw dollars, self-hosted n8n costs 1.5x to 2.5x what Make.com does over three years for this specific portfolio profile. The math does not pencil out on the dollars alone at this scale, and we say so directly. The question is whether the things you get for the extra spend (unlimited ops, real custom code, workflow-as-code in git, no per-client billing gymnastics, no ops-tier surprises in Q4) are worth the delta for how your agency actually operates.

Where the ops-cost math flips

The break-even shifts once the portfolio grows or the workflows get more iteration-heavy. Two profiles where self-hosted n8n starts to win on dollars alone:

Very high ops volume. An agency or in-house team processing 5M+ ops per month is looking at Make.com Enterprise quotes in the $2,500 to $4,500 per month range, or $30,000 to $54,000 per year. Self-hosted n8n handles this on a $400 to $700 per month cluster, and the annual delta covers the maintenance contract and the migration payback in year one.

Iteration-heavy workloads. If most of your ops burn comes from workflows that loop over thousands of records per run (data enrichment pipelines, bulk deduplication, catalog syncs, review harvesters), the Make.com bill grows linearly with the data. n8n's cost grows with the compute needed to process the data, which is sub-linear at the volumes we are talking about. At 3M+ iteration-heavy ops, the math on n8n is decisively better in year one.

The inverse also holds. If your workflows are HTTP-call-heavy but not iteration-heavy (webhook receivers, notification routers, simple CRUD sync between two systems), the ops count stays low, the Make.com bill stays reasonable, and the self-hosted case is weaker.

Where Make.com still wins, honestly

The list of teams who should not consider migrating is longer than the list who should. The honest version:

• Non-technical automation builders. If the people building your workflows are ops managers, marketers, or founders without engineering support, Make.com's UI is materially easier and the visual paradigm holds up better under load. Self-hosted n8n does not fit a team that cannot debug a stuck workflow at the container level when something goes sideways.
• Predictable, low-volume workflows. Under 200k ops per month across the whole portfolio, the Make.com bill is small enough that the migration cost has no realistic payback window. Stay put.
• Compliance-heavy environments needing SOC 2, HIPAA, or ISO 27001 vendors. Make.com has SOC 2 Type II and ISO 27001 in place. Self-hosted n8n community edition puts compliance responsibility on you, and n8n Enterprise or n8n Cloud is the equivalent path if you want a vendor-attested compliance posture.
• Heavy reliance on Make.com-specific modules. If half your workflows depend on niche connectors that Make.com has and n8n does not, the migration includes writing custom n8n nodes for each of those, which is real engineering work. Count them before you plan the timeline.
• No engineering capacity for infrastructure. Self-hosted anything needs someone who can run it. If that person does not exist on your team and hiring for it does not make sense, n8n Cloud is a middle path but not free, and Make.com stays the pragmatic answer.

If three or more of these describe your team, keep Make.com. The migration is not for you at this stage.

Where self-hosted n8n actually wins

The flip side. The team profile where self-hosted n8n is the right call looks like this.

• You run 15+ active client scenarios or internal automations, and the ops line has crossed $500 per month with growth expected.
• At least four of your workflows require custom code that currently lives in a Lambda or Cloud Function called from Make.com, adding real operational overhead.
• You have an engineering culture where workflows-as-code in git, code review, and staging-to-production promotion are things the team wants and Make.com is not delivering.
• You are running iteration-heavy workflows where the ops model taxes exactly the kind of work you get paid to do, and rewriting to bundle operations is starting to hide complexity in unmaintainable mapping formulas.
• You have a technical owner (internal or partnered) who can run a small n8n cluster for the next three years without heroics.
• You want per-client cost isolation for the automations side of your agency margin, and Make.com's shared-ops model makes that awkward.

If four or more of these are true, the self-hosted iPaaS conversation is real and the migration math (higher year-one, lower year-three and beyond) works out over the horizon that matters for a growing agency.

The decision framework at three portfolio sizes

Under 200k ops per month. Make.com almost every time. The bill is small, the UI advantage matters at this scale, and the self-hosted infrastructure overhead does not pencil out. Revisit when ops cross 500k or when you find yourself building the third Lambda callout for custom code.

200k to 1.5M ops per month. The interesting middle. Make.com works but the bill is now large enough that migration math starts to make sense on the three-year horizon, especially if half your workflows are iteration-heavy or half need custom code. Self-hosted n8n at this scale is a defensible call, and we have agency clients who went either direction with good reasons.

Over 1.5M ops per month. Self-hosted n8n wins the dollars conversation for most agency profiles at this volume. The Make.com bill is now $1,200 to $4,500+ per month, the ops model is taxing the parts of the work that scale worst, and the engineering team is usually mature enough to own a small cluster. The migration cost pays back in 8 to 18 months at this scale.

Above 5M ops per month, the conversation moves past whether to self-host and into how to architect the n8n cluster properly for queue depth, worker autoscaling, database tuning, and multi-tenant isolation, which is a different post.

What the migration off Make.com actually looks like

Assuming the analysis lands on self-host, the migration runs 8 to 14 weeks for an agency portfolio of 20 to 30 scenarios. The phases are predictable.

Weeks one and two are inventory and mapping. Every scenario is exported as a Make.com blueprint, catalogued, tagged by trigger type, connector list, custom code presence, and estimated complexity. Scenarios with no direct n8n equivalent (unusual Make.com modules, deeply nested router logic) get flagged for rework. This is unglamorous work that determines whether weeks three through eight go smoothly.

Weeks three through eight are the build. Standing up the production n8n cluster (compute, Postgres, Redis for queue mode, workers, secrets, TLS, backups), then porting scenarios in batches. We usually start with the simplest three to five scenarios to get the team confident in the pipeline, then move to the higher-complexity ones. Custom code that lived in Lambda gets pulled into Code nodes inline. Client credentials get moved into n8n's credentials system with per-workflow scoping.

Weeks nine and ten are parallel running. The new n8n workflow runs alongside the existing Make.com scenario against the same triggers, writing to a shadow destination or a separate table. The outputs are compared row by row until match rates clear an agreed threshold (typically 99.7 percent, with the remainder being either genuine edge cases or Make.com behavior nobody noticed).

Weeks eleven and twelve are cutover. Make.com scenarios are turned off in sequence, starting with the smallest, and the n8n workflows take live traffic. A one-week dual-monitoring window follows with direct engineering support. Make.com subscriptions get cancelled after the final cutover, not before, so you have a rollback path if a specific workflow behaves unexpectedly under production load.

Weeks thirteen and fourteen are stabilization and runbook. Alert routing, error escalation paths, on-call rotation if the agency has one, workflow versioning conventions, and internal training so the ops team can build new workflows in n8n without engineering support on every step.

The questions to answer before you decide

When an agency or ops team asks us whether to migrate from Make.com to self-hosted n8n, the answer comes from four questions.

First, what is your monthly ops volume today, and what is it in 12 months? If today is under 200k and next year is under 500k, the migration is premature. If today is 800k and next year is 2M, the math has already flipped and the only question is when to start.

Second, how many of your workflows currently need custom code that lives outside Make.com (Lambda, Cloud Functions, custom endpoints)? Zero or one means Functions module is holding up. Three or more means you already have a self-hosted iPaaS in pieces and consolidating it into n8n removes real operational overhead.

Third, who owns the automation stack if it breaks at 2am? If the answer is "we open a support ticket with Make.com and wait," and that has never caused a client incident, Make.com stays reasonable. If the answer is "we cannot tolerate a support queue between us and a broken client automation," that is the strongest single reason to self-host, because n8n gives you direct access to the running system.

Fourth, what does the next 18 months of client acquisition look like? If the agency is planning to double the client roster and most new clients will want automation built as part of onboarding, the ops burn will scale faster than the revenue and the Make.com line item becomes a governor on growth. If the roster is stable, the pressure to migrate is lower.

The Make.com vs n8n conversation is not about which tool is better in absolute terms. Both are well-built, and both have profiles they serve well. It is about whether your operation has outgrown the hosted, per-ops, UI-first model that Make.com is optimized for. For agencies and ops teams sitting between 500k and 5M monthly ops with growing custom code needs and an engineering culture, a self-hosted iPaaS built on n8n is the path that compounds over three years rather than the one that keeps adding to the monthly software bill.