n8n vs Zapier vs Make

Zapier and Make are hosted software. You sign up, connect your accounts and build, and the vendor runs everything else: servers, scaling, connector maintenance, security patching and uptime. Neither can be installed on your own infrastructure. For many organisations that is the right trade: no operational work at all, in exchange for little say over where processing happens and pricing that is entirely the vendor’s to set.

n8n offers both arrangements. Its cloud product is hosted software like the other two. Its self-hosted form runs as a container or a Node.js application on infrastructure you control, backed by a database, which for anything serious should be PostgreSQL rather than the default file-based option. For higher volumes it runs in queue mode, where a main process hands executions to separate worker processes through Redis so that capacity can be added by starting more workers. That is the property that changes the comparison: the same product can run beside your systems, inside your network, under your own backup and monitoring regime.

The licence needs stating precisely, because n8n is often described as open source and that is not accurate. It is source-available under the Sustainable Use License, which n8n calls fair-code. In practice you can read the source, modify it and run it free of charge for your own organisation’s internal business purposes. What the licence restricts is commercial redistribution: selling n8n, or offering it to others as a hosted service, is outside the free use and needs a commercial agreement with n8n. Some features that larger organisations care about, such as enterprise single sign-on and Git-backed environments, are licensed as paid features even when you host the software yourself.

For a company automating its own operations, the licence is rarely a constraint. It matters if you intend to host n8n and give clients access to it, to embed it in a product you sell, or to do anything else that sits near the line between internal use and providing a service. In those cases read the licence text and n8n’s own guidance, and have counsel look at your specific plan, rather than relying on a summary, including this one.

We will not quote prices, plan names or allowances, because all three have changed them repeatedly. What is stable enough to reason about is the unit each platform counts, because that decides how your bill behaves as the workflows grow. Check the current rate cards for the figures.

Zapier counts tasks. Broadly, each action a Zap completes is a task, and the trigger that starts it is not. A Zap with a trigger and five actions that runs a thousand times uses in the region of five thousand tasks. Cost therefore grows with steps multiplied by runs, and every extra step added for tidiness, a formatting step, a lookup, a logging action, is paid for on every run. The meter rewards short Zaps, so design with that in mind. How often polling triggers check for new data can also depend on the plan.

Make counts each module that runs, a unit it has called operations and more recently credits. The detail that catches people is lists: when an iterator splits an order into twenty lines and each line then passes through three modules, that single order consumes usage for every line at every module. A scheduled scenario that checks for new data can also consume usage on a check that finds nothing, so a scenario polling every minute carries a cost floor whether or not anything happens. The unit can be cheap, and it is more sensitive to the shape of a scenario than either alternative.

n8n’s cloud counts executions: one run of a workflow, whatever its length. A thirty-step workflow costs the same per run as a three-step one, so steps for validation, logging and error handling are free to add. The self-hosted community edition has no usage fee at all. You pay instead for servers, the database, monitoring and, above all, the engineering time to run it, which for a small team can exceed the subscription it replaced. Paid editions add features and support, and you should check how they are licensed for your case.

The trap is comparing headline plan prices. Instead, list the workflows, their steps, how often each runs and how many records each run processes, and price that on each current rate card. Add what no pricing page shows, chiefly the engineering hours a self-hosted instance needs. Then look at growth, because a meter that is trivial today and linear in volume becomes a large line the year the business doubles.

Every automation starts simple. What matters is the fifteenth requirement: an exception for one type of customer, a retry for a flaky API, a loop over records, a lookup that sometimes finds nothing and sometimes finds two. That is where the three separate, so trial your hardest real workflow on each, not your easiest.

Zapier handles branching through Paths and Filters, repetition through a looping step, and reuse through sub-Zaps. All of it works. The limit is legibility: a Zap is a vertical list, and once branches nest inside branches the logic becomes hard to hold in your head or to explain to a colleague. Its code steps run JavaScript or Python in a restricted environment with time and memory limits and little room for third-party libraries, which is enough for a calculation or a reshaped object and not for anything heavier.

Make’s routers send records down several routes with a filter on each, iterators and aggregators turn lists into individual records and back again, and a large library of functions handles dates, text, maths and arrays inside the mapping itself. Its distinctive strength is error handling: you attach a handler to the specific module that might fail and choose whether the run resumes with a substitute value, ignores the record, breaks and stores the run for retry, or rolls back. Make leans on that visual toolkit instead of code, and when logic gets heavy the usual answer is to call an endpoint you host.

