n8n bills by workflow execution rather than by step, which makes it cheap for complex workflows and expensive for frequent ones.
The billable unit matters more than the headline price, because it decides whether your bill grows with complexity or with frequency.
This page explains the shape of the pricing model rather than quoting figures, because plan limits and prices change. Check n8n.io for current numbers before deciding.
| n8n Cloud | Self-hosted n8n | Zapier | Aisle | |
|---|---|---|---|---|
| Billable unit | Workflow execution | Server capacity | Task, per step | Run, plus model calls |
| Adding a step | Nothing | Nothing | More per run | Nothing |
| Doubling frequency | Doubles | Nothing until capacity | Doubles | Doubles the model calls |
| Iterating 1,000 rows | Depends on loop shape | Nothing extra | Expensive | One run |
| Infrastructure | None | Server, storage, backups | None | None |
| Maintenance | None | Upgrades, patching, on-call | None | None |
| Cost known before deploy | Roughly | Yes | Roughly | Yes, calls sit in the code |
Because a whole workflow run counts as one execution, a workflow with forty nodes costs the same as one with three. That is the opposite of per-task pricing, and it is why teams with intricate automations often cut their bill by moving from Zapier. The pressure shows up elsewhere.
Self-hosting removes the execution meter, which is the obvious saving. The cost moves rather than disappearing, and it moves to the scarcest resource most teams have.
Sometimes the bill is a symptom. If workflows have grown to the point where nobody wants to change them, or a prompt edit has no history, or a retry re-sends messages that already went out, moving between billing shapes does not address any of it.
A Task is a Python program on a managed runtime. There is no execution meter and no per-step charge.
A prompt is only used when you call it, so you decide when to spend tokens. The call sites are lines in the file, so the per-run cost is arithmetic rather than something you discover from a balance.
result = aisle.parallel( process, rows, concurrency=8, max_per_minute=120, checkpoint="march-close", retry=3, ) # One run. Three prompt calls per row, at lines you wrote.
n8n bills by workflow execution rather than by step, so a run counts once whether it contains three nodes or forty. Plans set an included execution allowance along with limits on things like active workflows and concurrency. Check n8n.io for current allowances, since they change.
On the invoice, usually yes, especially at higher volumes. In total cost it depends what your engineering time is worth, because you take on a server, a database, backups, upgrades and being on call. For teams already running infrastructure that is a small addition. For teams who are not, it is a new responsibility.
The usual causes are a trigger firing per record rather than per batch, a polling trigger running more often than the work requires, sub-workflows billing separately depending on how they are called, and error-handler workflows counting too. Restructuring so one execution processes a batch is normally the fix.
For complex workflows, usually, because Zapier charges per task and counts every step while n8n counts the whole run once. A ten-step Zap costs ten tasks per run. For simple, very high-frequency automations the two get closer, since n8n still bills each run.
Once model calls are involved the platform fee is often smaller than the inference bill, so what matters most is whether you can see and control where the model gets called. Call sites you can read off a file make that cost predictable in a way a canvas generally does not.
Competitor details reviewed . Vendors change plans and features without notice, so check theirs before deciding.
Python on a managed runtime, with a cost you can work out before you deploy.