n8n pricing explained: what you are actually billed for

Published Aug 8, 2026 · 6 min read

The real question behind n8n pricing is whether this lands at twenty dollars a month or eight hundred. The published figures move, and any article that quotes them is wrong within a few months, so this one explains the model instead. The model has been stable, and once you understand it you can read n8n's own pricing page in about a minute and know which row applies to you.

n8n meters executions, not tasks and not seats

Most automation tools bill per step. Zapier counts tasks, Make counts operations, and in both cases every action inside an automation adds to the meter. n8n Cloud bills per workflow execution: one complete run of one workflow is one execution, whether that workflow contains three nodes or sixty.

That single difference changes how you build. Adding error handling, a data cleanup step, a logging step and a Slack notification to an existing workflow costs nothing extra on your bill. Splitting one workflow into five that call each other can cost you more. The lever on your invoice is how often things run, not how much work each run does.

Users and workflows are also outside the meter. Plans include unlimited workflows and unlimited users, so giving your ops lead, your bookkeeper and your assistant their own logins does not raise the price.

What counts as one execution

• A production run started by a live trigger: a webhook, a schedule, an app event, a form submission. The number of nodes inside it is irrelevant.
• A run that loops over 500 records is still one execution. Items processed do not multiply the count, which is why batching work into a single scheduled run is the cheapest shape.
• A run that fails partway through still used its trigger. If you have a retry configured, the retry is another run.
• Test runs you fire manually while building in the editor are treated differently from production runs. Check the current definition before you assume a week of building is free.
• Whether a sub-workflow called by a parent counts as its own execution has changed across n8n versions and plans. It matters a lot if you build modularly, so verify it before you design around it.

For the current tiers, execution allowances and the exact billing definition, go to n8n.io/pricing and the docs it links to. Those are the only numbers worth trusting.

Estimate your own volume before you look at a price

You cannot tell whether a plan is cheap without a number of your own, and getting one takes about ten minutes. List every trigger you expect to have, decide how often each one fires, and add them up.

The trap is polling. A schedule trigger that checks for new rows every five minutes runs on schedule whether or not anything happened, and it will quietly dominate your total.

Two things usually fall out of that table. First, one or two polling workflows account for most of the volume, and replacing them with a webhook from the same app cuts the total by an order of magnitude. Second, if your honest estimate is in the hundreds or low thousands, the entry tier covers you and this whole question is smaller than you feared.

Then double your number. New automations arrive faster than anyone plans for, and one misconfigured schedule can outweigh everything else on the list.

Self-hosting changes the shape of the cost, not always the size

The Community edition is free to run on your own server. It is source-available under n8n's Sustainable Use License, which permits internal business use but not reselling n8n itself as a hosted service. There is no execution meter, so the volume question disappears. In its place you pay for infrastructure and for someone's time.

Where self-hosting stops being cheaper

• The default SQLite database is fine for trying it out. Anything carrying real work wants Postgres, and past a certain concurrency you add queue mode with Redis and separate worker processes. Each of those is another service to run and patch.
• n8n ships releases frequently and major versions carry breaking changes. Either someone reads release notes and tests upgrades, or you sit on an old version with ageing dependencies.
• A backup is only real once you have restored from it. n8n encrypts stored credentials with a key held outside the database, and losing that key makes every saved credential unrecoverable even though your backup restored cleanly.
• A self-hosted instance that stops does not tell anyone. Alerting on failed runs and on the instance itself is something you build, not a box you tick.
• The honest line item is the hourly rate of whoever maintains it. If that is a technical founder who enjoys the work, self-hosting really is cheap. If it is a developer pulled off billable work for an afternoon of debugging, that afternoon can cost more than a year of the entry tier.

For a small team with no spare technical person, self-hosting is usually a false economy. The server is the cheap part.

The costs that are not on any pricing page

• Model usage. n8n's AI nodes call OpenAI, Anthropic or whoever you point them at using your own API key, billed by token, separately. On an AI-heavy workflow the model bill can be larger than the n8n bill.
• Messaging. WhatsApp Business, SMS and transactional email all charge per message or per conversation window, and volume there scales with your customers rather than your workflows.
• The other end of every integration. Some CRMs and accounting tools put API access or webhooks behind a higher plan, so connecting a tool can raise the price of that tool.
• Build time. Across a first year of automation, the license is normally the smallest number. Designing the flow, handling the edge cases, and the rework once real data hits it are the expensive parts.
• Maintenance. Upstream APIs change fields, deprecate endpoints and rotate credentials. Automations rot, and somebody notices either through monitoring or through an angry customer.

When paying an agency makes sense, and when it does not

If you need one or two automations, you have someone in-house who likes tinkering, and a workflow being broken for a day is survivable, hire nobody. n8n's templates and documentation will get you there, and paying anyone for that is waste.

It changes when the automation touches money or a promise you made to a customer, when the only person who could build it is the person you need doing something else, or when nobody has decided what happens the day it fails. That last one is the real deliverable, and it is the part DIY builds skip.

When we build on n8n, the instance and every connected account stay in the client's name under their own logins. You keep paying n8n directly, you can see exactly what your execution volume is, and if you fire us the automations keep running. We pair that with a dedicated virtual assistant for the judgement calls that automation should not be making.

The build fee, the monthly amount and the things we do not charge for are itemised on our n8n agency page.

Whatever you do next, get today's figures from n8n.io/pricing before you budget. The model in this article has held steady. The numbers attached to it have not.