Make.com vs n8n

Make (the platform that was Integromat until 2022) and n8n do the same job on the surface. Both give you a canvas, a trigger, a chain of app steps and a schedule. The difference is in what you're allowed to do with the software and how you get billed for it. Make is a hosted service only, and it charges per module run. n8n publishes its source, lets you run it on any server you control and charges per workflow run only if you pick its managed cloud. Most of what follows comes back to those two facts, so this comparison spends its time on the billing mechanics and on self-hosting, then on what building a workflow feels like in each tool. Integration counts get a short section near the end because they stopped deciding anything once both platforms passed a few hundred connectors.

Pricing model: credits per module vs executions per workflow

Make bills in credits. It used to bill in operations, and on August 27, 2025 the unit was renamed and converted one to one, so an old tutorial that says "operations" is describing the same meter. A credit is consumed each time a module runs, and a module runs once for each bundle it receives. The Make help center on how credits are counted spells out that reading, searching, creating, updating, deleting, transforming, aggregating and iterating data each count, and that AI modules using Make's built-in provider are charged by tokens on top of the per-module credit. The Free plan gives you 1,000 credits a month, two active scenarios and a 15 minute minimum schedule interval. Paid plans move the interval down to one minute and remove the scenario cap.

n8n Cloud bills per execution. The pricing page defines it as "a single run of your entire workflow. It doesn't matter how many steps are in the workflow or how much data it processes." Starter gives 2,500 executions a month with 5 concurrent runs, Pro 10,000 with 20 and Business 40,000 with 30, and all of them include unlimited users and workflows. You can check current tiers on the n8n pricing page, which also lists the self-hosted Business and Enterprise plans that come with a license key.

Self-hosted n8n Community edition has no execution meter at all. You pay for the server and your own time.

A worked example shows where the two meters diverge. Take a nightly sync that pulls 500 CRM rows, runs each through six modules (fetch, filter, look up a customer, format, write to a sheet, post a summary) and finishes. In Make that's one credit for the fetch and then 500 bundles through the remaining five modules, around 2,500 credits per night and roughly 75,000 a month, which is several times the 10,000-credit entry size of the paid tiers. In n8n Cloud the same nightly job is one execution, thirty a month, so it barely registers against the Starter allowance. On a self-hosted n8n instance it costs nothing beyond the CPU time. Flip the shape and the picture changes: several dozen two-step workflows firing a combined 330 times a day come to about 10,000 executions a month, the whole Pro allowance on n8n Cloud, while on Make those runs cost around 20,000 credits, two per run, and the two meters land within a plan tier of each other. Make's meter punishes fan-out inside a scenario, while n8n Cloud's punishes lots of small runs, and a self-hosted instance has no meter at all, which is the usual reason teams end up there once a workflow starts iterating over real data volumes.

Self-hosting and where the data lives

Make has no self-hosted version. Your scenarios, execution logs and stored connections live in Make's infrastructure, and the thing they call an on-prem agent is a connector that lets a hosted scenario reach an app on your private network. The platform itself stays on Make's side. For a lot of businesses that's fine. For anyone processing customer records under a data processing agreement that names specific subprocessors, it means adding Make to that list and keeping it there.

n8n runs anywhere Docker runs. The official image is n8nio/n8n, it listens on port 5678 and it defaults to SQLite in a volume mounted at /home/node/.n8n:

docker volume create n8n_data
docker run -d --name n8n -p 5678:5678 \
  -e GENERIC_TIMEZONE="Europe/London" \
  -e TZ="Europe/London" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -e N8N_RUNNERS_ENABLED=true \
  -v n8n_data:/home/node/.n8n \
  n8nio/n8n

That gets you an instance for testing. For anything you'd call production, the two changes that matter are switching the database to Postgres with DB_TYPE=postgresdb and putting a reverse proxy with TLS in front, and the n8n install guide for Ubuntu 24.04 walks through both on a fresh server. I moved my own instance off SQLite after the executions table crossed a few hundred megabytes, and the trade-offs between the two databases are laid out in the n8n PostgreSQL vs SQLite comparison if you want the numbers. If you'd rather skip the setup entirely, the one-click n8n VPS template deploys n8n with Docker and Caddy on Ubuntu 24.04, picked during ordering, so the instance is reachable over HTTPS within a minute of the server coming up.

Self-hosting also settles the compliance question in a way a hosted service can't. The instance runs in the region you chose, the execution data sits in a database you administer and there's no third party in the processing chain. The guide to running n8n under GDPR goes through the records-of-processing side of that, and it's also why the n8n Community edition gets picked by agencies whose clients ask for an EU-only data path.

What the Community edition leaves out, per n8n's own feature table: custom variables, environments, external secrets, external storage for binary data, log streaming, multi-main mode, projects, SSO (SAML and LDAP), workflow and credential sharing and Git-based version control. Registering the instance with an email unlocks folders, debug in editor and custom execution data at no cost. Everything else on that list needs a Business or Enterprise key, and a self-hosted Business key phones n8n's license server daily to report executions, which rules out a fully air-gapped install on that tier unless n8n agrees to something different in the contract.

