n8n Pricing Explained: Cloud vs Self-Hosted (and the Hidden Cost of DIY)

Understanding n8n pricing is harder than reading a pricing page, because the number on the page is rarely the number you pay. n8n prices its Cloud offering by workflow executions rather than per-task or per-operation, and it also ships an open-source engine you can self-host for the cost of a server. Both paths look cheap until you account for the one line item no pricing table shows: the engineering time to design, build, and maintain the workflows themselves. This post breaks down the tiers, explains the execution-based model that trips people up, and gets honest about where the real spend lives.

How n8n pricing actually works

n8n is unusual among automation platforms in two ways, and both affect what you pay.

First, it is fair-code / source-available. The core workflow engine is free to run yourself. You are not licensing seats or paying per active workflow — you download it, run it, and it executes. That is a genuinely different economic model from closed SaaS automation tools that meter every single operation.

Second, n8n Cloud bills by workflow executions, not by the number of steps inside them. One execution is one full run of a workflow, triggered by a webhook, a schedule, a manual click, or a chained call — regardless of whether that run touches three nodes or thirty. A workflow that fires an HTTP Request node, runs an IF, loops over a batch of items in a Split In Batches node, and writes them all to Postgres still counts as one execution.

That single detail changes how you architect. On per-operation platforms you are punished for complex workflows. On n8n you are rewarded for consolidating logic into fewer, denser executions — which is exactly how a well-engineered system should be built anyway.

n8n Cloud tiers vs self-hosted

There are two commercial surfaces to weigh.

n8n Cloud

Cloud is the managed, hosted option. n8n runs the infrastructure, handles upgrades, and gives you the editor at a URL. Tiers scale primarily along three axes:

• Included executions per month — the headline meter. Lower tiers include a modest execution allotment; higher tiers include far more.
• Active workflows — how many workflows can be live and triggerable at once.
• Platform features — things like more concurrent executions, longer execution-data retention, additional users and roles, and (on higher plans) global variables, environments, and RBAC-style controls.

The trap here is the shape of your automation. If you run a handful of heavy, scheduled workflows, even an entry Cloud tier goes a long way, because those are few executions. But if you have a chatty webhook that fires on every form submit, every inbound message, or every row change, execution count climbs fast and you tier up on volume — not on value delivered.

Self-hosted

Self-hosting the Community Edition removes the execution meter entirely. You run n8n in Docker (typically the n8nio/n8n image) on a VPS, pointed at a Postgres database for execution history and credentials. Your bill becomes:

• The server — a small instance handles light workloads; queue mode with worker containers and Redis is what you reach for at scale.
• The database — Postgres for persistence (SQLite is fine for a sandbox, not production).
• Your time — patching, backups, upgrades, TLS, and monitoring.

There is also a self-hosted Enterprise license for teams that need SSO, log streaming, environments, and support on their own infrastructure. That is a commercial conversation with n8n, not a public sticker price.

For a rough mental model: self-hosted swaps a per-execution subscription for a fixed infrastructure cost plus operational labor. Below a certain volume, Cloud wins on simplicity. Above it, self-hosting wins on unit economics — if you have someone to run it. That "if" is the whole game, and it leads directly to the cost nobody prices.

The hidden cost of DIY automation

Here is the part the pricing page cannot show you. Whether you pick Cloud or self-hosted, the platform is the cheapest input. The expensive input is the engineering.

A production-grade n8n workflow is not "connect two nodes and walk away." Doing it right means:

• Error handling on every external call. Real workflows use a dedicated Error Trigger workflow, the Continue On Fail setting where partial success is acceptable, and retry logic on flaky APIs. Skip this and your automation fails silently overnight.
• Idempotency and deduplication. Webhooks get retried. Without a dedupe key check — a lookup against Postgres, a Data Table, or an incoming-hash guard — you double-process orders, double-send emails, double-charge people.
• Credential and secret hygiene. OAuth tokens expire, API keys rotate, and rate limits bite. Handling 429 responses with a Wait node and backoff is the difference between a workflow that survives Monday-morning traffic and one that gets your account throttled.
• Data shaping. Real integrations rarely line up. You spend real time in Set, Code, and Merge nodes normalizing payloads between systems that disagree about what a "customer" even is.
• Observability and maintenance. APIs change. A vendor deprecates an endpoint, a schema shifts, and your workflow breaks. Someone has to notice, diagnose, and fix it — indefinitely.

None of that is on the pricing page, and all of it is where the hours go. A workflow you can demo in an afternoon is very different from one you can depend on for a year. The gap between those two is the hidden cost of DIY. We build on exactly this stack — n8n orchestration, LLM reasoning, and Supabase as the data ledger — and the autonomous business infrastructure we ship is defined far more by the resilience engineering than by the node wiring.

Build vs hire: choosing your real cost

So the honest decision isn't "Cloud or self-hosted." It's "who owns the engineering."

Pick Cloud + build-it-yourself when automation is a side quest — a few internal workflows, low stakes, someone technical enough to babysit them. The subscription is your all-in cost and it's predictable.

Pick self-hosted + build-it-yourself when you have real volume and real in-house engineering capacity. You trade the execution meter for infrastructure you now operate. The savings are real; so is the on-call.

Pick hire it out when the workflows are load-bearing — they touch revenue, customers, or compliance — and you need them to not break more than you need to save on a server. This is where an execution-based platform's true cost surfaces: it's not the executions, it's the person who makes each execution trustworthy. Handing that to a team that engineers and operates the system removes the human latency between "something broke" and "someone fixed it."

There's no universally right answer — only the one that matches your volume, your risk tolerance, and whether you have an engineer whose job is keeping the pipes clean. What we'd push back on is the assumption that the platform bill is the decision. It almost never is.

If you want a straight read on which path fits your workload — and a system built to survive contact with production, not just a demo — schedule a build with us. We'll map your execution profile against your tolerance for maintenance and tell you honestly where the real cost lands.