Most n8n versus Make comparisons stop at node counts and interface screenshots. For a two- or three-person cross-border team, the question that actually decides the outcome is different: when this automation breaks, who fixes it?
The short version: if nobody can reliably own a server and its upgrades, use a managed option (Make, or n8n's own cloud); if you have a genuine data-residency requirement, stable high volume, and someone who can maintain it, then consider self-hosting n8n. The subscription fee you save comes back as ops time.
How they're positioned
| Decision point | n8n | Make |
|---|---|---|
| Deployment | Cloud or self-hosted | Cloud only |
| Community edition | Free community edition available when self-hosting, with most features | No self-hosted form |
| Paid capabilities | SSO, environments, projects, workflow sharing, external storage and Git-based version control sit in paid plans | Capabilities and volume vary by plan |
| Billing model | Varies by plan and deployment | Metered on credits (formerly operations; one credit per operation for non-AI apps) |
| Who it suits | Teams with maintenance capacity or data-location requirements | Teams who want it working today and don't want infrastructure |
n8n's own documentation notes that feature availability changes over time and differs by plan and edition, with the pricing page as the authority. This article deliberately quotes no prices: they move quickly, so check both vendors before committing.
What self-hosting really saves, and really costs
Saves: subscription fees, pressure from per-operation billing, and the ability to keep data inside your own environment.
Costs:
- Deployment and upgrades. Versions, dependencies, database backups, certificate renewals;
- Availability. If the service dies and nobody is alerted, abandoned-cart emails and order notifications stop silently;
- Debugging. You're both the user and the operator when something fails;
- Access and security. Who can edit workflows, where credentials live, whether logs contain customer data.
Convert those into hours per month and compare against the subscription. Most small teams find that unless there's a real compliance requirement, managed wins.
Three questions that decide it
1. Can the data leave your environment?
If workflows touch customer addresses, identity documents, payment data or health-related information, and your obligations restrict where that data sits, self-hosting earns its keep. If the workflow is "post new orders to Slack", standing up a server for it isn't reasonable.
2. Is volume stable and high?
Make meters usage in credits (one credit per operation for non-AI apps), so dense workflows and frequent polling make cost growth visible. Self-hosting's fixed cost only becomes attractive when monthly operation counts have settled at a high level and the workflows have stopped changing weekly. While you're still editing them daily, iteration speed matters more.
3. Is there a second person who can maintain it?
If only one person understands the system, a holiday is an outage. Before self-hosting, ask: where are the docs, how is a backup restored, who receives the alert. No answers means managed, for now.
A two-week trial
Pick one low-risk but real workflow ("new order → check first-time buyer → write to a sheet → notify the owner"):
- build it in both, recording how long the build took;
- deliberately cause three failures (API timeout, missing field, expired auth) and record how long until you noticed and how long until it was fixed;
- have a non-technical colleague try to change one branch condition;
- log a month of actual runs for cost estimation;
- for the self-hosted option, additionally record how long an upgrade takes and whether a backup restore has ever been tested.
Step 2 is the revealing one. Automation is only worth it unattended, and unattended only works if failures reach a human.
Before any workflow runs unattended: a failure checklist
Whichever tool you pick, this list matters more than the choice itself:
- every workflow has a named owner and a one-paragraph description of what it does;
- failed runs send an alert to a channel a person actually reads, not only to a log;
- credentials sit in the tool's credential store rather than pasted into steps, and you know which accounts they belong to;
- there's a note on what to do by hand if the workflow is down for a day (who sends the order notifications, who checks the sheet);
- logs and run history have been checked for customer data you didn't mean to keep;
- for self-hosting: backups run on a schedule, a restore has been tested at least once, and someone receives upgrade and certificate warnings.
If you can't tick these for one workflow, adding more workflows only adds more ways to fail silently.
A prompt for writing a runbook a second person can follow
Question 3 above usually fails on documentation, not skill. AI can turn your description of a workflow into a first-draft runbook, which the person who built it then corrects.
Write a one-page runbook for the automation below, for a colleague who didn't build it and isn't technical.
Sections:
1. What it does, in two sentences
2. What triggers it and how often
3. Which accounts and credentials it uses (names only, never the secrets)
4. How you'll know it has failed
5. The three most likely failures and what to check first for each
6. What to do by hand if it's down
7. Who to contact
Use only the details I give you. Where something is missing, write "TO FILL IN" instead of guessing.
Tool: [MAKE / N8N CLOUD / SELF-HOSTED N8N]
Workflow steps, in order: [STEPS]
Owner: [NAME]
Alerts go to: [CHANNEL OR EMAIL]The "TO FILL IN" gaps are the point: each one is something nobody would have known during an outage.
Worked example: scoring the trial for a fictional team
Take a fictional three-person store, "Harbour & Pine", selling kitchen textiles to EU customers, as an example. They run the first-time-buyer workflow from the trial above in Make and in a self-hosted n8n instance.
Input: the trial notes. Both builds worked. In the failure step, the alert they had set up in the managed build reached the owner the same day; on the self-hosted instance nobody had configured an alert yet, so the expired-auth failure was only spotted the next morning. The non-technical colleague changed a branch condition in both, with some help. Nobody had tested a backup restore.
What the AI returns (given the notes and the runbook prompt): a runbook for each version, with "TO FILL IN" under backup restore and upgrade owner for n8n.
What a person changes: the team decides the gaps are the answer. Their workflows touch customer addresses but they have no data-residency obligation that rules out a managed service, and only one person could own a server. They stay managed for three months, as in "Making the call" below, and log monthly operation counts so the self-hosting question can be revisited with real numbers.
Common mistakes when choosing between n8n and Make
- Comparing on node counts or integration lists. Neither tells you who fixes it at 11pm.
- Self-hosting to save money without pricing the hours. Put upgrades, backups and debugging into the monthly sum before deciding.
- Skipping the failure test. A trial where everything worked tells you little about running unattended.
- Automating while the process still changes every week. Settle the steps by hand first, then build.
- Assuming every edition has the same features. Check the vendor's current plan and edition pages for anything you depend on, such as SSO or version control.
FAQ
Can I start on Make and move to n8n later? You can, but plan for it as a rebuild rather than a migration. Keep each workflow's runbook and step list current, and the rebuild becomes a matter of recreating known steps instead of reverse-engineering them.
Is n8n cloud the same as self-hosting n8n? No. On n8n's cloud the vendor runs the service, so most of the self-hosting costs listed above move off your plate. The data-boundary point changes too, because the data no longer sits only in your environment. Check plan details with n8n directly.
Does self-hosting n8n make my data handling compliant? No. It controls where the data sits, which matters for some obligations, but access, logging, credentials and retention are still yours to get right. If you have a genuine requirement, have it confirmed by whoever advises you on it.
What's the smallest team where self-hosting makes sense? There's no headcount rule. Question 3 is the useful test: at least two people who can restore a backup, apply an upgrade and act on an alert. Without that, team size doesn't change the answer.
Making the call
- No ops capacity, workflows still changing often → managed (Make or n8n cloud);
- Data-residency requirement, stable workflows, a maintainer → self-hosted n8n;
- In between → run managed for three months, then re-evaluate once volume and cost are measurable.
To work out what you should be automating first, see the workflow breakdown in Zapier vs Make for a two-person ecommerce team. For the wider stack, see how to build an AI tool stack for cross-border ecommerce. Tool pages: Make, Zapier.
Sources checked 2026-08-28: n8n deployment options. Plans, capability boundaries and billing models change; check each vendor's current documentation before choosing.