n8n treats a workflow as a graph of nodes that each process a list of items, with IF, Switch and Merge for control flow and sub-workflows that behave like function calls. n8n is itself a Node.js application, and its Code node runs JavaScript or Python anywhere in the graph; on a self-hosted instance you can allow external npm modules, and you can write custom nodes in TypeScript for internal systems. Failure handling is per node, with retries and the option to route errors down their own output, plus an error workflow, set in each workflow’s settings, that runs when it fails, which is where alerting usually lives.

Whatever you choose, the difference between a demonstration and a production automation is the bad day: an API that is down, a rate limit, a malformed record, a webhook delivered twice. Ask three things of any design. Will someone know it failed, within minutes rather than when a customer complains? Can the failed part be retried without rerunning everything? And is each step safe to repeat, so that a retry does not create a second invoice or send a second email? That last property is your responsibility on all three platforms, and it is the one most often missing.

All three platforms have added AI in roughly the same three forms: steps inside a workflow that call a language model to classify, extract, summarise or draft; assistants that help you build a workflow from a plain description; and agent features, where a model decides which actions to take and uses the platform’s connectors as its tools. The specifics change monthly, so check what each platform offers today.

On Zapier and Make, AI runs as part of the hosted service, either through the vendor’s own model access or through your API key for a model provider. Their agent products have one real advantage that is easy to underrate: an agent that can call any of a very large number of already-authenticated actions can do useful work in a business’s existing tools with very little set-up. The cost is that your data travels to the platform vendor and on to the model provider, and the agent’s reasoning happens inside a product you cannot inspect closely.

n8n’s AI nodes are built on LangChain, the framework, and expose its parts directly: an agent node, a choice of chat model, memory, tools, vector stores and document loaders for retrieval. Because the workflow around the model is ordinary n8n, you can put validation, approval and logging before and after every model call. On a self-hosted instance the model itself can be one you run on your own hardware, which is the only arrangement of the three in which a retrieval workflow over sensitive documents never sends text to an outside provider.

A word of caution that applies to all three. An AI agent that can take actions in your systems is a different category of risk from a step that drafts a paragraph for a person to read. Text the model reads, such as an inbound email or a support ticket, can contain instructions written by somebody hostile. Keep each agent’s tools as narrow as the job allows, require a human approval for anything consequential, such as refunds, deletions or messages to customers, log every action it takes, and test it with deliberately awkward input before it goes near production. The platforms make it very easy to give a model broad access. That ease is the risk.

An automation platform holds working credentials to everything it connects: the CRM, the finance system, the shared inbox, the file store, the payment provider. That makes it one of the most security-sensitive systems a business runs, though it is rarely chosen as one.

On the hosted options, Zapier, Make and n8n’s cloud, your data passes through the vendor and the run history it stores, which can contain personal data from every record that went through a workflow. The vendor’s security posture becomes part of yours. Check the data-processing terms, where processing and storage happen, how long run history is kept and whether you can shorten it, which sub-processors are involved, and that the vendor can supply the security reports your procurement needs. Make’s regional hosting zones give some choice of location. Zapier and n8n’s cloud decide the location for you, so confirm it suits your obligations.

Self-hosted n8n moves the data under your control and moves the whole security burden with it. Keep the editor off the public internet, behind single sign-on or a VPN, and expose only the webhook endpoints that outside systems genuinely need to reach. Upgrade promptly: n8n, like any widely deployed software, publishes security advisories that call for urgent upgrades, and an unpatched instance holding every credential the business has is an attractive target. Back up the database and, separately, the encryption key that protects stored credentials. Lose the key and every credential must be re-entered by hand; leak it alongside a database copy and every credential is exposed. Set execution-data retention so that personal data from months of runs is not sitting in the database indefinitely.

Residency is a property of every hop, not of the platform alone. A self-hosted n8n instance in your own data centre does not keep data local if a workflow sends records to a hosted AI model or a SaaS tool in another region. Map where each workflow sends data and judge residency on the whole path.

The most common failure we are asked to untangle has nothing to do with which platform was chosen. It is an automation estate that grew one workflow at a time, built by whoever needed it, with no inventory, no named owners and no description of what each workflow is for. The person who built the important ones has left. A critical connection runs under a former employee’s personal login. Changing one workflow quietly breaks another that depended on a field it renamed. Every platform permits this, and the easiest platform permits it fastest.

