What n8n, Zapier, and Make Really Cost at 100,000 Runs
By Aldridge Dagos, operations software engineer
n8n vs Zapier vs Make cost comparisons break when the rows use different units. An n8n execution can contain a whole workflow. A successful Zapier action usually counts as a task. Most Make module actions consume one credit. The same automation can show up as 100,000 units on one invoice and 500,000 on another.
I use one fixed workload to make those units visible: 100,000 workflow runs each month, with five successful non-AI actions in every run. That is a large, plain workload. It avoids AI token charges, premium app exceptions, failed-step edge cases, and vague claims about what a “typical” automation looks like.
The short version: At 100,000 monthly runs with five successful non-AI actions, n8n measures 100,000 executions, while Zapier and Make measure about 500,000 tasks or credits. On annual billing checked August 4, 2026, Zapier Professional lists $1,499 a month at 500,000 tasks and Make Pro lists $410.27 a month at 500,000 credits. n8n’s public Cloud plans do not list a 100,000-execution tier, so that workload needs a quote or a self-hosted plan. My live n8n setup is one AWS t3.medium with 60 GiB of gp3 storage and one public IPv4, a $38.96 monthly infrastructure floor before data transfer, off-site backups, labor, or a paid n8n license.
Cost map 01
One workload is billed three different ways
- n8n 100,000 executions$38.96 infra floor
- Make Pro 500,000 credits$410.27 / month
- Zapier Pro 500,000 tasks$1,499 / month
What does each platform count?
The unit is the first cost decision, not a footnote.
n8n pricing says it charges for a full workflow execution regardless of how many steps it contains. Our example produces 100,000 billable executions. A five-action run and a fifty-action run can each be one execution, though other plan limits and product terms still apply.
Zapier’s task guide defines a task as a successful action completed by a Zap. Triggers do not count as tasks, and some products or features can use more than one task. Five successful actions across 100,000 runs produce 500,000 tasks under the plain case.
Make pricing says each module action counts as one credit for most non-AI work. Five module actions across 100,000 runs produce 500,000 credits. AI and some advanced features can use credits differently, which is why this comparison keeps them out.
Here is a runnable Node.js calculation. Change the inputs when a real workflow has branches, retries, or actions that use more than one platform unit.
const monthlyRuns = 100_000;
const successfulActionsPerRun = 5;
const units = {
n8nExecutions: monthlyRuns,
zapierTasks: monthlyRuns * successfulActionsPerRun,
makeCredits: monthlyRuns * successfulActionsPerRun,
};
console.table(units);
The multiplication is simple. Finding the honest action count is not. A router may run only one branch, an error handler may add work, and a polling design may consume units without moving a record. I count from production histories when they exist. When they do not, I map the successful path and add an explicit retry assumption.
What does n8n vs Zapier vs Make cost at 100,000 monthly runs?
These prices were checked on August 4, 2026. Every figure below is in US dollars, using annual-billing monthly rates where the public selector provides them. Taxes, negotiated contracts, premium app rules, AI usage, and overages are outside this fixed example.
| Platform | Units for the example | Public price signal | What the number means |
|---|---|---|---|
| n8n Cloud | 100,000 executions | $667/month for Business at 40,000 executions | The public annual-billing tier does not cover 100,000, so the actual Cloud price needs a higher allowance or a quote |
| Zapier Professional | 500,000 tasks | $1,499/month | The annual-billing selector lists this price at 500,000 tasks |
| Make Pro | 500,000 credits | $410.27/month | The annual-billing selector lists this price at 500,000 credits |
| n8n Community Edition | 100,000 executions | $0 software license for permitted internal use | Infrastructure and ownership work remain separate costs |
n8n also lists Starter at $20 a month for 2,500 executions, Pro at $50 for 10,000, and Business at $667 for 40,000 when billed annually. Its pricing page lists a Business overage pack of 300,000 extra executions for $4,000. That makes the public page useful for unit economics, but it does not turn the 100,000 case into a neat catalog tier.
There is no universal cheapest result hiding in this table. A ten-step workflow leans toward execution billing. A one-action workflow narrows the unit gap. A company that already employs an operator may price self-hosting differently from a small owner who will carry the pager personally. Currency, contract term, app mix, support level, and growth pattern can change the answer.
Is self-hosted n8n free at this volume?
The Community Edition can have a zero-dollar software line without having a zero-cost service.
n8n’s deployment comparison says n8n Cloud handles setup and maintenance, while self-hosting requires server and security knowledge. Its Sustainable Use License permits internal business use of the Community Edition. It does not grant every commercial use, such as selling access to hosted n8n as the product. Paid Business and Enterprise features are another line when a team needs them.
I do not have to invent an infrastructure floor for this comparison. I checked the system I actually run on August 4, 2026. It is one AWS EC2 t3.medium in Northern Virginia with two vCPUs and 4 GiB of memory. Ubuntu 24.04 runs Nginx and Docker Compose. The Compose stack has n8n 2.29.10 and Watchtower in monitor-only mode, so it reports available updates but never installs them. n8n stores its data in SQLite on a named Docker volume. There is no PostgreSQL service, Redis service, worker fleet, or queue mode.
| Live AWS component | Price input | Monthly cost |
|---|---|---|
| EC2 t3.medium | 730 hours at $0.0418 | $30.51 |
| 60 GiB gp3 EBS volume | 60 GiB at $0.08 | $4.80 |
| One public IPv4 address | 730 hours at $0.005 | $3.65 |
| Base infrastructure | Compute, storage, and address | $38.96 |
Those inputs come from AWS’s current T3 instance pricing, EBS pricing, and VPC public IPv4 pricing. The 730-hour convention makes the parts comparable. The actual invoice can vary with the calendar, data transfer, taxes, and T3 surplus CPU credits.
This is a working system, not a hypothetical diagram. It held 120 workflows, 24 active, when I inspected it. The retained execution database showed 10,128 executions across about 5.8 days. That is roughly a 52,000-execution 30-day pace if the rate stays flat, not an exact monthly total because older execution records are pruned. It tells me the present machine is carrying meaningful work. It does not prove that the same single node will carry the fixed 100,000-run example without a load test.
The $38.96 figure also is not the whole service. It excludes operator labor, paid monitoring, alert delivery, the n8n paid license, support, high availability, off-site backups, snapshot storage, and data transfer. My current rollback archive sits on the same EBS volume as the application. That is useful before an update, but it is not independent disaster recovery. One host and one volume remain one failure domain.
If I later add n8n queue mode, I will be pricing a different system with PostgreSQL, Redis, and workers. Queue mode still uses one main process unless paid multi-main features are added. It can increase throughput, but it does not turn a single-host deployment into high availability by itself.
A floor is useful because it exposes the first bill. It is dangerous when someone presents it as total cost.
Where does ownership cost enter the comparison?
The invoice pays for machines. Ownership pays for the moments when machines stop behaving.
On my current stack, someone has to patch Ubuntu, Nginx, Docker, and n8n. Someone has to watch disk growth, certificate expiry, memory pressure, SQLite health, and failed executions. Watchtower only reports a new container image. I still decide when to back up, update, test, and roll back. Credentials need rotation. An incident needs a person who can decide whether to retry 20,000 jobs without duplicating customer actions. Redis, PostgreSQL, queue depth, and worker health become my problem only if I actually build that larger architecture.
That work is not imaginary because the month was quiet. It is capacity held for a future failure.
When I built an operations hub for a 53-person team, the result joined 18 accounts, 12 roles, and 9 departments without asking leaders to assemble reports by hand. The visible screen was the small part. Data rules, access boundaries, sync failures, and recovery paths decided whether the system stayed useful. The same is true when an automation tool moves from a vendor account onto your server.
The owner needs a forecast that includes cash and responsibility. The automation operator needs a service boundary, maintenance window, escalation path, and paid time for recovery. A low infrastructure number helps neither person if it quietly hands permanent on-call work to the builder.
How should you calculate the real monthly total?
Keep subscription cost and ownership cost in separate rows. That makes assumptions debatable without hiding them inside one persuasive number.
This runnable example turns operator time, incident time, and an infrastructure floor into a monthly estimate. The sample labor figures are placeholders, not market rates.
const estimate = {
awsInfrastructure: 38.96,
offSiteBackupAndMonitoring: 0,
maintenanceHours: 6,
expectedIncidentHours: 3,
loadedOperatorRate: 75,
paidLicenseAndSupport: 0,
};
const ownershipLabor =
(estimate.maintenanceHours + estimate.expectedIncidentHours) *
estimate.loadedOperatorRate;
const monthlyTotal =
estimate.awsInfrastructure +
estimate.offSiteBackupAndMonitoring +
ownershipLabor +
estimate.paidLicenseAndSupport;
console.table({ ownershipLabor, monthlyTotal });
The $38.96 is my current AWS floor. The zero for off-site backup and monitoring describes a coverage gap, not free protection. The labor figures are placeholders. Use a loaded internal rate, not take-home pay. Include the time spent planning changes, testing backups, reviewing failures, and writing incident notes. If the system needs coverage outside one person’s working hours, price that coverage rather than setting the row to zero.
Then test the number against change. What happens when runs double? What happens when average actions rise from five to eight? What happens when a file workflow needs object storage, or an outage demands a second database node? The right model makes those questions easy to change.
I use the same separation when deciding whether to replace SaaS with custom software. License savings are real. So are maintenance and recovery. Combining them is how an attractive migration becomes an unexplained operating burden.
Which platform should an owner choose?
Choose from the constraint that would hurt most if you guessed wrong.
- Zapier: Broad app coverage and a managed service matter more than the task curve.
- Make: The team wants a managed visual builder and its scenario fits the credit model.
- n8n Cloud: Execution billing fits the workflow and the team wants the vendor to carry the service.
- Self-hosted n8n: Data location, code access, or execution economics justify owning the service.
Before moving, replay representative workflows and count actual units. Include branches, retries, polling, file handling, and failure paths. Test whether the target supports the credentials and actions you depend on. A spreadsheet comparison cannot tell you whether a connector drops a field or a webhook arrives twice.
Build the operating path too. Webhook reliability depends on durable receipt, idempotency, retry policy, and useful failure records. A dashboard that fails safely needs to show stale or incomplete state rather than presenting silence as success. Those properties cost time on every platform. Self-hosting merely changes who owns them.
The owner should see the whole bill before approving the move. The operator should see the whole job before inheriting it.
That is the balance the price page cannot calculate for you.
Frequently asked questions
Why does the same workflow count as 100,000 n8n executions but 500,000 Zapier tasks?
n8n bills a full workflow run as one execution on its listed plans, regardless of the number of steps. Zapier generally counts each successful action as a task. With five successful actions in each of 100,000 runs, the plain example becomes 100,000 n8n executions and 500,000 Zapier tasks. Product exceptions and premium features still need a workflow-level check.
Does Make always charge one credit per module action?
Make says most non-AI module actions use one credit, which is the rule used here. AI features and some advanced work can consume credits differently. Count the modules that actually run, including repeated bundles and error paths, then check those modules against the current billing rules before applying the 500,000-credit example.
What does your live AWS n8n setup cost?
Its current AWS infrastructure floor is $38.96 a month: $30.51 for a t3.medium, $4.80 for 60 GiB of gp3 storage, and $3.65 for one public IPv4 address using a 730-hour month. That excludes transfer, taxes, T3 surplus CPU credits, off-site backups, monitoring, labor, licensing, support, and high availability.
Does your n8n setup use queue mode?
No. It is one EC2 instance running n8n with SQLite, Nginx, and monitor-only Watchtower. It has no PostgreSQL, Redis, or worker services. Queue mode would be a separate scaling decision, and multiple main processes would require n8n’s paid multi-main capability.
How often should I redo an n8n vs Zapier vs Make cost comparison?
Recalculate when volume, action count, workflow shape, staffing, or a vendor price changes. I would also review it before an annual renewal and after a material incident. Keep the run count, action count, currency, billing term, infrastructure parts, operator rate, and excluded items visible so the next review updates assumptions rather than starting with a sales headline.