n8n or Zapier for Agency Ops: Which One Survives Client Volume

Because it is answering a different one. Go and read the pages ranking for n8n versus Zapier right now and you will find integration counts, a pricing table, a note about how n8n is better for developers, and a verdict. One of the strongest is around 5,500 words and covers twelve sections, and not one of them is about running the same automation for more than one company.

That is not laziness. It is who the page is for. A comparison written for an ops manager at a single company is genuinely answered by connector counts and a learning curve, because that person builds a workflow once and runs it forever. You build it once and then deploy it forty times, keep forty sets of credentials alive, and answer for it when client nineteen's version stops firing on a Tuesday.

The multiplier changes which constraints bind. Connector count stops mattering the moment both platforms cover your stack, and it usually does. What starts mattering is cloning, credential isolation, concurrency, who is allowed to hold whose data, and how you find out something broke without logging into forty dashboards. Every one of those is documented. None of them shows up on a comparison table.

The billing units are different in a way that only bites at volume. Zapier counts a task when it successfully completes an action, and triggers, polling and built-in steps like Filter and Formatter are free. n8n counts an execution, which is a single run of your entire workflow no matter how many nodes are in it.

At one client this is close to noise. Take a six-step workflow where four steps are billable actions, running 1,000 times a month. That is 4,000 Zapier tasks or 1,000 n8n executions. Fine either way.

Now run it for forty clients. On Zapier you need roughly 160,000 tasks, but you cannot buy them as one block, and the reason is the next section. Each client sits on their own account and needs their own plan covering 4,000 tasks a month, which is Professional at the 5,000-task tier, $89 a month on annual billing. Forty of those is $3,560 a month. On n8n the same work is 40,000 executions on one instance, which is exactly the Business plan at 667 euros a month.

That is a 5.3x gap on the platform line, and it is the single strongest argument for n8n at agency scale. It is also the argument every n8n reseller stops at, so keep reading, because the money is the easy part.

Read this before you design anything, because it settles a question most agencies answer by accident and then discover eighteen months in.

Zapier's terms restrict you to your own internal business operations and prohibit reselling, subleasing, sublicensing, white-labeling, and operating a service bureau or time-sharing service. That is not a footnote for an agency. It means the tidy setup where you hold every client's Zaps in your account and bill them a monthly fee is the thing the clause exists to stop. Zapier's own staff answer this directly in their community forum, recommending that agencies work with clients who have their own account, owned and paid for by them.

So the forty accounts are not a pricing accident. They are the architecture Zapier intends, and the $3,560 is what that architecture costs.

n8n draws the same line somewhere else. The Sustainable Use License permits use and modification for your own internal business purposes, and the docs are unusually clear about the edges: providing consulting services is named as allowed, while white-labeling n8n for customers and hosting n8n and charging access fees are named as not. Building automations for a client and handing them over is squarely fine. Running one instance that holds forty clients' credentials and charging them for access to it is the case that needs a separate commercial agreement.

This is the part the shops selling n8n builds do not put on their services page, and it is worth being blunt about why. The self-hosted cost advantage in the chart above assumes an architecture that, past a certain point, is not covered by the free license. If your plan is to become the automation vendor rather than the agency that builds automations, budget for the conversation with n8n rather than finding out later.

This is the job. One workflow, forty near-identical copies, each pointing at a different client's CRM, inbox and sheet. Then you improve it and have to push that improvement everywhere without breaking the nineteen clients who had a small customization.

Zapier's answer is copying. You duplicate a Zap, reconnect the accounts, and adjust. It works and it is fast for the first few. What it does not give you is any way to express that these forty Zaps are the same workflow, so there is no upgrade path: version forty-one of your onboarding automation is forty separate edits. Version history exists and rolls back per Zap, and on the Professional plan it keeps versions created within one month. Six months on Team, a year on Enterprise. If a client asks in March what changed in their workflow in December, on Professional the answer is that nobody knows.

n8n's answer is source control and environments, which back your instance with a git repository and let you push and pull between environments. This is the real structural advantage and it comes with two conditions worth knowing before you plan around it. It is available on Business and Enterprise plans, so the 667 euro tier is where it starts. And git carries workflows, tags, variables and credential stubs rather than credential values, so after every pull somebody still populates the credentials by hand. Forty clients means forty credential sets that live outside the thing doing your versioning.

The honest summary is that n8n gives you a real deployment pipeline and Zapier gives you copy and paste, and that n8n's pipeline still leaves the per-client part manual. If you want the shape of what gets cloned before you pick either, our ready-made automation workflow templates are the same JSON either platform imports.

Nothing, until Monday at 9am, when a scheduled trigger fires for every client in the same minute.

