n8n Pricing: What the Cloud Plans Cost and What Self-Hosting Actually Costs

n8n has three cost models: a paid cloud service priced by workflow executions rather than by task, a free Community Edition you run yourself under a source-available licence, and a paid Enterprise self-hosted tier. The interesting part is not the sticker prices — it is that self-hosting is free in licence terms and not free in total.

n8n’s own framing is that pricing reflects value delivered rather than compute consumed, which is why the self-hosted paid tiers exist at all and why the execution-based model looks unusual next to per-task competitors. Whether that framing suits you depends less on the numbers than on how many steps your workflows have and whether the licence permits what you intend to build.

The three models
Execution-based pricing, and why it changes the maths
What self-hosting actually costs
What drives your bill either way
Choosing between them
Sizing the self-hosted option honestly
How this fits the rest of the stack
FAQ

The three models

Cloud. Hosted by n8n, priced in tiers by the number of workflow executions per month, with limits on active workflows and features by tier. No infrastructure work.
Community Edition, self-hosted. The full workflow engine, free of licence charge, run on your own infrastructure. This is the version most self-hosters use and it is genuinely capable.
Enterprise, self-hosted. Paid tier adding SSO, log streaming, external secret stores, environments, and support, while still running on your infrastructure.

The distinction that matters commercially is between free and self-hosted paid, and it is a licence question rather than a feature one. n8n is source-available under a sustainable use licence, not open source in the OSI sense. Internal business use is permitted. Reselling n8n itself, or offering it as a hosted service to your customers, is not — which means building a SaaS product whose core is a rebadged n8n falls outside the free licence.

Read the licence before building a business on top of it. It is short, and it is the single most consequential thing on this page for anyone planning a product rather than an internal automation.

Execution-based pricing, and why it changes the maths

n8n counts a full workflow run as one execution, regardless of how many nodes it contains. That is a meaningful difference from per-task or per-operation models, and it cuts in a specific direction.

A workflow with twenty-five nodes that fires a thousand times a month is a thousand executions. Under a per-task model, the same thing could be counted twenty-five thousand times. For complex workflows this is dramatically cheaper; for trivial two-step workflows firing constantly, it is less advantageous.

The practical consequence is a design incentive worth being aware of. Under execution pricing you are rewarded for consolidating related work into one workflow, and penalised for splitting it into several that call each other. That pulls against the maintainability advice of keeping one workflow to one job, and it is worth deciding consciously which way you want to lean rather than drifting.

One thing to watch either way: a polling trigger set to every minute produces roughly 43,200 executions a month whether or not anything changed. Switching to a webhook where the source supports one removes almost all of that. It is the highest-leverage cost change available and it also makes the workflow react faster.

What self-hosting actually costs

The licence is free. The rest is not, and the honest list is longer than people expect.

Compute. Modest — n8n runs comfortably in a small instance for typical loads.
A database. PostgreSQL for execution history, once you are past evaluating. This is a real, separate cost.
Storage. Execution history grows. Configure pruning or budget for it.
A domain and certificate. Webhooks need a stable HTTPS URL.
Backups. Of the database, and of the credentials store.
Your time. Upgrades, monitoring, the evening an upgrade goes badly, and the hour spent working out why webhooks stopped arriving.

That last item is the one that decides it and the one nobody puts in the spreadsheet. If an hour of your time has a value and self-hosting costs three hours a month once it is running, the comparison changes shape entirely. It is still frequently worth it — particularly when you want workflows touching internal systems that should not be reachable from a hosted service — but it should be an informed choice rather than an assumed saving.

The genuinely good reason to self-host is not cost. It is control: data that stays inside your network, no execution limits, and the ability to reach services that are not exposed publicly.

What drives your bill either way

