A Cheaper Zapier: the Arithmetic Nobody Shows You
Tasks, credits and executions are not the same unit, and that is where the bill grows. Verified Zapier, Make and n8n pricing, and the sum that settles it.
Tasks, credits and executions measure different things
Price comparison between automation platforms misleads because each one sells a different unit, and the units do not convert. Zapier bills per task. A task counts each time a Zap completes an action that moves data. The detail that changes the arithmetic: triggers, filters and built-in tools do not consume tasks. A Zap with a trigger, two filters and one action costs one task per run, not four. Make bills per credit, and a credit is consumed by every module that executes inside a scenario. Triggers count. Filters count. Routers count. The same flow that cost one task on Zapier can cost four credits on Make. n8n bills per execution on its cloud plan: one complete run of the workflow, however many nodes it holds. A forty-node workflow consumes one execution. This is why comparing unit prices without looking at the shape of your flows gives wrong answers in both directions.
The prices, verified
The figures below are list prices checked in September 2026, in US dollars, which is the currency all three publish in. They change often: confirm at source before deciding. Zapier has a free plan with 100 tasks a month. Professional starts at $29.99 monthly with 750 tasks and scales in tiers up to two million tasks a month. Team is around $69 billed annually. Make has a free plan with 1,000 credits. Core sits around $9 and Pro around $16, and every paid plan starts at 10,000 credits a month. n8n cloud starts at $20 a month billed annually with 2,500 executions. Pro is $50 with 10,000 executions. The ratio that jumps out: a Make credit costs about $0.0016 and a Zapier task about $0.04. Twenty-five times more per unit. Except, as we saw, Make consumes more units for the same work.
| Zapier | Make | n8n | |
|---|---|---|---|
| Billed unit | Task (acção) | Credit (módulo) | Execution (workflow) |
| Do triggers and filters count? | Não | Sim | Não |
| Free plan | 100 tasks/mês | 1 000 credits/mês | Community self-hosted |
| Entry paid plan | 29,99 USD (750 tasks) | ~9 USD (10 000 credits) | 20 USD (2 500 exec.) |
| Next tier | ~69 USD (Team) | ~16 USD (Pro) | 50 USD (10 000 exec.) |
| Self-hosting | Não | Não | Sim |
Where Make wins and where it does not
Make wins clearly on simple, high-volume flows: few modules, many runs. A three-module scenario running ten thousand times a month consumes thirty thousand credits. On Zapier the same flow with one useful action consumes ten thousand tasks, which cost substantially more. Make loses on flows with a lot of conditional logic. Every router, filter and iterator spends a credit per pass. A scenario with branches and aggregation can burn fifteen credits per run without moving more data than one that burns three. The practical consequence, which almost nobody states: on Make it pays to design scenarios to use fewer modules, and that pushes towards less readable flows. You are optimising the design for the pricing grid rather than for whoever maintains it a year from now. Zapier is expensive but predictable. For a non-technical team running twenty small automations, that predictability is worth real money.
Self-hosted n8n: the real cost, not the marketing one
The n8n Community Edition is free software with no cap on executions or steps. What you pay for is the server. For moderate volumes a small VPS in the $4 to $7 a month range is enough, and that is where the number everyone repeats comes from: unlimited automation for under ten dollars. The number is correct and incomplete. What it leaves out: First, time. Installing is quick; running it is not. Updates, certificates, tested backups, monitoring so you learn the service is down before the client tells you. If nobody in the company does that, the cost is not zero. It is the cost of hiring someone who will. Second, sizing. Workflows with heavy processing, many parallel workers or long execution-history retention eat memory quickly. A serious production install sits well above an entry VPS. Third, the licence. The Community Edition is fair-code, not MIT. Internal use inside your own company is covered; reselling hosted automation to clients as a service is not necessarily. If that is the plan, read the licence before building on it. That said: for a company running tens of thousands of executions a month with someone who can administer a Linux server, the gap against Zapier is not a percentage. It is an order of magnitude.
AlphaVPS
European VPS with NVMe and Docker ready, where we run our own n8n instances.
Affiliate link: we earn a commission if you subscribe, at no extra cost to you.
The sum that settles it
Before switching, run this with your numbers rather than the article's. Count your monthly executions across every flow. Count the useful steps in each one — steps that move data, not filters. Multiply against each platform's grid. Add the migration time, which for a dozen automations is usually days rather than hours, because integrations are not equivalent across platforms and there is always one that does not exist on the other side. The rule of thumb that has served us: below a few hundred runs a month, the cheapest platform is whichever one the person maintaining it works fastest in, and the bill difference is irrelevant next to that person's cost. Between a few thousand and a few tens of thousands, Make usually wins on simple flows. Above that, with in-house technical skill, self-hosting wins by a wide margin. There is a cost that rarely makes it onto the spreadsheet and should: lock-in. Three hundred automations on a proprietary platform are three hundred things that do not leave without being rebuilt.
When leaving Zapier is the wrong call
We say this to clients often enough that it is worth writing down. If the monthly Zapier bill is less than half a day of technical work, the annual saving does not pay for the migration. If the person building the automations is in marketing and nobody is available to run a server, self-hosting turns a solved problem into an open one. If the connectors you depend on exist in Zapier and not in n8n, you will end up hand-writing HTTP calls for tools that used to be one click. Most of the migrations we have turned down were for one of those three reasons. The right automation is the one that still works when the person who built it goes on holiday, not the one that looks better in a pricing table. There is a middle path that gets overlooked: keep Zapier for the handful of flows that depend on connectors nobody else has, and move the high-volume, low-complexity ones to a cheaper platform. Splitting a stack is not elegant, but it is often the cheapest honest answer, and it avoids a migration whose only justification was making the diagram tidy.
The connectors that do not exist on the other side
The part of a migration that blows the schedule is not the complex flows. It is the integrations that existed in one place and do not exist in the other. Zapier built its advantage in supported applications over more than a decade. Niche tools, local business software, platforms with customers in a single country — plenty of things have a Zapier connector and no connector anywhere else. When you change platform, each of those becomes a hand-written HTTP call against the vendor's API. That is perfectly workable and it is what we do regularly. What is not workable is doing it without budgeting the time. An HTTP call means reading the API documentation, handling authentication, dealing with pagination, deciding what happens when the request fails, and testing all of it. Where there was a prebuilt block there is now code somebody has to maintain when the vendor changes the API. The test we run before advising a migration is this: list every application involved in the current flows and look each one up on the destination platform. If more than a quarter have no native connector, the project stops being a migration and becomes development, with the budget and calendar that implies. One detail always surfaces late: inbound webhooks. External services configured to call a Zapier URL have to be reconfigured one at a time, and some of them live in systems nobody at the company still has access to.
Frequently Asked Questions
What is the cheapest Zapier alternative?
On list price alone, self-hosted n8n: the software is free and you pay only for the server, from roughly $4 to $7 a month on a small VPS. Among managed platforms, Make has the cheapest unit. But the cheapest unit is not the cheapest bill: it depends how many modules your flows execute.
Why did my Make bill rise without more customers?
Almost always because someone added logic to the scenarios. Every router, filter or iterator consumes a credit per pass. Adding two conditions to a scenario running ten thousand times a month adds twenty thousand credits without processing a single extra record.
Is self-hosted n8n really free?
The software is free and does not cap executions. The server, the backups and the maintenance time are not. The Community Edition is also fair-code rather than MIT: internal use is covered, reselling hosted automation to clients may not be. If that is the plan, read the licence first.
How long does migrating from Zapier to n8n take?
There is no automatic import. Every flow is rebuilt. For a dozen simple automations count on days rather than hours, and most of that time goes on connectors that exist on one side and not the other, which become hand-written HTTP calls.
What about data? Does self-hosting help with GDPR?
It helps with two concrete things: you know where the data physically sits, and you cut the number of processors you have to declare. It exempts you from nothing. You still need a legal basis, a record of processing and appropriate technical measures, and now the backups and server access control are yours.