Zapier is the most exposed to that pattern because it is the most accessible, which is also its main strength. The remedies are organisational: a shared team account, connections authorised by service accounts that do not leave when people do, a naming convention, an owner recorded for every live Zap, and a quarterly review to switch off what nothing depends on.

Make needs the same discipline, and its canvas helps, because a scenario is easier for a second person to read than a long step list. Promotion from a test scenario to the live one is manual, so agree who may edit live scenarios and how a change is checked first.

n8n comes closest to ordinary engineering practice, with workflows as JSON that can be committed, reviewed and deployed through environments. That advantage only exists if the team uses it. A self-hosted instance where everyone edits production directly, with no export, no review and no record of who changed what, is no better maintained than a Zapier account, and it adds a server to the list of things nobody owns.

The rule for all three is short. Anything business-critical needs a named owner, a sentence describing what it does and why, an alert when it fails, and a known answer to what happens to the business while it is broken. If you cannot write those four things down for a workflow, it is not ready to be relied on, whatever it runs on.

These platforms are not a phase a business grows out of. Most organisations should run one indefinitely for the long tail of simple connections: a form that creates a CRM record, a signed contract that notifies finance, a new hire that triggers account requests. Writing and maintaining software for each of those would be a poor use of money. The real question is which particular workflows should leave, and when.

The signals are consistent. A workflow should move when its failure stops revenue or breaks a promise to customers, and it needs the testing, review and monitoring that production software gets. It should move when its logic has become mostly code steps held together by a visual editor, because at that point the platform is adding friction rather than removing it. It should move when the platform bill for that one workflow exceeds the cost of maintaining a small service that does the same job. And it should move when it needs things the platforms handle poorly: strict ordering, transactions that must succeed or fail as a whole, throughput or latency that customers notice, or state that persists across many runs.

The last signal is the clearest. If customers now interact with the workflow directly, it has become part of your product, and products need version control, tests, deployment pipelines and engineers who can reason about them. Leaving a product feature inside an automation platform because that is where it started is how businesses end up with their most important logic in the place least suited to it.

Custom does not have to mean large. Usually it is a small service built through ordinary API development: an endpoint that receives the event, a queue so that bursts do not overwhelm anything, retries with backoff, steps designed to be safe to repeat, structured logs and an alert. The platform often stays as the trigger layer, catching the event from a SaaS tool and handing it to your service, which keeps the platform’s connector catalogue and moves the critical logic into code you can test. That hybrid is frequently the cheapest end state, and it can be reached one workflow at a time.

Be equally clear about when not to move. A workflow that runs reliably, costs little and changes rarely gains nothing from being rewritten as software, however much tidier an engineer would find the result, and the rewrite adds code that someone must maintain for years.

The same applies to AI. When a model sits at the centre of a workflow, with retrieval over a large and changing document set, measurement of answer quality, cost control per request or latency customers notice, a platform node makes a good prototype and usually a poor permanent home.

There is no meaningful migration path between these three. They differ in data model, expression language, connector behaviour, error handling and how they count usage, so moving from one to another means rebuilding each workflow on the new platform and checking every step. Plan for a rebuild and you will estimate correctly.

What survives is more valuable than the workflows themselves: the understanding of each process, the field mappings, the list of edge cases discovered the hard way, and the test cases that prove a workflow behaves. Before moving anything, build an inventory of every live workflow, what triggers it, what it touches, who owns it and how often it runs. That inventory is usually the first time anyone has seen the whole estate, and it routinely shows workflows that can simply be switched off rather than moved.

Move one workflow at a time and run old and new in parallel where you safely can, comparing outputs, before switching the trigger. Watch for the details that cause incidents: webhook URLs registered in outside systems that must be repointed, credentials that must be authorised again under the right account, and the window in which both versions are live and could act on the same record twice. Disable the old workflow rather than deleting it, and keep it for a few weeks as a reference.

Moving a workflow into code follows the same discipline, with one advantage: the platform can stay as the trigger while your service takes over the logic, so the systems on either side never notice. Moving to self-hosted n8n adds a step before the first workflow arrives: stand the instance up properly, with backups, a safely stored encryption key, monitoring and access control.

Finally, be honest about the reason. A modest saving on a subscription rarely pays for rebuilding dozens of working automations, and the risk of a missed edge case lands on real customers. Platform migrations earn their cost when the current tool genuinely cannot do what the business now needs, when the data must move under your control, or when volume has made the meter the problem. Otherwise, tidy the estate you have.