Unit economics, hosting and security and compliance, embedding and client work, migration and lock-in, and the decision framework itself.
A Signal Through field guide. Independent and vendor-neutral; not affiliated with n8n GmbH, Celonis (Make), or Zapier Inc. Approximately 23454 words.
In this volume:
Chapter 3 (Mental Models: How a Run Actually Happens) planted a claim that this chapter now has to pay off: the single most consequential difference between Zapier, Make, and n8n is not any feature — it is the unit each platform sells you. Zapier sells tasks, Make sells operations, and n8n sells executions. Those three words sound interchangeable. They are not. The same workflow, processing the same data, can consume wildly different quantities of billing units on each platform, and the gap widens as your volume grows. A design that is cheap on one platform can be ruinously expensive on another, and vice versa — not because any vendor is gouging you, but because each unit measures a different dimension of the work.
This is the compendium's only pricing chapter, so it goes all the way down: precise definitions of each unit, what each platform gives away free, what happens when you exhaust an allowance, how AI steps get billed on a second meter, the classic traps that inflate bills silently, and — because vendor prices change faster than books do — three real workflows costed in units at three realistic volumes, so you can multiply by whatever the per-unit price is on the day you read this.
One accuracy note before we start. Counting rules are structural: they follow from how each engine executes a run, and they change rarely. Dollar prices, plan names, and allowance sizes change often. This chapter is precise about the former and deliberately qualitative about the latter. Before you commit real money, spend ten minutes on each vendor's current pricing page with the worksheet at the end of this chapter in hand.
A task is one action step that completes successfully, counted once for each item it processes. That definition has three load-bearing words.
Action: only steps that do something count. The trigger —
the step that starts a Zap (Zapier's name for a workflow) — is free, no
matter how often it fires. Zapier's built-in logic steps are also free:
Filter steps (which halt a run unless a condition is met),
Paths steps (branching — see Chapter 16), and, under
current rules, Formatter steps (Zapier's built-in
data-reshaping utility). Zapier's framing is that you pay for actions
sent to other apps, not for the routing and prep work in between.
Successfully: a step that errors does not bill. Neither do steps that never run because an earlier filter stopped the Zap or an earlier step failed. If a five-action Zap dies at step two, you are charged for one completed action, not five.
Each item: when a Zap loops (via Looping by Zapier) or fires once per record, every action inside the loop bills once per iteration. Ten records through a loop containing two actions is twenty tasks, plus the loop step itself. Sub-Zaps — Zapier's reusable callable workflows, covered in Chapter 18 (Modularity and Reuse) — bill fully: the call itself and every action inside the sub-Zap consume tasks, so extracting shared logic into a sub-Zap adds a small per-run surcharge rather than saving units.
One subtle rule worth memorizing: replaying a Zap run (re-running it from history after fixing a problem) re-bills every step that runs again, including steps that already succeeded and billed the first time.
An operation is one execution of one module, counted once per bundle. In Make's vocabulary (Chapter 11, Three Data Models), a module is a single block in a scenario — a trigger, an action, a search — and a bundle is one packet of data flowing through it. If a search module returns 50 bundles, the search itself is one operation, but every downstream module that processes those bundles runs 50 times and bills 50 operations.
The parts Make gives away: filters (the conditions you place on the line between two modules) and the router block itself (the branching mechanism) do not consume operations. The modules on each route do.
The part Make charges for that surprises everyone: the trigger check itself is an operation, including checks that find nothing. If a scenario polls a mailbox every 15 minutes and the mailbox is empty all night, each of those empty checks still consumed an operation, because the trigger module executed. This single rule is the source of the most common billing surprise on the platform, and we will quantify it in Workflow C below.
Two smaller rules that matter at scale: an iterator (which splits an array into individual bundles — Chapter 13) is itself an operation, and everything downstream of it multiplies per bundle; an aggregator (which merges bundles back into one) collapses that multiplication, which is why iterate-early/aggregate-early is Make's fundamental cost-optimization move. When a scenario errors partway through, the operations already consumed stay consumed.
An execution is one top-level run of one workflow, from trigger to finish — regardless of how many nodes it contains, how many items flow through it, or how long it takes. A 3-node workflow and a 60-node workflow each cost exactly one execution per run. A run that processes one item and a run that processes ten thousand items each cost one execution.
Two consequential refinements. First, a call to a sub-workflow (Chapter 18) generally bills as its own execution: a parent that fans out into five sub-workflow calls consumes six executions, not one. Rules like this get revised, so verify the current policy before you architect around heavy fan-out. Second, a polling trigger node that checks and finds nothing does not start a run at all, so idle polling is free — the opposite of Make's rule. But that is a property of native polling trigger nodes; if you hand-roll the same poll as a Schedule Trigger followed by a fetch step, every check is a full billed execution, empty or not.
The other thing to know about n8n is that the meter is optional. n8n Cloud (the hosted product) bills per execution; self-hosted n8n — the community edition you run on your own server, covered in Chapter 32 (Hosting, Security, and Compliance) — has no execution metering at all. Your costs are the server, your time, and nothing per run. That makes n8n the only one of the three whose marginal cost per run can be driven to effectively zero, which reshapes every calculation in this chapter for high-volume shops willing to operate their own infrastructure.
| Zapier task | Make operation | n8n execution | |
|---|---|---|---|
| What bills | One successful action step, per item | One module execution, per bundle | One top-level workflow run |
| Trigger fires | Free | One operation per check — even empty checks | Free to check; a run only starts when there is data |
| Filters / branching logic | Free (Filter, Paths, Formatter) | Free (filters, router block) | Free (nodes don't bill individually) |
| Loop over N items | N tasks per action inside the loop | N operations per module after the iterator | Still one execution |
| Reusable sub-flows | Call + inner actions all bill | Called scenario's modules all bill | Each sub-workflow call generally bills as its own execution |
| Failed runs | Errored and never-run steps don't bill; replays re-bill | Operations consumed before the error stay consumed | Check current policy on failed and re-run executions |
| Cost scales with | Workflow depth × item count | Module count × bundle count × schedule frequency | Run count — and nothing else |
Read the bottom row twice. It is the whole chapter in one line: Zapier charges for depth, Make charges for volume and frequency, n8n charges for run count. Every trap and every arbitrage in the rest of this chapter is a corollary.
Each vendor's tiers bundle the unit allowance with feature gates, and the gates sometimes matter more than the units.
On Zapier, higher tiers unlock larger task allowances, faster polling intervals (how often Zapier checks apps that can't push instantly — Chapter 8), access to "premium" apps that are fenced off from lower tiers, longer history retention, and team features. Zapier has long offered a free tier with a small task allowance; its exact constraints have shifted repeatedly over the years, so verify what a free Zap may contain today rather than trusting any book, this one included.
On Make, tiers gate the monthly operation allowance, the minimum scheduling interval (free plans can only poll infrequently; paid plans can schedule down to about a minute), the number of active scenarios on some tiers, execution priority in busy periods, and team/organization features. Make's free tier is genuinely usable for learning — a small monthly operation allowance and the full editor.
On n8n Cloud, tiers gate the execution allowance, the number of active (switched-on) workflows, concurrency (how many executions may run simultaneously — Chapter 30), log retention, and collaboration features like projects and role-based access. At the time of writing n8n Cloud offers a time-limited trial rather than a perpetual free tier; the perpetually free option is self-hosting the community edition.
Tip: When comparing tiers, price the feature cliff, not just the unit allowance. Needing one premium app on Zapier, one-minute scheduling on Make, or higher concurrency on n8n can force a tier jump that dwarfs your unit consumption. Chapter 4 (The Rosetta Stone) has the capability map; check it against your app list before you anchor on a cheap tier.
The three platforms answer "what happens at 100% of allowance?" differently, and the difference determines whether an unexpectedly busy month costs you money or costs you missed runs.
Zapier fails open, then closed. On paid plans, when you exhaust your task allowance, Zaps keep running and additional tasks bill at a premium per-task rate — up to a ceiling (a multiple of your plan's allowance), after which further runs are held until the next billing cycle. You trade budget surprise for continuity.
Make fails closed, unless you opt out. When operations run out, scenarios stop running. You can buy additional operation packs, and there is a setting to purchase extras automatically when you run low — effectively choosing fail-open behavior in the workspace's subscription settings. If you never flip that switch, a viral day silently pauses your automations.
n8n Cloud sits between: expect warnings and upgrade prompts as you approach the allowance rather than a hard mid-month wall, but treat the current policy as something to verify, not assume — and remember that self-hosted n8n has no wall at all.
Watch out: "Fail open" and "fail closed" are both dangerous in the wrong context. A billing-sensitive side project wants fail-closed (a bug that loops forever should stop, not bill forever). A revenue workflow — order fulfillment, lead response — wants fail-open (a busy month should cost more, not drop customers). Decide which posture each workflow needs before the month that tests it, and set up usage alerts either way; Chapter 27 (Monitoring, History, and Alerting) shows how.
Allowances on all three platforms reset monthly and, as a general rule, unused units do not roll over — another thing worth a ten-second verification on current terms before you pick a tier size.
Now the arithmetic. Three real workflows — the kinds of builds this compendium's worked projects use — costed in billing units at three realistic volumes. Units, not dollars: multiply the totals by the current per-unit price of whatever tier you are eyeing, and the comparison stays valid no matter how the price lists drift.
The Chapter 36 shape: a form submission arrives by instant trigger (a webhook — Chapter 9), a filter drops obvious spam, then three actions run: upsert the contact into a CRM, post a Slack notification, send a welcome email.
Per lead: Zapier bills the three actions (trigger and filter free) = 3 tasks. Make bills the webhook trigger plus three modules (filter free) = 4 operations. n8n bills the run = 1 execution.
| Monthly leads | Zapier tasks | Make operations | n8n executions |
|---|---|---|---|
| 100 | 300 | 400 | 100 |
| 1,000 | 3,000 | 4,000 | 1,000 |
| 10,000 | 30,000 | 40,000 | 10,000 |
The ratios are fixed by structure: 3 : 4 : 1. Every step you add to make the workflow nicer — a lead-scoring lookup, a second notification, an enrichment call — raises Zapier and Make's column by one unit per lead forever, and changes n8n's column not at all. At 100 leads a month, nobody cares. At 10,000, the platforms have diverged into different tier brackets.
A scheduled job, 30 runs a month: every night, fetch the day's updated rows from a source system, upsert each row into a database, then post one summary message. This is the shape that Chapter 13 (Lists, Loops, and Aggregation) teaches; here is what it costs.
Per night with N rows: Zapier — the schedule trigger is free; a fetch action (1 task), a Looping by Zapier step (1 task), one upsert action per row (N tasks), one summary message (1 task) ≈ N + 3 tasks. Make — the scheduled search is 1 operation, the upsert module runs per bundle (N operations), an aggregator (1) and the summary message (1) ≈ N + 3 operations. n8n — the whole night is 1 execution, whether N is 50 or 5,000.
| Rows per night | Zapier tasks / month | Make operations / month | n8n executions / month |
|---|---|---|---|
| 50 | ~1,590 | ~1,590 | 30 |
| 500 | ~15,090 | ~15,090 | 30 |
| 5,000 | ~150,090 | ~150,090 | 30 |
This is where the pricing models diverge dramatically rather than proportionally. Zapier and Make track each other almost exactly here — both are per-item models once a loop is involved — while n8n's column does not move, because item count is invisible to per-run billing. A 100× increase in data volume is a 100× increase in units on two platforms and a 0× increase on the third.
Two honest footnotes. First, Zapier caps how many iterations a single loop may run (and truly bulk moves belong in purpose-built transfer tooling with its own billing), so the 5,000-row night needs restructuring on Zapier regardless of cost. Second, some Zapier actions accept line items — a whole list handed to one action — and when the destination app supports that, the loop disappears and so does most of the bill; Chapter 12 (Mapping and Transforming Fields) covers when that is possible.
Tip: On per-item platforms, the cheapest loop is the one you delete. Before accepting an N-per-run bill, check for a native bulk or line-item variant of the action, an aggregator that lets one module handle the whole batch, or an API endpoint that accepts arrays via a raw HTTP step (Chapter 9). One module processing 500 rows as a single payload is one operation, not 500.
The Chapter 37 shape, simplified: watch a shared inbox; for each new email, an AI step (Chapter 21) classifies it; urgent messages branch to two actions (create a ticket, alert Slack), routine ones to one (apply a label). Assume 20% urgent, so the average run is the classify step plus 1.2 branch actions. The inbox trigger polls every 15 minutes where polling applies — roughly 2,880 checks a month.
Per email: Zapier ≈ 2.2 tasks (classify + branch actions; trigger, paths free — and polling itself is free). Make ≈ 2.2 operations (classify + average 1.2 branch modules; router free) plus a flat polling baseline: the trigger check bills one operation per cycle whether it finds zero emails or ten, so a 15-minute schedule costs ~2,880 trigger operations a month before any email is processed. n8n = 1 execution per email found; empty polls start no run — assuming a native polling trigger node, per the caveat above (a hand-rolled schedule-and-fetch version would bill all ~2,880 checks as executions).
| Monthly emails | Zapier tasks | Make operations | n8n executions |
|---|---|---|---|
| 300 | ~660 | ~660 + 2,880 baseline ≈ 3,540 | 300 |
| 3,000 | ~6,600 | ~6,600 + 2,880 ≈ 9,480 | 3,000 |
| 30,000 | ~66,000 | ~66,000 + 2,880 ≈ 68,880 | 30,000 |
Look at the low-volume row. At 300 emails a month, roughly four-fifths of the Make bill is the polling baseline — operations consumed watching an inbox where, most of the time, nothing had happened. The fix is architectural, not financial: switch to an instant trigger (the mailbox's push notification or a webhook) and the baseline vanishes; or stretch the polling interval and shrink it. Chapter 8 (Triggers) is the full treatment.
And a second meter is running in this workflow that none of these columns show: the AI step's token bill. Hold that thought for one section.
Strip the tables to their logic and you get four rules:
The most useful normalization is cost per business outcome: units per lead handled, per row synced, per email triaged. Workflow A costs 3 tasks, 4 operations, or 1 execution per lead. Workflow B costs about 1 task, 1 operation, or 0.006–0.6 executions per row depending on volume. That is the number to multiply by per-unit price and compare — it survives repricing, and it exposes structural mismatches that headline plan prices hide.
Chapter 25 (Trust, Cost, and Control) covers AI cost governance in depth; here is the billing mechanics summary. An AI step inside a workflow usually runs two meters at once: the platform's normal unit (a task, an operation, an execution as usual) and the model provider's token bill — tokens being the word-fragments language models charge by, proportional to how much text goes in and comes out.
Where the second meter lands depends on wiring. If you bring your own API key — connecting your own OpenAI or Anthropic account to the AI step — the token bill arrives on your provider invoice, separate from the automation platform entirely. If you use the platform's built-in AI offerings, the model cost is wrapped into platform currency instead: some AI features draw from your normal allowance, others from a separate credit pool. Zapier's agent products (Chapter 23), notably, meter on their own activity quota rather than on tasks. Make and n8n both lean toward bring-your-own-key for model calls, with platform units billed as normal for the step itself.
The planning consequence: token costs scale with content length and model choice, not with run count, so they can dwarf platform units without moving any dashboard you are watching. Classifying a two-line email with a small model costs a fraction of summarizing a 40-page document with a frontier one — same single task, operation, or execution either way.
Watch out: Budget AI workflows on both meters from day one. A triage workflow that is comfortably inside its platform allowance can still triple your total automation spend via the provider invoice. Put a spending cap or alert on the model provider account itself — the automation platform's usage screen will never warn you about a bill it doesn't send.
Every one of these appears in real bills constantly. All are avoidable at design time and annoying to fix after.
Covered in Workflow C, generalized here: on Make, every scheduled check bills whether or not there is data, so an aggressive interval on a quiet source is a standing monthly charge for nothing. Audit every polling trigger: can it be an instant/webhook trigger instead? If not, what is the slowest interval the business actually tolerates? Halving frequency halves the idle cost. On Zapier polling is free but interval is tier-gated; on n8n idle polls are free with native polling trigger nodes, while hand-rolled schedule-and-fetch constructions bill every check as an execution. Chapter 17 (Waiting, Scheduling Windows, and Throttling) covers interval design.
An iterator or loop turns every downstream step into a per-item charge. The multiplication is silent — the editor shows five neat steps; the bill shows five × N. Defenses: aggregate as early as possible, use line-item or bulk actions where they exist, push array handling into a single code or HTTP step (Chapter 10), and put filters before the loop so excluded items never enter it. On n8n, loops are billing-neutral — which is exactly why item-heavy work is the strongest structural argument for per-run pricing.
On task and operation platforms, good hygiene has a price tag: every logging step, every safety lookup, every "also notify" convenience is a permanent per-event surcharge, which quietly pressures you toward thinner, more fragile workflows. On per-run platforms the pressure inverts: steps are free, so workflows grow luxuriant, but splitting logic into many small top-level workflows multiplies executions. Know which direction your platform pushes and lean against it deliberately.
Failure economics differ. On Zapier, errored and never-run steps don't bill — but replaying a run re-bills every step that executes again, including previously successful ones, so bulk-replaying a thousand failed runs is a real purchase. On Make, operations consumed before a crash stay consumed, so a scenario that reliably fails at step 8 of 10 still bills ~80% of a successful run each attempt — a retry loop against a broken credential (Chapter 7) burns allowance at nearly full speed while accomplishing nothing. Configure retry limits and error routes (Chapter 19) with the meter in mind, and check each platform's current policy on whether failed runs, automatic retries, and editor test runs count.
Watch out: The most expensive failure mode on any per-item platform is the infinite feedback loop: workflow A updates a record, which triggers workflow B, which updates the record, which triggers A. On task or operation billing this burns allowance at machine speed until something halts it. Loop-guard patterns — marker fields, self-trigger filters — are in Chapter 39 (The Troubleshooting Encyclopedia).
Building and debugging consume units too: manual scenario runs on Make bill their operations, test invocations may or may not bill depending on platform and step type, and a debugging afternoon of thirty test runs on an item-heavy workflow can eat a visible slice of a small allowance. Test against small fixture datasets, not the production backlog, and check whether your platform exempts editor test runs before assuming either way. Chapter 26 (Testing, Debugging, and Launch) covers cheap test design.
Fill this in before choosing a platform or a tier. It takes half an hour and routinely changes the decision.
Step 1 — inventory. List every workflow you plan to run in the next six months. For each, record: trigger type (instant or polling), runs per month (use the busiest realistic month, not the average), average items per run, and the number of real action steps (exclude filters and branching).
Step 2 — count units per workflow.
Step 3 — tabulate.
| Workflow | Runs/mo | Items/run | Action steps | Zapier tasks | Make ops | n8n execs |
|---|---|---|---|---|---|---|
| _____________ | _____ | _____ | _____ | _____ | _____ | _____ |
| _____________ | _____ | _____ | _____ | _____ | _____ | _____ |
| _____________ | _____ | _____ | _____ | _____ | _____ | _____ |
| Totals | _____ | _____ | _____ |
Step 4 — add headroom. Multiply each total by 1.5. Growth, retries, replays, and testing all consume units the inventory doesn't show, and you never want to live at 95% of an allowance.
Step 5 — price it. Open each vendor's current pricing page. Find the cheapest tier whose allowance covers your headroom number and whose feature gates pass (premium apps, polling interval, concurrency, team features — Step 1 of Chapter 35's framework). Note the overage policy next to each price: what happens in a month at 2× volume?
Step 6 — add the second meter. For each AI step: runs × average tokens per run × the model's current per-token price, on whichever invoice it lands. Add it to the total; it is real money even though it never appears on the automation platform's tier page.
Step 7 — sanity-check per outcome. Divide each platform's projected monthly cost by monthly business outcomes (leads, orders, tickets). If automation costs a meaningful fraction of what an outcome is worth, revisit the design — usually a loop to collapse, a poll to slow down, or a platform mismatch this chapter's tables will make obvious.
Tip: Re-run this worksheet whenever a workflow's volume changes by an order of magnitude. The platform that was right at 100 events a month is frequently wrong at 10,000 — and Chapter 34 (Migration, Coexistence, and Lock-In) exists precisely because unit economics are the most common reason teams move.
Where does this leave the decision? Task billing buys you the least surprising bill for shallow, low-volume workflows and the industry's broadest catalog behind it. Operation billing is granular and cheap per unit but demands discipline about loops and polling. Per-run billing is structurally unbeatable for deep, item-heavy work — with self-hosting as its zero-marginal-cost endgame — and structurally indifferent for trivial ones. None of that is a verdict; it is one axis of several. Chapter 35 (The Decision Framework) weighs it against capability fit, governance, and hosting to produce an actual recommendation. Bring your filled-in worksheet.
Somewhere in your organization there is a person whose job is to ask one question about every new tool: "Where does our data go?" This chapter exists so you can answer them precisely — and so that, if you are that person, you can evaluate n8n, Make, and Zapier without wading through three vendors' trust-center marketing.
The short version: Zapier and Make are software-as-a-service (SaaS) products — you use them in the vendor's cloud or not at all. n8n offers a hosted cloud service too, but it is also self-hostable: you can download it and run it on your own servers, inside your own network, under your own lock and key. That single structural difference drives most of what follows. It determines where data lives, which compliance regimes are reachable, which systems your workflows can even see, and who carries the operational burden.
This is the buying view. The day-to-day mechanics of running a team on these platforms — roles, permissions, folders, approval flows — live in Chapter 29 (Teams, Governance, and Change Management). Here we care about the questions you must answer before you sign anything.
Start with a fact that surprises many first-time buyers: a workflow platform does not just orchestrate your data — it handles it. When a workflow copies a new CRM contact into a spreadsheet, the contact's name, email, and phone number physically pass through the platform's servers. The platform receives the record from one app, holds it in memory (and usually writes it to an execution log — the stored record of what a run did, kept so you can debug it later), transforms it, and hands it to the next app.
So there are really three data questions hiding inside "where does our data go":
On a SaaS platform, the answer to all three is "the vendor's cloud." That is not automatically a problem — the same is true of your CRM, your email provider, and probably your file storage. But it means the platform joins the list of processors your privacy and security reviews must cover, and for some organizations — hospitals, banks, defense contractors, European public bodies — that list is governed by rules with teeth.
Tip: Retention is the most commonly overlooked of the three. Even if live processing is acceptable, execution logs can quietly accumulate months of customer records inside the platform. All three products let you influence log retention — n8n most completely, since on a self-hosted instance the logs sit in a database you own. Ask about retention controls explicitly during evaluation; Chapter 27 (Monitoring, History, and Alerting) covers what the logs contain.
Zapier runs exclusively as a cloud service on infrastructure in the United States. There is no self-hosted version and no option to choose another region. Every Zap you build executes in Zapier's cloud, and every piece of data it touches transits US-based servers. For most US businesses this is a non-event. For organizations with strict data-residency obligations (more on that term below), it is the first fork in the road: if payload data legally cannot leave a particular jurisdiction that isn't the US, Zapier is out of scope regardless of its other merits.
Make is also SaaS-only — no self-hosting — but it operates in multiple hosting zones, including European Union and United States regions. When an account is created it is placed in a zone, and that zone determines where scenarios execute and where data is processed. You can see which zone you're in by looking at the domain you log into: the zone name appears in the URL of the Make web app. Make began life as a European company (its origins are in Prague), and its EU hosting is first-class rather than an afterthought, which has historically made it the pragmatic SaaS choice for European teams with GDPR-driven preferences for EU processing.
Watch out: A Make account's zone is a property of the account, not a per-workflow setting. If your organization signed up years ago in one zone and now needs the other, moving is a migration project, not a toggle. Check the zone before you build, and confirm current transfer options with Make if you inherit an account in the wrong region.
n8n gives you both postures. n8n Cloud is the company's managed SaaS offering, hosted in the European Union (Frankfurt, Germany, at the time of writing) — worth noting because it inverts the usual pattern: the default SaaS home is Europe, not the US. Self-hosted n8n is the same product running wherever you choose to run it: a virtual machine at any cloud provider in any region, a server in your office, a Docker container (a lightweight, portable way to package and run software) on hardware in a data center you control, even a laptop. When you self-host, n8n-the-company never sees your workflow data at all. There is no "phone home" of your payloads; the processing, the logs, and the credentials all live inside your infrastructure.
| Question | Zapier | Make | n8n |
|---|---|---|---|
| Self-hostable? | No | No | Yes (core product) |
| Vendor-hosted option? | Yes (only option) | Yes (only option) | Yes (n8n Cloud) |
| Region choice on the vendor's cloud? | No — US | Yes — EU and US zones | Cloud is EU-hosted; region choice comes from self-hosting |
| Can payload data stay entirely inside your network? | No | No | Yes, when self-hosted |
| Who patches and backs up the platform? | Zapier | Make | The vendor (Cloud) or you (self-hosted) |
If n8n's self-hostability is on your shortlist, you will meet its license, and it deserves a plain-English explanation because it is not a standard open-source license and the difference occasionally matters commercially.
n8n describes itself as fair-code: the source code is publicly available and you can read, run, and modify it, but the license restricts certain commercial uses. The Open Source Initiative's definition of "open source" forbids restrictions on use, so n8n — accurately and to its credit — does not call itself open source. The license in question is the Sustainable Use License, and it is deliberately short and written in ordinary language. Its practical effect:
What you can do, free of charge:
What you cannot do without a commercial license:
Why a buyer should care even if none of that applies: two reasons. First, some corporate open-source policies whitelist only OSI-approved licenses; a fair-code license may need a one-off review by legal, which is usually quick but should be scheduled, not discovered. Second, the license is the mechanism that keeps free self-hosting sustainable for the vendor — understanding it tells you the free tier is a deliberate strategy, not a loophole that might close abruptly. Note also that some of n8n's advanced features (single sign-on, external secrets storage, log streaming, and similar) are not in the free self-hosted edition at all; they are paid enterprise features layered on top, whichever way you host.
Tip: The one-sentence test for whether the free license covers you: are you using n8n to run your business, or selling n8n as the business? The first is free. The second needs a conversation with n8n.
It is tempting to file self-hosting under "compliance checkbox," but its most underrated consequence is architectural: a self-hosted instance sits inside your network, so it can reach things the public internet cannot.
Every SaaS automation platform calls your systems from the outside. If the system is a public cloud app with a public API (an application programming interface — the doorway one program offers another), that's fine. But many valuable systems are not public: the Postgres database behind your firewall, the inventory service on the warehouse LAN, the legacy ERP (enterprise resource-planning system) that IT will not expose to the internet under any circumstances. For a SaaS platform to touch those, someone must open a door — a VPN, a tunnel, an allowlisted static IP address, or an agent installed inside the network — and every opened door is a negotiation with your security team and a new thing to maintain.
A self-hosted n8n instance needs no door, because it is already inside. A workflow can query the internal database directly, call the internal API by its private address, and read the file share, using the connector and code-step techniques covered in Chapter 10 (When the Catalog Falls Short: Custom Connectors and Code Steps) and the raw-HTTP patterns from Chapter 9 (Webhooks and Raw HTTP). For organizations whose most automatable systems live behind the firewall, this is not a compliance nicety — it is the difference between "possible" and "not possible."
Self-hosting also buys you:
And it bills you in kind:
Watch out: "We'll self-host, so security is handled" is the most dangerous sentence in this chapter. A SaaS vendor employs a security team whose entire job is protecting the platform; when you self-host, that job transfers to whoever set up the server — which, in small teams, is often nobody in particular. If you cannot name the person who will apply next month's security update, price in managed hosting or reconsider the SaaS route.
Data residency means the requirement that certain data be stored or processed only within a specific geographic or legal jurisdiction. It shows up in EU data-protection practice, in national rules for government and health data, in banking regulation, and increasingly in customer contracts ("supplier shall process personal data only within the EEA," meaning the European Economic Area).
The three platforms' honest answers:
One nuance keeps consultants employed: residency applies to the platform's processing, but your workflow's endpoints matter too. An EU-resident Make scenario that pushes data into a US-hosted SaaS app has still transferred the data — via the destination, not the platform. Residency analysis has to cover the whole path, not just the middle.
Compliance conversations run on acronyms. Here is each one in a sentence, then how the three vendors stand. Two ground rules first. A DPA (data processing agreement) is the contract in which a vendor commits to handling personal data on your instructions — all three vendors offer one. A BAA (business associate agreement) is the HIPAA-specific contract a vendor must sign before it may touch US health data — and this one, as you'll see, is the sharp edge.
How the vendors stand, verified against their published materials at the time of writing — always reconfirm current status in each vendor's trust or security center before you rely on it:
| Posture | Zapier | Make | n8n |
|---|---|---|---|
| SOC 2 Type II audit | Yes (also SOC 3) | Yes (also SOC 3) | Yes (n8n Cloud; report available to enterprise customers) |
| ISO 27001 | Not the headline attestation; check trust center | Yes (information-security program) | Check current status with vendor |
| GDPR: DPA with SCCs offered | Yes | Yes (EU-native processing available) | Yes; Cloud processing already in the EU |
| HIPAA: will sign a BAA | No — explicitly does not support PHI | No — no published BAA | Not via standard Cloud terms; self-hosting changes the question (see below) |
| Data-residency levers | None | EU/US zone choice | Cloud in EU; self-host anywhere |
Three readings of that table matter more than the table itself.
First: SOC 2 is table stakes, not a differentiator. All three clear that bar. If a stakeholder waves a SOC 2 report as the reason to pick one platform, the argument is decorative.
Second: none of the three SaaS options is a HIPAA processor. Zapier states plainly that PHI is not supported on the platform and it cannot sign BAAs. Make's published materials likewise offer no BAA. If your workflows touch US health data, the SaaS routes are closed, full stop — a SOC 2 report does not substitute for a BAA, however sincerely a salesperson implies otherwise.
Third: self-hosting doesn't grant compliance — it relocates it. Here is the subtlety that decides the healthcare case. When you self-host n8n, the software vendor never processes your data, so there is no vendor to sign a BAA with — and no vendor to fail you. The compliance obligation lands on the infrastructure you run it on and the controls you wrap around it: a HIPAA-eligible hosting environment (the major clouds offer BAAs covering their infrastructure services), encryption, access control, audit trails, and policies. Organizations do run PHI through self-hosted n8n on exactly this basis. But it is your compliance program doing the work, and your auditor's opinion — not a property of n8n — that makes it defensible. The same logic applies to any regime the vendors don't cover: self-hosting makes compliance achievable, never automatic.
Watch out: Beware the phrase "HIPAA-compliant software." No software is; compliance describes an organization's practices, not a product. What you can buy is a vendor willing to sign a BAA and evidence its controls — or, via self-hosting, the ability to build that evidence yourself. Any listing or reseller claiming a platform "is HIPAA compliant" out of the box has told you something about their rigor.
Compliance frameworks care about the vendor's controls. Your security team will also ask about your controls on the platform — three in particular.
Two-factor authentication (2FA) — requiring a second
proof (an authenticator-app code, a hardware key) beyond the password at
login. All three platforms offer 2FA on ordinary accounts; it lives in
personal account or security settings on each (for example, under
Settings > Two-Factor Authentication or the equivalent
security section of your profile — the exact menu wording drifts, but
the feature is never buried deep). Turn it on everywhere, on every plan,
on day one. It is free on all three.
Single sign-on (SSO) — letting your staff log in through your company's identity provider (Okta, Microsoft Entra, Google Workspace) instead of a separate password, usually via SAML or OIDC (two standard protocols identity systems use to vouch for a user). SSO is what makes offboarding real: disable a departed employee in the identity provider and their platform access dies with it. On all three products, SSO is a higher-tier feature — Zapier includes SAML SSO on its team-level and enterprise plans, Make reserves it for its enterprise plan, and n8n treats it as a paid capability of its upper tiers whether you use Cloud or self-host (the free self-hosted community edition does not include it). Plan for this: if your security policy mandates SSO (many do), the effective price of every platform is its SSO-bearing tier, which materially changes the unit economics of Chapter 31.
Audit logs — a tamper-evident record of who did what in the platform itself: who edited a workflow, who viewed a credential, who changed a permission. (Distinct from execution logs, which record what workflows did.) Auditors ask for these; incident responders live in them. Across all three products, organization-level audit logging is again an enterprise-tier feature, and on self-hosted n8n the enterprise license adds log streaming — pushing those events into your own security tooling in real time.
| Control | Typical availability — Zapier | Make | n8n |
|---|---|---|---|
| 2FA | All plans | All plans | All editions |
| SSO (SAML/OIDC) | Team-level and enterprise tiers | Enterprise tier | Paid feature of upper tiers (Cloud or self-hosted) |
| Audit logs | Enterprise-grade tiers | Enterprise tier | Enterprise feature; streamable to your own tooling |
| External secrets-vault integration | — | — | Enterprise feature |
(Exact plan names and boundaries shift; treat this as the shape of the market, and confirm the current tier sheet during procurement.) How you use these controls — role design, workspace structure, review workflows — is Chapter 29's territory.
Tip: During procurement, ask each vendor one deliberately boring question: "Which plan do we need for SSO enforced for all members, plus audit-log export?" The answer collapses marketing tiers into the number that belongs in your cost model, and it frequently reorders the shortlist.
A 2026-era caveat that earlier compliance playbooks miss: the moment a workflow includes an AI step — summarize this ticket, classify this email — your data takes a second journey, to whatever model provider serves that step. A self-hosted n8n instance calling a US-hosted model API has just sent payload data outside the building through the front door, residency guarantees intact everywhere except where it matters. Self-hosting pairs naturally with self-hosted or private-endpoint models if that journey is unacceptable. The full treatment of AI data flows, retention by model vendors, and control strategies is Chapter 25 (Trust, Cost, and Control); flagging it here because hosting decisions made without it can be quietly undone by one dropped-in AI step.
Work through these in order; stop at the first verdict that fires.
Hosting, security, and compliance questions are eliminators, not selectors. They rarely tell you which platform is best; they tell you which platforms are possible — and they do it early and cheaply, before anyone has built forty workflows on the wrong foundation. Zapier is the pure-SaaS, US-hosted incumbent with strong audited controls and a flat "no" on PHI. Make matches the audit posture and adds the EU/US zone choice that satisfies most European residency preferences without any infrastructure work. n8n is the only one that can follow you behind the firewall, under a fair-code license that makes internal self-hosting free and plainly legal — at the price of becoming your own operator, and with its enterprise security features costing real money whichever way you host it.
Answer the tree, shortlist the survivors, and bring them to Chapter 35 with their true tier — the one with SSO and audit logs — priced in.
Most of this compendium assumes a simple arrangement: you sign up for an automation platform, you build workflows, and those workflows serve your own business. This chapter covers the two situations where that arrangement breaks down — where the automation platform stops being a tool you use and becomes a thing you redistribute.
The first situation is embedding: you run a software product of your own, your customers keep asking for integrations ("does it connect to Slack? to HubSpot? to QuickBooks?"), and you want to ship those integrations inside your product without building and maintaining hundreds of API connections yourself. All three vendors sell a version of this — Zapier through its Powered by Zapier embed tools, Make through Make Bridge, and n8n through its Embed license — and they differ sharply in branding, billing, and who does the hosting.
The second situation is client work: you are an agency, consultancy, or freelancer, and you build automations for other companies as a paid service. Here the question is not "how do I put the platform inside my product?" but "how do I manage a dozen client workspaces without violating anyone's terms of service, losing access at the worst moment, or accidentally becoming the single point of failure for someone else's business?"
Both situations share one deep question — who is the customer of the automation platform, and who pays for it? — and getting that answer wrong is the most expensive mistake in this corner of the market. This chapter is also deliberately narrow: workflows that present a form to a human are covered in Chapter 20 (Humans in the Loop), and chat interfaces that sit on top of workflows are covered in Chapter 24 (Knowledge, Memory, and Chat Surfaces). Here we are talking strictly about putting the platform itself — its editor, its connectors, its runtime — in front of people who are not you.
In ordinary use, an automation platform has two parties: the vendor and you. Embedding and client work both introduce a third party — your end user or your client — and every hard question in this chapter is really a question about how the triangle is wired:
Keep those three questions in mind as you read; each product answers them differently, and the answers determine which one fits your business.
Before evaluating any embed product, also write down your answer to a fourth question: who fixes it at 2 a.m.? Embedded automation becomes part of your product's reliability surface. If a connector breaks, your customers will file tickets with you, not with the automation vendor — no matter whose logo is on the workflow editor.
Every SaaS product eventually hits the integration long tail. Your ten biggest customers need five specific integrations, and you build those natively. But behind them sit hundreds of requests for connections you will never justify building one at a time — each one is an API to learn, an OAuth flow (the "sign in with X" authorization handshake described in Chapter 7) to implement, and a maintenance burden forever after, because third-party APIs change under you.
An embedded iPaaS — "integration platform as a service," the industry term for renting another company's connector library and workflow engine and surfacing it inside your own product — converts that long tail from an engineering roadmap into a licensing decision. The three platforms in this compendium all offer one, and the practical differences come down to the triangle above: account ownership, billing direction, and branding.
One prerequisite applies across all three: your own product generally needs to exist on the platform as a connector before embedding makes sense. Users embed workflows that connect your app to other apps, which means the platform needs to know how to talk to your app. Chapter 10 (When the Catalog Falls Short: Custom Connectors and Code Steps) covers how connectors get built on each platform; for Zapier in particular, a published public integration is the entry ticket to the whole embed program.
Zapier's embed offering — marketed under the "Powered by Zapier" banner and housed in its developer platform — is the oldest and most widely deployed of the three. Its defining characteristic: the end user brings their own Zapier account. You are not buying automation capacity and reselling it; you are surfacing Zapier's product inside yours, and each of your users signs in to (or creates) a Zapier account of their own, on whatever Zapier plan they choose to pay for.
The embed tools come in ascending order of integration depth:
The licensing and pricing implications follow directly from the account model. Embedding itself costs you little or nothing — Zapier wants to be embedded, because every embed surface recruits new Zapier users, and its partner program rewards integrations that drive adoption (better directory placement, co-marketing, and similar benefits that shift over time). What you give up is control of the commercial relationship. Your user's automation runs on their Zapier plan, subject to their task limits (a task being Zapier's billable unit of work — see Chapter 31, Unit Economics). If their Zap stops because their Zapier plan ran out of tasks mid-month, that failure happens inside a feature carrying your product's name.
Watch out: With any bring-your-own-account embed, your product's perceived reliability is coupled to a billing relationship you can neither see nor fix. Design your integrations page so that "this workflow is paused because of your Zapier plan" is visible and comprehensible to the user, or your support team will chase ghosts.
Make's embed product, Make Bridge, is younger (it emerged in the mid-2020s) and takes the opposite position on the triangle: your users do not need Make accounts at all. You — the software vendor — hold the Make relationship, and Bridge lets you surface Make-powered automation inside your product under your own brand.
The working model: in your Make account you build Bridge templates — ordinary Make scenarios (Make's word for a workflow) designed to be parameterized — and mark the choices an end user should make. Bridge then generates an integration wizard: a simplified, step-by-step setup flow your users see inside your product, embedded via Make's SDK or driven through its API. Users pick options and connect their accounts; they never see Make's full scenario editor, its data-flow diagrams, or its brand. You can adjust logos, fonts, and text so the wizard matches your product's look.
The commercial consequences:
Tip: Because you carry Bridge's consumption cost, model it before you price it. Estimate operations per template run, runs per user per month, and the distribution across your user base — then check the result against your gross margin the way Chapter 31 models any per-unit cost. An automation feature that costs you more than the plan upgrade it drives is a marketing expense, not a product.
n8n's answer is different in kind, not just degree. n8n Embed is a commercial white-label license: a contract that lets you take the n8n application itself — the editor, the runtime, the connector catalog — rebrand it, and ship it inside your product, typically on infrastructure you host and operate.
The first thing to understand is why the license exists. n8n's source code is publicly available, but it is not open source in the classic sense; it ships under a Sustainable Use License (a "fair-code" license), which permits free use for your own internal business purposes but prohibits offering n8n itself to others as a commercial product. Running n8n to automate your company: allowed. Selling your customers access to a rebadged n8n: not allowed — unless you hold the Embed license. Chapter 32 (Hosting, Security, and Compliance) covers the license's implications for ordinary self-hosting; here it is the legal hinge of the entire offering.
What the license buys you:
What it costs you:
| Dimension | Powered by Zapier | Make Bridge | n8n Embed |
|---|---|---|---|
| Who holds the platform account | Your end user | You (the vendor) | You, under license; you host |
| Who pays the automation vendor | Your end user | You, on consumption | You, annual license |
| Branding | Zapier-visible; Workflow API softens it | White-labeled wizard; Make hosts | Fully white-labeled |
| End-user experience | Templates up to full Zapier editor | Guided setup wizard only | Anything from hidden engine to full editor |
| Hosting and operations | Zapier | Make | You |
| Cost to start embedding | Minimal (public integration required) | Consumption-based | Significant annual commitment |
| Best fit | Ride an ecosystem your users already know | On-brand integrations without infrastructure | Automation as a core, controlled product capability |
The decision usually resolves on two axes. How central is automation to your product? If it is a supporting feature — an integrations page that closes deals — Powered by Zapier or Bridge gets you there in weeks. If it is load-bearing — the thing customers buy — n8n Embed's control justifies its cost. Who should own the commercial relationship? If you want automation revenue on your invoice and your margin, that excludes Powered by Zapier; if you never want to run infrastructure, that excludes n8n Embed; Bridge sits deliberately between. Chapter 35 (The Decision Framework) folds these axes into the product-team persona.
Watch out: Embedding is the stickiest form of lock-in in this entire book. Migrating your own workflows off a platform is a project (Chapter 34, Migration, Coexistence, and Lock-In); migrating a feature of your product — with hundreds of customers' live workflows, credentials, and expectations riding on it — is a re-platforming. Weigh the exit before you sign, and prefer designs where your product's data model, not the embed vendor's, is the source of truth.
The second redistribution model needs no license at all — it is the ordinary business of building automations for paying clients. All three vendors court this audience, because every agency is a distribution channel. But the operating mechanics differ, and so does the failure mode when you get account structure wrong.
Across all three platforms, one principle should govern everything: workflows that run a client's business should live in an account the client owns and pays for, with you invited in as a collaborator. Not the reverse.
The reasons stack up quickly:
Tip: Put account ownership in your statement of work: the client creates and pays for the platform subscription; you are added as a member; all connections are authorized by client-owned identities wherever possible, or by dedicated service accounts (shared-purpose logins created for automation, per Chapter 7) rather than an employee's personal login — and never by yours.
Zapier's collaboration model runs through its multi-seat plans: a client on a team-capable plan invites you as a member, and you switch between client accounts from your own profile — one login, many workspaces. On clients' solo plans without seats, agencies fall back to credential sharing through a password manager, which works but concentrates risk; treat it as a stopgap and prefer plans with real seats for anything long-lived.
Formally, Zapier's practitioner channel is its Solution Partner Program (the successor to the long-running Zapier Experts program). Membership brings a partner directory listing (inbound lead flow), a partner portal, tiered benefits that scale with the business you drive, and referral mechanics that pay when clients you bring upgrade. None of it changes the account mechanics above; it changes your economics and visibility.
Operationally, Zapier's simplicity is its agency superpower and its ceiling at once. Handovers are easy because clients can read their own Zaps — the linear trigger-then-actions shape from Chapter 3 (Mental Models) survives contact with non-technical owners. But per-client environments stay siloed: there is no umbrella console showing every client's run health at once, so monitoring across a book of clients means either logging into each account or wiring alert workflows that push failures to you (Chapter 27, Monitoring, History, and Alerting).
Make's structural advantage for agencies is its workspace hierarchy. A Make organization is the top-level container that holds billing and members; inside it, teams partition scenarios, connections, and data with their own access lists (Chapter 29, Teams, Governance, and Change Management, covers the model in depth). That gives agencies two clean patterns:
Make formalizes the channel through its Solution Partner Program for agencies and consultants (alongside separate tracks for software vendors and enterprise service providers). Partner status brings directory listing, enablement and certification, a partner portal, and commercial benefits that deepen by tier; partners running many client organizations get purpose-built management arrangements at the upper end. Of the three vendors, Make leans hardest into the agency channel as a first-class go-to-market motion, and it shows in the program's maturity.
n8n's agency story has the most moving parts, because hosting enters the picture. Three patterns dominate:
Watch out: "We'll just host it for them" is where agencies drift from consulting into unlicensed software distribution without noticing. The line is not how many servers you run — it is whether clients are paying you for your work or for access to n8n. If removing your services would leave the client with a working platform they own, you are consulting. If it would leave them with nothing, you are distributing. When in doubt, ask n8n; the sales team answers this question daily.
n8n's practitioner channel — an experts/partner listing and community credentialing — is younger and thinner than Zapier's or Make's, which matches the product's center of gravity: n8n agencies tend to win on technical depth (custom nodes, code steps, self-hosted deployments — Chapters 10 and 32) rather than on program benefits.
However the accounts are wired, you still have to charge for the work. Four structures cover nearly all client automation practices, and most mature agencies blend them:
| Structure | What the client pays for | Where it fits |
|---|---|---|
| Project fee | A defined build, delivered and handed over | Discovery-to-launch engagements; the Chapter 36 lead-capture build is a canonical scope |
| Retainer | Ongoing maintenance, monitoring, and small changes | Post-launch; workflows decay as connected apps change, so recurring care is honest, not padding |
| Value or outcome pricing | A share of measurable impact (hours saved, leads processed) | Trust-heavy relationships with clean baseline metrics |
| Managed automation | An all-in monthly fee bundling platform costs and service | Fully-managed clients — the model most in tension with the ownership rules above; structure it carefully |
Keep platform fees pass-through wherever possible: the client pays the vendor directly on their own card, and your invoice covers only your services. It keeps you clear of resale clauses, keeps price changes the vendor's problem instead of a margin surprise, and keeps the exit clean. Where partner programs pay you for referred subscriptions, disclose it — a vendor-neutral recommendation you are paid to make is only neutral if the client knows.
One more billing asymmetry belongs in your pricing: the platforms' unit economics (Chapter 31) hit agencies differently. Zapier's per-task pricing makes high-volume client workflows expensive fastest; Make's per-operation model rewards the efficient scenario design covered in Chapter 13 (Lists, Loops, and Aggregation); self-hosted n8n makes marginal runs nearly free but shifts cost into your hosting-management time. Agencies that quote a flat build price without modeling the client's run-rate costs end up explaining, three months later, why the automation's platform bill exceeds its fee.
Because engagements end, the handover is not an afterthought — it is part of what the client bought. A defensible handover package includes: an inventory of every workflow with its trigger, purpose, and owner; documentation of every connection and which identity authorized it (Chapter 7); error-handling behavior and where alerts go (Chapter 19); and a walkthrough sufficient for the client's staff — or a successor agency — to operate the system. The reuse and modularity practices from Chapter 18 pay off double here: sub-workflows and templates you can lift between clients are also artifacts a client can understand when you leave.
Tip: Build the handover document as you build the automation, not at the end. On every platform, workflow names, descriptions, and notes fields are the cheapest documentation surface you have — a scenario named
client-crm-sync-v3-final-FINALis a future support ticket with your name on it.
For the Chapter 35 framework, this chapter reduces to two persona verdicts.
The product team choosing an embed partner is really choosing a business model. Powered by Zapier maximizes ecosystem reach and minimizes cost and effort, at the price of visible branding and a customer billing relationship you don't control. Make Bridge delivers on-brand, vendor-hosted integrations you can price yourself, at the cost of consumption margin risk and a deliberately simplified end-user surface. n8n Embed delivers total control — brand, hosting, data path, editor — at the cost of a serious license fee and the obligation to operate the platform. The forcing question: is automation a feature of your product, or the product?
The agency is choosing an operating posture more than a platform. Zapier offers the easiest client comprehension and handover, plus a mature partner program, but siloed accounts and task pricing that punishes volume. Make offers the strongest structural fit — organizations and teams built for multi-client work, and the most agency-committed partner program of the three. n8n offers the deepest technical differentiation and the best run-rate economics for volume-heavy clients, in exchange for hosting complexity and a license boundary you must respect deliberately. Most real agencies end up multi-platform, matching Chapter 4's capability map to each client rather than to themselves — which is, in the end, the most vendor-neutral advice this guide can give.
Every platform choice in this book is reversible — at a price. The purpose of this chapter is to let you see that price before you commit, lower it where you can, and recognize the cases where the smartest move is not to migrate at all but to run two platforms side by side on purpose. "Lock-in" gets thrown around as if it were a single wall you either can or cannot climb. It is nothing so tidy. It is a bundle of separate dependencies that accumulate quietly, and the first useful thing you can do is name the strands.
There are six of them, and they come loose at very different rates. The workflow logic — the steps and the rules connecting them — is usually easiest to reproduce, because logic can be read and rebuilt. The credentials you have authorized (the saved logins to Salesforce, Stripe, your email; see Chapter 7, Connections and Credentials) never travel and must be re-created wherever you land, but that is true on every platform, so it is a constant rather than a differentiator. The webhook addresses you have handed out to other systems — the inbound URLs other apps push events to — are a hard dependency on outside parties who must reconfigure when you move. The data stored inside the platform — tables, data stores, static values — must be physically moved, not just rebuilt. The run history you lean on for audits generally stays behind. And the least visible strand, often the largest, is the fluency locked in your team's heads: the instinct for how this particular tool fails and how you fix it.
When someone says "we're locked into Zapier" or "we can't leave Make," they almost always mean two or three of these strands, not all six. Untangling which ones actually bind you is how you turn a vague dread into a plan.
Start with the most concrete question: if you decided to leave tomorrow, what could you physically carry out the door?
n8n represents every workflow as a JSON document — JSON (JavaScript
Object Notation) being the standard plain-text format for structured
data, readable by humans and machines alike. From the workflow editor
you can download any workflow as a .json file, copy
selected nodes to your clipboard as JSON text, or import a file back in.
The round trip is high-fidelity: nodes, the connections between them,
expressions, per-node settings, and even canvas layout all survive. This
is not a bolt-on. It is how n8n users routinely back up work, promote a
workflow from a test instance to production, and keep automations under
version control (a system that tracks every change to a file over time,
so you can see history and roll back).
n8n leans into this further with built-in source control on its higher tiers: you can link an instance to a Git repository — Git being the dominant version-control system — and push or pull workflows between environments as ordinary code changes. What crosses is the logic plus stubs for credentials and variables; the secret values stay out, by design (see Chapter 32, Hosting, Security, and Compliance).
Two caveats matter. First, credentials do not ride inside the JSON, deliberately, for security. An imported workflow arrives pointing at credential names that do not yet exist at the destination, and you re-create or re-link each one. Second, if you self-host n8n (run it on infrastructure you control), you own far more than the workflow files: the entire application database — past executions, encrypted credentials, users, settings — sits on your own server. That is the deepest data portability any of the three platforms offers, and a major reason data-sensitive teams gravitate to self-hosted n8n.
Make calls an exported scenario a blueprint — a JSON file describing every module, its settings, its field mappings, and the links between modules. You export a blueprint from the scenario editor and import it into another scenario, another team, or another Make account. As with n8n, the blueprint excludes the live connection credentials; the imported scenario shows modules with unlinked connections waiting for you to re-authorize them by hand. Blueprints also leave operational state behind: the contents of data stores (Make's built-in mini-database, covered in Chapter 14) and the scenario's execution history do not come along.
Blueprints are genuinely useful in daily life, not just at migration time. They are how Make templates circulate, how agencies hand a working scenario to a client, and how careful teams snapshot a scenario before a risky edit. Treat the blueprint as your backup format from the first day you build anything you would hate to lose.
Zapier used to be the clear outlier, with no file export at all. That has softened. On its higher-tier Team and Enterprise plans, Zapier now lets you export and import Zaps as JSON files, and a separate account-level option — reachable from the security-and-data area of your account settings — lets you download a JSON copy of your Zaps for safekeeping. On the lower-priced individual plans you still get only in-ecosystem sharing: copying a Zap, sharing a template link so someone else can spin up their own copy, or moving Zaps between members of a team account.
Two facts keep this from being the migration lever it might look like. First, it is plan-gated — the file export lives on the upper tiers, and many Zapier users will never see it. Second, and more important, the JSON is Zapier's own internal format. It re-imports into Zapier; it does not import into Make or n8n, and no reliable converter turns it into either. So Zapier's export solves backup and same-platform portability — moving Zaps between your own Zapier accounts, keeping an off-platform copy — and does essentially nothing for a cross-platform rebuild. If you leave Zapier for another vendor, the logic still leaves through your eyes and your keyboard: you read each step and reconstruct it on the destination.
This should shape how you use Zapier rather than whether you should. Zapier remains the fastest route to an enormous catalog of app integrations (Chapter 6, The App Catalogs). But every Zap you build is a small IOU written against a future migration, and the habits at the end of this chapter are how you keep those IOUs small.
| Question | n8n | Make | Zapier |
|---|---|---|---|
| Export workflow logic to a file? | Yes — workflow JSON, download or copy-paste | Yes — blueprint JSON | Yes on higher tiers — Zapier-format JSON; in-ecosystem sharing on lower tiers |
| Re-import into the same platform elsewhere? | Yes, high fidelity | Yes, high fidelity | Yes, into Zapier (creates a new "Imported Zaps" folder) |
| Export imports into a different platform? | No | No | No |
| Credentials included in the export? | No, by design | No, by design | No — reconnect after import |
| Platform-internal data (tables/data stores) included? | Static data needs separate handling; self-hosters own the database | Data store contents not in blueprint | Zapier Tables and Storage stay behind |
| Run history exportable? | Self-hosted: it is your database; cloud: via UI/API | View and retrieve via UI/API | View in the UI (Zap history) |
| Own the whole system? | Self-hosted: yes, fully | No | No |
Watch out: An export is portable within a product family, never across families. A Make blueprint will not open in n8n; n8n JSON will not open in Make; Zapier's JSON opens only in Zapier. The three formats describe three different underlying data models (Chapter 11, Three Data Models), so there is no faithful automatic translation between them and none of the mainstream "converters" you will find advertised do the job reliably. Cross-platform migration is always a rebuild. The export only makes the rebuild dramatically easier to specify.
Because there is no import button that bridges two vendors, a cross-platform migration is a translation exercise. The encouraging news is that the translation is far more mechanical than it first looks, because all three platforms are built from the same small set of constructs described in different dialects. Chapter 4 (The Rosetta Stone, the Capability Map, and How to Decide) laid out the full translation table. Here is the working subset you actually reach for during a migration, walked construct by construct, followed by an honest method for estimating the effort.
Almost every business automation reduces to the same skeleton: something happens → check whether we care → reshape the data → maybe branch → do one or more things → handle failure. Take a representative mid-sized workflow of that shape and translate it a piece at a time.
The trigger. Zapier says trigger, Make calls the first module of a scenario the trigger, n8n calls it a trigger node — same idea, three names. The translation question is not the label but the mechanism: is it polling (the platform checks the source app on a repeating schedule), an instant webhook (the app pushes an event the moment it happens), or a clock schedule? Chapter 8 (Triggers: How Workflows Start) covers why the distinction matters. The migration-specific trap is that a polling trigger keeps private deduplication state — a memory of which records it has already handled — and that memory does not migrate. A freshly built trigger on the new platform starts with amnesia, so on first activation it may re-fire for recent records, or fire in parallel with the still-running old platform during cutover. Plan for this deliberately; the cutover method below handles it.
Filters and conditions. Zapier's Filter step, Make's per-route filters (which live on the line between two modules rather than as a module of their own), and n8n's IF or Filter nodes all express the same "only continue if" logic in three grammars. The translation is usually one construct to one construct, but check the operator semantics: how each platform treats an empty value, whether text comparison is case-sensitive, and how dates compare all differ enough to cause a silent wrong answer. Re-test every filter with a record that should not pass, not only one that should.
Field mapping and transformation. This is where most of the manual labor lives, and where step counts mislead you. Zapier spreads reshaping across separate Formatter steps; Make embeds functions directly inside a field mapping; n8n uses expressions or a Code node (Chapter 12, Mapping and Transforming Fields). A Zap with four Formatter steps often collapses to zero extra steps on Make or n8n because the same work happens inline. That is pleasant, but it means the old and new workflows will not have matching step counts, so a checklist that reads "recreate all twelve steps" is the wrong mental model entirely. Translate what the data must look like at each seam — the exact shape entering and leaving each real integration — not the intermediate plumbing.
Branching. Zapier Paths, Make's Router, and n8n's IF and Switch nodes map cleanly at the concept level (Chapter 16, Branching: Filters, Paths, and Merges). Watch two things. Maximum branch counts and nesting rules differ. And merging branches back together differs sharply: recombining is natural in n8n, structured but explicit in Make, and awkward in Zapier. If your source workflow is visibly contorted around one platform's branching limits, the destination version should usually be redesigned to fit the new platform's grain, not transliterated line for line.
Loops and lists. This is the deepest data-model difference of all (Chapters 11 and 13, Lists, Loops, and Aggregation) and the construct most likely to move your effort estimate. Zapier mostly hides iteration or handles collections through line items; Make makes iteration explicit with Iterators and Aggregators; n8n runs most nodes over every incoming item automatically. A Zapier workflow built on line-item tricks can become genuinely simpler on Make or n8n. An n8n workflow that leans on automatic per-item execution may need explicit iteration when rebuilt on Make, and can be awkward or impossible to express in Zapier. Identify list handling early, before you promise anyone a timeline.
Platform storage. Zapier Tables and Storage, Make data stores, n8n static data and variables (Chapter 14, Storing Data Inside the Platform). None of it migrates automatically. You will export the contents where the platform lets you, reshape them, and load them into the destination — or, far better, treat the migration as the moment to move that data to an external store you own, which is the first day-one habit below.
Error handling. Autoreplay settings, Make's error-handler routes, n8n's dedicated error workflows (Chapter 19, Error Handling by Design) rarely translate one to one and are the easiest thing in the whole workflow to forget, because they never appear on the happy path you tested. List error handling as its own line during inventory, or the rebuilt workflow will silently lack the resilience the original had, and you will discover the gap the first time the destination hits a bad record at 2 a.m.
Code steps. JavaScript or Python inside a code step (Chapter 10, When the Catalog Falls Short) is often the most portable single element — the language is the same everywhere — but the wrapper around it is not: how input data arrives, how output must be shaped for the next step, and which libraries and time limits apply all vary by platform. Budget a small, predictable adaptation for each code step rather than assuming a clean copy-paste.
The full worked rebuilds — one real project carried across all three platforms — are Chapters 36 and 37 (Worked Project 1 and Worked Project 2). If a migration is genuinely on your horizon, read the destination platform's build there before you estimate anything, because seeing the target shape changes the estimate.
A method that avoids both panic and wishful thinking:
Tip: Before you extrapolate a total, actually build one conceptual-equivalent workflow end to end and time it. Your first rebuild on an unfamiliar platform takes roughly three to five times longer than your fifth. Extrapolating from workflow number one badly overestimates the total; extrapolating from a slick vendor demo badly underestimates it. One real, timed rebuild is worth more than any spreadsheet of guesses.
Watch out: The migration cost nobody writes on the estimate is fluency. A team that has internalized one platform's mental model (Chapter 3, Mental Models) debugs a failure there in minutes. On the new platform, the same class of failure costs an afternoon for the first few months, because the instinct has not formed yet. If your automations are operationally critical, schedule the migration for a calm season, not the week before your busiest quarter.
Migration is not the only response to a platform mismatch, and it is frequently not the best one. Running two platforms deliberately, each doing what it does best, is a legitimate architecture rather than a failure of decisiveness. A great many mature operations settle here on purpose and stay.
Zapier for breadth, n8n for depth. This is the most popular pairing, and it is popular because the two platforms' strengths are almost mirror images. Zapier's catalog advantage means the long tail of niche SaaS — the obscure CRM, the booking tool, the regional payment provider — connects in minutes with no engineering. n8n's strengths are the opposite profile: high-volume processing where per-task pricing would sting (Chapter 31, Unit Economics), intricate logic with loops and merges, code-heavy transformation, and any workflow touching data that must stay on infrastructure you control (Chapter 32). The division nearly writes itself — light and wide integrations on Zapier; heavy, private, or complex workloads on n8n.
Make in the middle. Make pairs comfortably with either neighbor. Teams run Zapier alongside Make to keep visually complex, iteration-heavy scenarios on Make's typically friendlier per-operation economics while still reaching the apps only Zapier catalogs. Teams run Make alongside n8n when they want Make's polished visual builder for business-facing scenarios and n8n for the self-hosted or code-centric jobs.
Old plus new, during a long migration. Coexistence is also the honest name for any migration that runs longer than a month, which is most of them. The disciplines below apply identically; the only difference is that in a migration the traffic split is meant to drift steadily toward one platform, whereas in a permanent split it holds roughly steady.
Two platforms in one business need an explicit rule for where each one's territory ends, or you drift into the anti-pattern: overlapping workflows on both platforms touching the same records, ping-ponging events at each other, and nobody sure which system did what. Three rules keep the seam clean.
Split by workload, not by app. A rule like "HubSpot lives on Zapier, Postgres lives on n8n" decays fast, because real workflows cross apps constantly. A workload rule survives: "customer-facing notifications and long-tail app glue run on Zapier; anything over a few thousand runs a month, anything touching the data warehouse, and anything with regulated data runs on n8n." A workload rule tells a builder where a new workflow belongs without anyone calling a meeting.
Bridge with webhooks, and keep the bridge thin. When a single workflow genuinely must span both platforms, have one platform call the other over a webhook — an HTTP request to a URL the receiving platform listens on (Chapter 9 covers the mechanics; Chapter 18, Modularity and Reuse, covers this as a design pattern). Pass a small, well-defined JSON payload: the specific IDs and fields the receiving side needs, and nothing more. A thin, documented seam means either platform can later be rebuilt or replaced without the other noticing. A thick seam — one platform reaching directly into the other's internal storage, or payloads that dump whole raw records across — quietly recreates lock-in between your own two platforms, which is genuinely the worst of both worlds.
One workflow, one home. Never run the same business process on both platforms at once, except during a deliberate, time-boxed parallel run with the deduplication guard from earlier in place. Duplicate automation produces duplicate emails, duplicate charges, duplicate records, and support tickets that take days to trace back to their cause.
Be honest about the costs, because they are real even when the strategy is right. Two subscriptions — though the split often lowers total spend once heavy workloads move off per-task pricing, so run the numbers with Chapter 31's method rather than assuming two bills are worse than one. Two skill sets to keep current, which bites hardest in small teams where a single person holds all the automation knowledge (Chapter 29, Teams, Governance, and Change Management, treats this bus-factor problem directly). Two monitoring surfaces, meaning failures now need watching in two places — so centralize alerting into one channel using Chapter 27's patterns. Two credential inventories, doubling the audit surface for Chapter 7's hygiene practices. And cross-seam debugging: when a record goes missing, the investigation now spans two run histories joined only by a single webhook call, so stamp a correlation ID — one shared unique value — onto the payload at every seam so you can trace a single event across both platforms (Chapter 28, Diagnosing Failures).
Tip: If you adopt the two-platform strategy, write the territory rule down in one short paragraph and put it where every workflow builder will actually see it. The strategy almost never fails through a technical problem. It fails through drift — each new workflow lands on whichever platform its author happened to be logged into that day, and eighteen months later nobody can explain why anything lives where it does.
If those costs sound heavier than your automation footprint justifies, they probably are. Coexistence earns its keep roughly at the point where you have two genuinely distinct workload classes — one that needs breadth, one that needs volume, privacy, or complexity. Below that line, pick a single platform with Chapter 35's framework and keep your life simpler.
Everything above gets dramatically cheaper if you build a handful of habits into your very first workflow, long before any migration is on the table. None of them slows you down much today. All of them compound.
The built-in stores — Zapier Tables and Storage, Make data stores, n8n static data — are convenient, and Chapter 14 covers the cases where that convenience is worth taking. But data inside a platform store is the single stickiest strand of lock-in there is: workflow logic can be rebuilt from documentation, whereas data must be physically moved, and platform stores export grudgingly if at all. The habit is simple. When state must persist between runs — a customer list, a log of already-processed IDs, a small queue — prefer an external store you own: a real database, a Google Sheet or Airtable base, even a well-structured file in cloud storage (Chapter 15, Files and Documents). Reserve the platform's own store for small, disposable state: counters, deduplication caches you could lose without harm, short-lived lookups. Ask of every value you are about to store: if this platform vanished overnight, would losing this data hurt? If yes, it belongs outside.
Every time you hand a platform-generated webhook URL to an external system — your website's contact form, a payment provider, a partner's system — you create a hard dependency on someone else's configuration. Migrate later and every one of those senders has to be updated, several of them by people outside your company, on their schedule rather than yours. There are two mitigations, in ascending order of effort. The minimum: keep a register — a plain shared document listing every external system that holds one of your webhook URLs, which workflow it feeds, and who is able to change it. That costs about a minute per webhook and turns a migration-day scavenger hunt into a checklist. The better version, for seams you expect to outlive the platform: hand out a URL on a domain you control and forward it to the platform — a redirect rule at your DNS host (DNS being the system that maps domain names to servers), a tiny relay endpoint, or an API gateway if you already run one. Then a migration means changing one forwarding rule you own, and the dozen external senders never learn that anything moved.
The reason Zapier migrations historically hurt is not that rebuilding is hard; it is that reading a live workflow to reconstruct what it was supposed to do is hard, especially once its author has left the company. A one-page spec per workflow removes that pain on every platform, including the exportable ones — because JSON tells you exactly what a workflow does and never why. The page holds: what event starts the workflow, which systems it touches, what the data must look like at each hop, what should happen on failure, who owns it, and any deliberate oddities ("the ten-minute delay exists because the CRM's webhook fires before the record is fully saved"). Write it as you build; update it when you change. This is the very same artifact Chapter 29 asks for as a governance practice — lock-in insurance and change management turn out to be one document, so you only write it once.
For Make and n8n, add the mechanical half of the habit: export the blueprint or workflow JSON on every meaningful change and commit it to version control. A Git repository is ideal; a dated folder in shared cloud storage is an acceptable start. n8n's higher tiers link workflows to Git natively, but a disciplined manual export captures most of the benefit on any plan.
When a workflow can be built two ways — one using constructs every platform shares (a webhook trigger, a filter, a field mapping, an HTTP call), the other using a platform-exclusive convenience — the shared-construct version is a little more portable every single time. This is a preference, not an iron rule. Platform-specific features exist because they genuinely help, and refusing all of them means paying insurance premiums on a migration that may never come. But when the two versions are close in effort, take the boring one. In particular, a raw HTTP request calling a well-documented API (an API being the machine-readable interface a service exposes; Chapter 9) is the most portable step that exists — it translates across all three platforms almost verbatim, because it depends on the outside service's contract rather than on any one platform's cleverness.
Watch out: The least portable construct in modern automation is the AI step whose prompt and behavior have been tuned by trial and error against one platform's particular way of calling the model (Volume E, especially Chapter 21, AI Steps Inside Ordinary Workflows). The prompt text copies anywhere; the hard-won tuned behavior often does not, because the surrounding platform feeds the model slightly different context. Keep your prompts in your documentation, not only inside the step, and note which model and settings each one was tuned against so the next person is not tuning from zero.
Once a quarter, spend thirty minutes on a lock-in review. Is the workflow inventory current? Are the exports committed and recent? Does the webhook register still match reality? Has a platform store quietly accumulated data that ought to live outside? Which workflows have crossed into heavy volume and should now trigger the two-platform territory rule? This runs on the same cadence as the governance reviews in Chapter 29 and folds neatly into them, so it is not a new meeting — just a few extra questions on an agenda you already keep.
Pulling the chapter together into one qualitative comparison — remembering that no platform scores perfectly, and that low lock-in is only one factor among the many weighed in Chapter 35 (The Decision Framework):
| Lock-in strand | n8n | Make | Zapier |
|---|---|---|---|
| Workflow logic portability | Strong — full JSON export; self-hosters own the whole database | Good — blueprint export within the Make ecosystem | Fair within Zapier (JSON export on higher tiers); still a manual rebuild to leave Zapier |
| Credential portability | None — re-authorize everywhere (true of all three) | None | None |
| Internal-data exposure | Low if you follow the external-storage habit; instance data is yours when self-hosting | Medium — data stores are convenient and sticky | Medium-high — Tables and Storage are convenient and sticky |
| Webhook-address exposure | Same for all three — governed by your seam habits, not the platform | Same | Same |
| Knowledge/fluency lock-in | Real, and deepest where usage is most code-centric | Real — the visual model is distinctive | Real, but the shallowest learning curve to re-acquire |
Read the last row against the grain of the others, because it inverts them. Zapier, the weakest on logic portability, is also the easiest platform for a new person to become useful on quickly, which softens the fluency strand considerably. n8n, the strongest on portability, embodies the deepest mental model — leaving it means giving up capability, not merely convenience, so its low technical lock-in is partly offset by high skill lock-in. Lock-in is never a single number, and any comparison that reports it as one is hiding the trade-off that actually matters to you.
A closing reframe. The strongest position is not "we chose the platform we can leave." It is "we could leave any of them in a known number of days, and we know the number." Exports committed, workflows documented on one page each, important data held externally, webhook seams published under your own domain — with those four habits in place, the platforms have to earn your workload every quarter, and whichever one you keep, you are keeping it by choice rather than by inertia. That freedom, more than any feature on any comparison grid, is what this chapter exists to give you.
Every chapter before this one was building a single instrument. Chapter 4 (The Rosetta Stone, the Capability Map, and How to Decide) split the impossible question — "which platform is best?" — into six answerable ones, and sketched five personas with weights penciled in as High, Medium, and Low. Volumes B through G then filled in the evidence, one area at a time. This is the chapter where you pick the instrument up and play it: turn those qualitative weights into numbers, score n8n, Make, and Zapier against the six areas, apply the disqualifiers and tie-breakers, run a two-week pilot to test the paper answer against reality, and write the decision down so you can defend it now and reopen it later.
Two commitments before we start. First, nothing here is a new fact about any platform; every score compresses material already covered and points back to where the evidence lives, so if a number surprises you, the cited chapter is the argument. Second, the scores are judgments, not measurements — considered ratings as of this writing, certain to drift as the products drift. What you keep is not the verdicts but the method, which you can re-run any afternoon with fresh scores and your own weights.
Here are the six areas again, exactly as Chapter 4 defined them, with the chapters that supply each one's evidence.
| Area | The question it answers | Where the evidence lives |
|---|---|---|
| Connectivity | Can it reach the services I use — and the ones with no catalog entry? | Chapters 6-10 |
| Data | Can it carry, reshape, store, and move my data without garbling it? | Chapters 11-15 |
| Flow control | Can it express my process — branches, timing, reuse, failure, sign-off? | Chapters 16-20 |
| AI | Can it use AI in workflows, build workflows for me, or act as an agent — safely? | Chapters 21-25 |
| Operations | Can I test it, watch it, fix it, govern it, and scale it once it matters? | Chapters 26-30 |
| Adoption | Can I afford it, host it where I must, embed it, and leave it if I need to? | Chapters 31-34 |
The tool this chapter builds is a weighted decision matrix — a plain table. Rows are the six areas, columns are the three platforms, each cell holds a score for how well that platform handles that area, and each row carries a weight for how much that area matters to you. Multiply every score by its row weight, sum each column, and compare the totals. The arithmetic is grade-school; the value is entirely in what the table forces into the open. When two people reach different conclusions, the matrix shows precisely where they part ways — a single score, or a single weight — and a disagreement about one number is a conversation that ends, whereas "Zapier is just better" is a conversation that never does.
The method runs in a fixed sequence, and the sequence is load-bearing:
Tip: Do the steps in this order and resist reordering them. Scores before weights, weights before adjustments, and everything before totals. Jumping to the totals first is exactly how motivated reasoning gets in — with six numbers to tune, you can always find a set of weights that crowns whichever platform you already wanted.
A red line is a requirement that eliminates a platform outright, no matter how high its total would have been. Check these first, because scoring a platform you cannot actually use is wasted effort.
Watch out: Red lines are for genuine requirements, never for preferences. The most common way a matrix gets rigged is that someone slips "we'd really rather not" into the disqualification list to protect a favorite. The honest test is a single question: would you truly abandon the whole project rather than cross this line? If the answer is no, it is not a red line — it is a weight, and it belongs in Step Three where it can be traded off against everything else.
Scores run from 1 to 5. A 3 means "competent, with real friction"; a 5 means "the clear leader of these three." Half-points are allowed. These rate each platform at its best, in the hands of a team able to use it fully; the gap between that ideal and your reality arrives as adjustments in Step Four, where it can be reasoned about rather than smuggled into the base number.
| Area | n8n | Make | Zapier |
|---|---|---|---|
| Connectivity | 4 | 4 | 5 |
| Data | 4.5 | 4 | 3 |
| Flow control | 4.5 | 4 | 3.5 |
| AI | 4.5 | 3.5 | 4 |
| Operations | 3.5 | 4 | 4.5 |
| Adoption | 4.5 | 4 | 3 |
The reasoning, row by row:
Connectivity. Zapier's catalog is the largest by a wide margin, with the deepest long tail of niche business apps (Chapter 6). Make's catalog is substantial, and its modules frequently expose more of an app's underlying API than Zapier's deliberately simplified actions. n8n's catalog is the smallest, but this area also asks about services with no catalog entry, and there n8n leads outright: its HTTP Request node is a full-strength API client, code steps are native, and a custom node is a first-class path (Chapters 9 and 10). Zapier earns the 5 because catalog breadth decides this area for the typical buyer; n8n's extensibility offsets its smaller catalog only for teams equipped to use it, which the adjustments step captures.
Data. Chapter 11 (Three Data Models) is the spine of this row. n8n's items-and-JSON model is the most explicit and powerful once learned, and the least forgiving if it is not. Make's bundles — its term for the data packets that pass between modules — sit in the middle: the data structures are visible on the canvas, and its array handling is genuinely strong (Chapter 13). Zapier's flattened, one-record-per-run model is the friendliest to a beginner and the most constraining at the edges — line items remain its perennial awkward corner.
Flow control. n8n and Make both offer real branching, merging, and designed error handling (Chapters 16 and 19), with n8n slightly ahead on complex merges and reusable sub-workflows (Chapter 18). Zapier's paths, delays, and error options have matured but remain the most linear of the three — a feature for simple work, a ceiling for intricate work.
AI. All three have invested heavily. n8n's agent and model tooling is the most composable and the most willing to let software direct itself (Chapter 23); Zapier's copilots and catalog-wide AI actions are the most accessible to a non-technical builder (Chapter 22); Make is stronger on structured AI steps than on agent autonomy. This is the shortest-lived row in the table — reverify Volume E's landscape before you lean real weight on it.
Operations. Zapier's managed run history, alerting, and team surfaces are the most polished (Chapter 27), and its guided diagnosis loop the friendliest when something breaks (Chapter 28). Make's scenario history and incomplete-executions machinery are strong. n8n's debugging is excellent — full execution data, pinned test data — but its monitoring and alerting are the most do-it-yourself, and if you self-host, you are the operations team (Chapters 27 and 32). That burden is a property of the platform's model, not a persona quirk, so it belongs in the base score.
Adoption. n8n leads: the best unit economics at volume (Chapter 31), the only self-hosting option (Chapter 32), portable workflow definitions, and the gentlest exit (Chapter 34). Make holds the middle on cost and hosting. Zapier's per-task pricing produces the steepest cost curve as volume climbs — the recurring complaint Chapter 31 quantified.
Watch out: Do not average the six numbers into one "overall score" per platform. An unweighted average silently asserts that all six areas matter to you equally, which is never true for anyone. The weights are where your situation enters the arithmetic; averaging skips that step — the exact failure mode of every comparison that ends in one grand ranking.
Chapter 4 handed each persona qualitative weights. Here those become percentages that sum to 100. Roughly, a High lands between 20 and 30, a Medium between 10 and 15, and a Low between 5 and 10; within those bands we nudged individual rows and will say why. Treat every number below as a default to argue with — the worked examples exist so you can see how to disagree.
| Area | Solo operator | SMB ops team | Agency | Product/eng team | Regulated enterprise |
|---|---|---|---|---|---|
| Connectivity | 30 | 25 | 20 | 10 | 10 |
| Data | 10 | 15 | 10 | 20 | 10 |
| Flow control | 10 | 15 | 10 | 20 | 15 |
| AI | 15 | 10 | 10 | 10 | 5 |
| Operations | 10 | 20 | 25 | 25 | 30 |
| Adoption | 25 | 15 | 25 | 15 | 30 |
The nudges worth confessing. The SMB column promotes Operations from Chapter 4's Medium into the bottom of the High band, because workflows several people depend on need watching more than they need novel capability, and it keeps AI at the floor of the Mediums, following Chapter 4's warning to weight AI by what you will actually run every month rather than by what demos well. The regulated column gives Flow control a little extra, because approval gates and error-handling design are audit surface (Chapters 19 and 20), and drops AI to the floor — not from indifference but because Chapter 25's trust and control questions gate any higher number.
A weighted total is the sum of weight times score, divided by 100, which lands the result back on the familiar 1-to-5 scale. Now the five personas, worked all the way through.
Each persona below declares its adjustments — the places where a platform's effective capability differs from its base score for this particular situation — before any total is computed, with the reason attached to each. Declaring adjustments in advance, in the open, is the single practice that separates an honest matrix from one reverse-engineered to reach a predetermined answer.
One person automating their own business. Connectivity carries the most weight (there is no time to build around a missing connector) and Adoption comes next (the monthly bill has to stay boring). The defining adjustment follows straight from Chapter 4's definition: this persona has no developers on call, so n8n has to be scored as its non-coder-accessible self. Its Data and Flow control each drop a point — the expressions-and-JSON barrier of Chapter 12 is real when there is nobody to ask — and its Adoption drops a point too, because self-hosting is off the table (Chapter 32), surrendering part of the very cost advantage that earned the 4.5.
| Platform | Weighted total |
|---|---|
| n8n | 3.80 |
| Make | 3.93 |
| Zapier | 3.95 |
Verdict: Zapier, by a nose — and the closeness is the actual finding. The catalog means your first ten automations already exist as near-templates, and the managed operations mean weekends stay quiet. But a two-hundredths lead over Make is the matrix telling you the two are comparably fit, which hands the decision to the tie-breakers: if your projected run volume makes Zapier's per-task pricing uncomfortable (run Chapter 31's crossover math), Make takes it — you keep managed hosting and flatten the cost curve for a slightly steeper first week. n8n's 3.80 is not a black mark; it is what a matrix returns when a tool's best qualities sit behind skills this persona does not have.
A small operations team automating a company's core processes. Data and Flow control rise (these workflows have branches, approvals, and awkward edge cases) and Operations rises (several people now depend on them). The pivotal question is whether the team contains one technical owner — a person comfortable with expressions, JSON, and reading an API error without flinching. With one, n8n needs no adjustment. Without one, n8n takes the same accessibility adjustments as the solo persona on Data and Flow control, and its AI drops half a point too, because the agent tooling of Chapter 23 assumes a confident builder at the keyboard.
| Platform | With technical owner | Without |
|---|---|---|
| n8n | 4.18 | 3.83 |
| Make | 3.95 | 3.95 |
| Zapier | 3.98 | 3.98 |
Verdict: conditional, and the condition is a person, not a platform. With a technical owner, n8n wins clearly: an ops team's workflows are precisely the branching, data-heavy kind where its model earns its keep, and a two-tenths margin survives reasonable re-weighting. Without one, Zapier edges Make by a nose, and the same volume tie-breaker as the solo persona applies. Notice what happened: one person's presence swung n8n by more than a third of a point. Staff — or lose staff — with that in mind, and watch the re-decision triggers below. This is the persona for which the bake-off is least optional.
You build and run automations for other people's businesses. Operations and Adoption dominate jointly: monitoring many clients' workflows is the job (Chapters 27 and 29), and your margin is the gap between what a client pays and what the platform plus your maintenance time costs (Chapters 31 and 33). One adjustment: Make's Operations rises half a point, because its team-and-workspace organization and scenario templating fit the many-clients shape unusually well (Chapters 29 and 33). Nothing flatters Zapier here — per-task costs stack across clients, already priced into its base Adoption score.
| Platform | Weighted total |
|---|---|
| n8n | 4.15 |
| Make | 4.08 |
| Zapier | 3.93 |
Verdict: split by business model, not by the score. If you run a productized or embedded agency — automation delivered inside your own offering, white-labeled, at margin — n8n's paper win is a real win: self-hosting converts platform fees from a per-client cost into fixed infrastructure (Chapter 33). If you run a classic managed-automation agency where each client holds their own account, Make is the working answer despite the lower total: the client owns the bill, the hand-off is clean, and your builders stay inside one visual idiom across every engagement. Zapier stays right for agencies whose clients demand it by name — not rare, given its recognition. When these totals sit within a quarter of a point, the business-model question outranks the arithmetic.
Software engineers using a workflow platform as internal glue, or as a component behind a product feature. Data, Flow control, and Operations dominate; Connectivity barely registers because this team codes around catalog gaps as a matter of routine. Two adjustments, both for n8n: Connectivity rises half a point (the HTTP node, code steps, and custom nodes of Chapters 9 and 10 are fully exploitable here, erasing the catalog gap), and Operations rises a full point (workflow definitions in version control, self-hosting inside infrastructure the team already runs, real staging environments — Chapters 29 and 32 — with the self-hosting burden landing on people who already operate services).
| Platform | Weighted total |
|---|---|
| n8n | 4.50 |
| Make | 3.95 |
| Zapier | 3.78 |
Verdict: n8n, decisively — the least contested call in this chapter. It is the only one of the three that treats "developer" as its primary user, and every adjustment this persona can legitimately claim lands on an n8n strength. The one honest counter-case is narrow but important: a team whose real goal is automation owned by non-engineers, so that engineering stops being the bottleneck for every small integration, is not this persona at all. That team is the SMB ops team, and it should read that verdict instead.
An organization where data residency, audit trails, access control, and vendor risk review are gating requirements. Operations and Adoption carry sixty percent of the weight between them, and inside those areas, hosting and compliance (Chapter 32) and governance (Chapter 29) matter more than price. The decisive question is which of two regimes you are in — and the two produce different kinds of answer.
Regime one: data residency required. Data residency means regulation or contract constrains where your data physically and jurisdictionally lives; in its strict form, the data may not even transit infrastructure you do not control. This is not a scoring situation — it is the first red line. Only self-hosted n8n survives it. For completeness, its total under this column (with Operations nudged up half a point, since a platform team running n8n inside your boundary is what the regime demands) is 4.30, but the other two columns are empty because those platforms were never eligible, not because they scored poorly. When a matrix contains a red line in disguise, say so plainly; dressing a disqualification up as a close score comparison misleads every stakeholder who later reads the memo.
Regime two: attestation-first. Data may live in a vendor's cloud, provided the vendor proves its controls with recognized attestations. Now all three columns are live, with adjustments: Zapier's Adoption rises half a point (enterprise contracting flattens the cost objection that drove its base score), while self-hosted n8n's Operations and Adoption each drop half a point — because in this regime, every control a vendor's attestation would have covered instead becomes evidence your team has to produce for your auditors.
| Platform | Weighted total (attestation regime) |
|---|---|
| n8n | 3.85 |
| Make | 3.98 |
| Zapier | 3.93 |
Verdict: the matrix declines to decide, which is the correct output. Thirteen hundredths separate first from last; the instrument is telling you the real decision lives in your specific obligations, not in general capability. In practice, Zapier's admin, governance, and catalog surface on its upper tiers usually carries this persona; Make takes it when cost-at-volume dominates procurement; and n8n stays on the table wherever an internal platform team already produces control evidence for other systems. Verify the current compliance documentation of all three against your actual obligations before deciding — this is the fastest-moving surface in the whole comparison, and Chapter 32's checklist is the way through it.
Tip: When a stakeholder rejects one of these verdicts, do not hand them the verdict again — hand them the weights row. "Which of these six numbers is wrong for us?" turns an argument about taste into an argument about priorities, and priorities arguments actually converge. Most people who reject a conclusion are objecting to a weight they never saw.
When totals land within a few tenths — as they did for the solo, the SMB-without-owner, and the regulated-attestation cases — the matrix has done its job: it has told you the platforms are comparably fit, and that you should decide on the questions it deliberately leaves out. Apply these in order and stop at the first that clearly separates the finalists.
The matrix narrows three candidates to two. The bake-off — building the same real automation on both finalists and comparing the lived experience — catches everything paper analysis cannot: the pricing surprise, the connector that technically exists but lacks the one action you needed, the editor your actual team actually enjoys sitting in front of.
Reuse Chapter 5's pilot worksheet — the three-question screen (a clear starting event, structured data, a rule-based action) plus the safety screen — but promote the difficulty by one notch. A bake-off pilot should be real but not critical: a genuine business process with a trigger, at least one branch, one data transformation, and one external system, whose failure during the pilot would be annoying rather than damaging. Lead capture to follow-up (Chapter 36, Worked Project 1) is the canonical shape and a safe default. A pilot that exercises nothing teaches nothing; one that could take down your billing on a bad afternoon teaches the wrong lesson.
The same person or pair builds the automation on both platforms and keeps a running log:
Run both builds on real or realistic traffic, ideally in shadow mode — receiving genuine inputs but writing to test destinations, so a failure costs nothing (Chapter 26). Then break them on purpose, because the most valuable hour of the bake-off is the one where things go wrong on your schedule instead of the platform's:
A short scorecard, filled in by the people who actually did the work rather than the people who will sign the invoice.
| Dimension | Finalist A | Finalist B |
|---|---|---|
| Time to working build | ||
| Workaround count and ugliness | ||
| Allowance consumed (build plus one week) | ||
| Time to notice the injected failure | ||
| Effort to diagnose and replay | ||
| Builder's subjective preference |
That last row is not filler: the platform your team likes is the one your team will keep maintaining, and Chapter 27 established what happens to automations nobody wants to open.
Tip: Do not bake off all three finalists. A three-way pilot takes half again as long and almost never changes the outcome, because the matrix eliminated the third candidate for reasons two more weeks of building will not overturn. If your matrix could not narrow the field to two, the problem is not that you need more pilots — it is that your weights are still undecided. Fix the weights first, then bake off the two survivors.
A decision that lives only in one person's head gets relitigated forever. Write it down as a one-page memo with seven parts:
Defending the memo is mostly pre-emption. The objection you will hear, in some form, is "why not the platform I already know?" — and the answer is never "because yours is worse." It is: "Here are the six weights we used; here is the total under them; if you think one is wrong for us, propose a different number and we will re-run it in front of you." Most objections evaporate on contact with that offer, because most objectors carry a preference, not a weight. The rare stakeholder who accepts it and hands back a defensible re-weighting has just improved your decision — thank them and re-run it.
File the memo alongside your workflow documentation (Chapter 29's change-management practices). Its second and more important audience is whoever inherits these automations two years from now and wonders why on earth this platform was chosen.
A platform choice is a decision with a shelf life, not a marriage. Reopen it — meaning re-run the matrix with fresh scores, which does not automatically mean migrate — whenever any of the following fires.
Pricing events. Your vendor changes its pricing model, not merely its prices: a new unit of billing, a feature sliding between tiers, usage-based components appearing where there were none. Model changes redraw Chapter 31's cost curves, and a platform that won on economics can quietly stop winning. Recheck within a billing cycle.
Volume growth. You cross a threshold well above your original projection — sustained traffic at roughly triple the level you scored the decision at is a sound trigger. Per-run pricing that was comfortable at launch may now dominate your bill; conversely, self-hosting overhead that made no sense at low volume may now be trivially worth it. Chapter 30's scale patterns tell you what to test before you move.
Compliance events. A new certification demand from a large customer, expansion into a jurisdiction with residency rules, a security incident (yours or your vendor's), or a change in a vendor's attestation status. Any of these can convert a weight into a red line overnight — and red lines, unlike scores, are not open to negotiation.
Team events. The technical owner leaves; the platform team maintaining your self-hosted n8n is reassigned. The SMB matrix showed a single person's presence moving a total by more than a third of a point. Their departure moves it right back.
Catalog and product events. The connector your core workflow depends on is deprecated or degraded (Chapter 6); a capability you scored as weak ships and matures — the AI row especially deserves a fresh look at least yearly; your vendor is acquired or announces a direction change that touches your critical path.
Strategic events. You start embedding automation inside your own product — reread Chapter 33, because embedding runs on different economics than internal use — or you acquire a company running a different platform and inherit Chapter 34's coexistence question.
Absent any trigger at all, put a yearly review on the calendar anyway: one hour to re-score the matrix against current reality. Most years it will simply confirm the incumbent, and that confirmation is worth the hour, because it converts "we use Zapier because we always have" into "we use Zapier because it still wins under our weights" — the whole difference between a habit and a decision.
That is the entire framework: red lines checked first; six areas scored honestly with the evidence cited; weights that admit who you are; adjustments declared before the totals; ties broken on maintenance, margin, depth, and exit; two weeks of deliberate contact with reality; one page that shows its work; and a standing date to confirm the answer is still true. The three platforms will keep changing under you. The instrument keeps working.