The n8n Sustainable Use License

n8n ships under the Sustainable Use License, which n8n calls fair-code and which is not an OSI-approved open source license. You can read the full terms in the n8n license FAQ, but the working rule is short: internal business use is allowed, and so is consulting work where you build workflows for clients. Hosting n8n and charging people to access it, or white-labeling it inside a product you sell, is not allowed without an Enterprise license. For a company automating its own operations the license is a non-issue. A SaaS founder planning to embed a workflow builder in a product should read it before anything else.

Make has no equivalent question, since there's nothing to install.

Building workflows: modules and bundles vs nodes and items

Make's canvas is the friendlier one for someone who has never automated anything. Modules are round icons in a line and a router splits the line into branches, with iterators and aggregators to unpack and repack arrays. When you run a scenario you watch bundles animate through each module with a count. The mental model is a conveyor belt. Field mapping happens in a side panel with a palette of functions, and most people can build a working three-module scenario in their first hour without reading documentation.

n8n's canvas is closer to a programming environment that happens to be visual. Nodes pass arrays of items and every field can hold an expression wrapped in double curly braces. The expression language is JavaScript, so {{ $json.email.toLowerCase() }} works exactly as a developer expects. The Code node takes a full JavaScript or Python block, sub-workflows are first class and sticky notes sit on the canvas, and the learning curve that comes with all of it is real. Ops people who would have been productive in Make on day one tend to spend their first n8n week fighting the item model.

If the people maintaining the automations write code for a living, n8n, because the expression language and the Code node mean you never hit a wall the UI can't get past. If the maintainers are in marketing or sales ops, Make's editor is the one they'll keep using after the person who set it up leaves.

Error handling and debugging

Make handles errors per module. You attach an error handler route to any module and choose a directive for what happens next, and a failed run can be parked as an incomplete execution to retry later once the upstream problem is fixed. The execution history shows every bundle that went through every module, so finding the one bad record is quick.

n8n gives each node a retry-on-fail setting with a wait between attempts and a continue-on-error option that routes the failure down a separate output, plus an Error Trigger node that starts a dedicated error workflow for every workflow you point at it in the workflow settings. Execution logs keep the input and output of every node, and you can pin a node's output while editing so downstream nodes run against real data without re-calling the API. The one operational job n8n adds when self-hosted is retention: the executions table grows until you prune it, and the execution pruning settings are worth setting on day one so the database doesn't turn into the biggest thing on the disk.

AI agents and LLM steps

Both platforms ship agent builders now. Make's AI Agents run inside Make and, when you use Make's own AI provider, bill credits by token as well as by module. Bring your own OpenAI or Anthropic key and Make charges the module credits while the provider bills the tokens separately.

n8n's AI Agent node and its LangChain-based node family run wherever the instance runs, which on a self-hosted server means the agent can call a local Ollama model on the same box or over a private network and the prompt data never leaves. That setup is covered in the tutorial on n8n AI integration on a VPS. For a chatbot over internal documents, the local route is the only one that keeps the documents internal.

Integrations and community

Make lists over 3,000 apps. n8n lists over 500 integrations plus more than 10,000 published workflow templates, and the gap matters less than it looks because n8n's HTTP Request node covers any REST API with a few fields, and community nodes install from npm for the rest. If a niche SaaS has a Make module and no n8n node, you'll spend twenty minutes reading its API docs on the n8n side. The n8n repository sits above 200,000 GitHub stars, which says more about the size of the community answering forum questions than about the software.

Scaling and concurrency

On Make you don't scale anything. Concurrency and throughput come with the plan tier, and if a scenario needs more you buy more.

n8n Cloud caps concurrent executions per plan (5, 20 and 30 on the three listed tiers). Self-hosted n8n scales horizontally in queue mode, where a main process hands executions to worker containers through Redis and you add workers as load grows. The setup is documented in the guide to n8n queue mode with Redis workers. Multi-main, the mode where more than one main process shares the load, is an Enterprise feature, so a Community instance keeps a single main and scales the workers behind it.

Comparison table

Which one to pick

Make fits a team where nobody wants to run a server, the automations are short glue between SaaS tools and the monthly credit count stays predictable. n8n Cloud fits the same team once the workflows start iterating over large batches, since one execution covers the whole batch. Self-hosted n8n is the answer when data residency is a hard requirement or the execution count would push either hosted plan into a higher tier, and it's the natural home for a team that writes code and would rather have the Code node than a function palette. Self-hosting does put backups on your plate, and the n8n backup and disaster recovery guide covers the encryption key, the database, the workflow exports and the compose file that need to be in the backup set.

I haven't run Make's on-prem agent against a database behind a flaky VPN, so how it behaves when the tunnel drops mid-scenario is something to test on the Free plan before committing if that's your setup.

There's also a wider field than these two. Zapier, Windmill, Activepieces and Node-RED each solve a different slice of the same problem, and the roundup of n8n alternatives goes through what each one charges and which ones you can host yourself.