n8n Cloud caps concurrent production executions per plan: five on Starter, twenty on Pro, and 200 or more on Enterprise. Anything over the cap is not dropped. It queues and runs in FIFO order as capacity frees up, which is the right behavior and also the thing that surprises people, because the workflow that looks stuck is simply waiting. Two details matter operationally. Concurrency applies only to production executions started from a webhook or trigger node, so manual runs, sub-workflow calls and error executions are exempt. And a queued execution cannot be retried, so your retry logic has a hole in it exactly where the queue is deepest.

That exemption is a genuine architecture lever rather than trivia. A parent workflow that calls a sub-workflow per client consumes one concurrency slot instead of forty, because the sub-workflow executions do not count against the cap. That single fact is worth more than most of the feature comparison, and it is buried in a docs page about deployment.

Zapier has no equivalent ceiling you are budgeting against, because the work is spread across forty separate accounts with their own limits. Fragmentation solves the concurrency problem by accident. It creates every other problem in this post.

Self-hosting n8n moves the ceiling onto hardware you own, which sounds like it removes the limit and actually just makes it yours. Now the queue depth, the worker count and the database under it are your operational problem at 9am on Monday.

Here is the finding that changed how we set these up, and it runs against the story everybody tells about self-hosting.

Self-hosted n8n enables pruning by default and ships with EXECUTIONS_DATA_MAX_AGE at 336 hours, which is 14 days, and a prune count of 10,000 executions. Zapier, by its own documentation, keeps run history for 60 days. So the default memory of a self-hosted instance, the one you chose partly to own your own logs, is roughly a quarter of the SaaS product you left. Nobody tells you this, because it contradicts the reason you were given for self-hosting.

It is a default rather than a limit, which is the whole point. Two environment variables fix it, and annotated executions are never pruned at all, so a tagged run survives regardless. But at forty clients that 10,000-execution cap arrives fast. Forty clients at 1,000 runs a month is 40,000 executions, which fills the default count in about a week, and now the client asking what happened last month is asking about data that has already gone.

Where n8n genuinely wins is the shape of the monitoring. One instance means one place to look. You point every client workflow at the same error workflow in its settings, and one Error Trigger handler catches the lot, so forty clients share a single alerting path that posts to one channel with the client name attached. On Zapier, forty client-owned accounts means forty dashboards, forty sets of notification settings, and no cross-account view unless you are on Enterprise. Managing that is the password-manager-and-private-windows routine that Zapier solution partners describe in that same community thread, and it does not get better with practice.

Neither platform solves the failure that produces no error at all, where a trigger quietly stops firing and nothing lands in any history. That one is the same on every no-code platform and it is on you to build the heartbeat that catches silence.

n8n, on the numbers, and only if somebody owns it.

That second clause is the whole answer. n8n wins the cost comparison by roughly five times, wins deployment outright once you are on Business, and wins observability by having one place to look instead of forty. Those are real and they compound with every client you add. What it hands you in exchange is an instance to run, a queue to reason about, a retention default that is worse than the thing you left, and a license boundary you have to stay on the right side of. Every one of those is a job. If nobody at your agency has that job, n8n at forty clients degrades into forty unmonitored workflows on a server nobody has patched, which is strictly worse than forty boring Zapier accounts.

Zapier survives client volume fine. It just survives it expensively and in fragments. The fragmentation is not a bug you can engineer around either, because it is what the terms require. If your forty clients each want to own their automation, pay for it themselves, and keep it when they leave you, Zapier's architecture is not a compromise. It is the correct answer, and the $3,560 is buying you the absence of an operations job.

The split we use is boring and it holds. Client-owned, low-stakes, few runs a month, and the client wants to poke at it themselves: Zapier, on their account, and hand them the login. High volume, needs to be identical across clients, needs a real audit trail, or touches money: n8n, on infrastructure with an owner and a monitoring story. Most agencies we talk to end up running both, and that is not a failure to decide.

One thing to be clear about, since this whole post is about platform limits. Neither of these is the same decision as no code against custom automation, which turns on reliability rather than cost and has a completely different threshold. Pick your platform here. Pick your substrate there.

Three questions, in this order, and they take an afternoon.

1. Who is going to own the client's account in two years. If the honest answer is the client, you are on Zapier and the rest of the analysis is moot. If the answer is you, and you intend to charge for that, read both licenses again with your actual model in front of you.
2. How many of your workflows are genuinely identical across clients rather than merely similar. Count them, because agencies consistently overestimate this. If it is three workflows with forty variants each, n8n's deployment pipeline pays for itself immediately. If it is forty bespoke workflows that happen to be in the same category, you have no cloning problem to solve and the main n8n advantage evaporates.
3. Who gets paged when it breaks at 2am. Name them. Not the team. The person. If that name does not exist yet, hire before you migrate, or hire an agency automation consultant who carries it for you, because a platform migration does not create an operator.

That is the work we do in a 10x audit before anybody touches a workflow, and the answer is frequently that the platform was never the problem. If you want the arithmetic on what building and running this actually costs, we published the full cost of automating agency operations separately, and it holds regardless of which of these two you land on.