Trigger frequency. The largest factor by a distance. Polling every minute versus every hour is a sixty-fold difference in executions.
Webhook versus polling. A webhook fires only when something happened. Polling fires whether or not anything did.
Retry storms. A workflow that retries aggressively against a failing API can multiply executions during an incident. Bound the retries.
Test runs. Manual executions during development count on cloud plans. Meaningful during a heavy build week.
Error workflows. Each error workflow run is itself an execution. Worth having anyway; worth knowing about.
Sub-workflows. A workflow calling another may count as two executions depending on configuration.

The cheapest optimisation on that list is the first two together: audit your active workflows for polling triggers, and convert every one whose source supports webhooks. Most instances have at least one workflow polling far more often than the data ever changes, left at a default nobody revisited.

Choosing between them

Trying it out, or a handful of workflows — cloud’s entry tier or a free self-hosted instance. Both are fine; cloud is faster to start.
Internal automation touching only public APIs — cloud, unless the execution volume is high. The time saved is worth more than the difference.
Workflows reaching internal systems — self-hosted. A hosted service cannot reach your private network, and this is the clearest case.
Data residency or compliance constraints — self-hosted, in the location required.
High execution volume with simple workflows — self-hosted. This is where the economics flip hardest.
Building a product on top of n8n — read the licence first. This is a legal question before it is a pricing one.

And the hybrid nobody mentions: self-host, but on a managed platform rather than a server you administer. You keep the free licence, the private network reach, and the absence of execution limits, while not owning the certificate renewal, the restart policy, or the database backups.

Sizing the self-hosted option honestly

If you go that way, the components are: the n8n process itself, a Postgres database for execution history, storage, and bandwidth. Those are four separate numbers, and collapsing them into one estimate is how self-hosting ends up looking cheaper than it is.

n8n itself is not demanding — a small plan covers a real team’s workflows, since execution is mostly waiting on HTTP calls rather than CPU work. The database is the part people forget to include, and it is not optional once execution history matters.

Storage grows with execution history, so configure pruning to delete executions past a retention age you actually need. Bandwidth depends on payload sizes; workflows moving files use meaningfully more than workflows moving JSON records.

How this fits the rest of the stack

On RunxBuild, n8n is a managed tool rather than a server you build: a create form, a plan, a live URL with a custom domain, environment variables, autoscaling between a floor and a ceiling, and logs per execution — with a managed Postgres provisioned alongside it rather than crammed into the same container. n8n on a Basic plan at $6 a month with a managed database beside it covers a real team’s automation load, and the two appear as separate lines rather than a bundle. Services on RunxBuild covers the deploy, variable, and log model, and the RunxBuild hosting calculator lets you put the tool plan, the database, storage, and bandwidth side by side so the self-hosted total is an actual figure rather than an assumption.

Useful related references:

FAQ

How does n8n pricing work?

n8n cloud is priced in tiers by the number of workflow executions per month, where one full workflow run counts as a single execution regardless of node count. There is also a free self-hosted Community Edition and a paid Enterprise self-hosted tier adding SSO, log streaming, and support.

Is self-hosted n8n free?

The Community Edition carries no licence charge, but self-hosting is not free in total — you pay for compute, a PostgreSQL database for execution history, storage, a domain and certificate, backups, and your own time on upgrades and monitoring. The good reason to self-host is control, not cost.

Can I build a SaaS product on top of n8n?

Not under the free licence. n8n is source-available under a sustainable use licence that permits internal business use but not reselling n8n or offering it as a hosted service to your customers. Read the licence before building a product around it — it is a legal question first.

What makes an n8n bill go up?

Trigger frequency, overwhelmingly. A workflow polling every minute produces roughly 43,200 executions a month whether or not anything changed. Switching to webhooks where the source supports them removes most of that. Retry storms during an incident and manual test runs also count on cloud plans.

Is execution-based pricing cheaper than per-task pricing?

For complex workflows, substantially — a twenty-five node workflow running a thousand times is a thousand executions rather than twenty-five thousand tasks. For trivial two-step workflows firing very frequently, the advantage is smaller. It also creates an incentive to consolidate work into fewer, larger workflows.