---
title: "n8n Cloud Pricing 2026: Plans, Execution Limits, and Self-Hosting Costs"
description: "Compare current n8n Cloud prices, execution limits, polling costs, quota behavior, Business and Enterprise plans, and self-hosting costs."
canonical: "https://darwa.co/blog/en/n8n-cloud-pricing-2026"
language: "en"
category: "Engineering"
tags: ["n8n", "n8n pricing", "n8n cloud", "workflow automation", "self-hosted n8n", "automation costs", "managed n8n hosting"]
author: "Darwa Engineering"
published: "2026-10-01T18:30:00Z"
updated: "2026-10-02T04:44:28.203432Z"
reading_time_minutes: 12
---
# n8n Cloud Pricing 2026: Plans, Execution Limits, and Self-Hosting Costs

A fact-checked guide to n8n pricing in 2026, including plan limits, polling execution math, what happens at the quota, and when Cloud or self-hosting costs less.

**The short answer:** n8n Cloud starts at **€20 per month when billed annually** for 2,500 workflow executions. Pro starts at **€50 per month when billed annually** for 10,000 executions. The €667 Business plan shown on n8n's pricing page is **self-hosted, not a Cloud plan**. Enterprise pricing is custom.

The price on the card is only half of the decision. n8n bills completed production workflow runs rather than individual nodes, so a 20-node workflow normally counts as one execution. But a polling workflow scheduled every five minutes can attempt about 8,640 runs in a 30-day month before it processes a single useful record.

This guide was verified against n8n's official pricing, support, and documentation on **2 October 2026**. Prices exclude VAT and can change. Check the [live n8n pricing page](https://n8n.io/pricing/) before buying.

## n8n pricing in one table

| Plan | Advertised price | Included executions | Deployment | Important limits or features |
| --- | ---: | ---: | --- | --- |
| **Starter** | €20/month, billed annually | 2,500/month | n8n Cloud | 1 shared project, 5 concurrent executions, 1,600 AI Assistant credits/month |
| **Pro** | €50/month, billed annually | 10,000/month | n8n Cloud | 3 shared projects, up to 50 concurrent executions, 7 days of insights, AI Assistant credits vary by Pro configuration |
| **Business** | €667/month, billed annually | 40,000/month | Self-hosted only | 6 shared projects, SSO, environments, Git, 30 days of insights, queue mode |
| **Enterprise** | Custom | Custom | n8n Cloud or self-hosted | Custom projects, retention, support, security, and scaling terms |
| **Community Edition** | No n8n subscription fee | No Cloud execution allowance | Self-hosted | You operate compute, database, storage, TLS, updates, monitoring, and recovery |

At annual billing, the advertised base commitment is €240 for Starter, €600 for Pro, and €8,004 for Business before VAT. n8n also offers a [startup plan](https://n8n.io/pricing/startup-plan/) advertised at €333 per month billed annually for eligible companies with fewer than 20 employees and less than €5 million in total funding. That plan is self-hosted and includes 40,000 executions.

Two corrections are worth making because many pricing summaries get them wrong:

1. **Business is not an n8n Cloud tier.** The current pricing page labels it self-hosted.
2. **Reaching the execution quota does not deactivate every workflow.** New production executions fail before their nodes run; triggers and workflows remain active.

## What counts as an n8n execution?

An execution is one run of a workflow. A successful webhook run through 25 nodes is one execution, not 25. An error run is still a run. A scheduled check that finds no new work also uses a run if the workflow executes.

That model is often favorable for long workflows. It also makes trigger design more important than node count.

Consider two ways to watch for a new order:

- A **webhook** starts the workflow only when an order arrives. If 300 orders arrive, the workflow runs about 300 times.
- A **polling schedule** checks the source every five minutes. It runs about 8,640 times in a 30-day month, even if only 300 checks find an order.

The exact count depends on retries, errors, sub-workflows, manual runs, and the way each trigger is implemented. n8n's pricing page says charges are based on workflow executions rather than each step. Use the execution history from a representative week instead of estimating only from business events.

### Polling interval calculator

For a workflow that runs continuously, the baseline monthly attempts are:

| Schedule | Approximate runs in 30 days | Smallest listed Cloud plan that fits one such workflow |
| --- | ---: | --- |
| Every 5 minutes | 8,640 | Pro |
| Every 10 minutes | 4,320 | Pro |
| Every 15 minutes | 2,880 | Pro |
| Every 30 minutes | 1,440 | Starter |
| Every hour | 720 | Starter |
| Once per day | 30 | Starter |

The formula is simple:

```text
monthly scheduled runs = (60 / interval in minutes) × 24 × 30
```

This is capacity math, not a promise about the bill. A workflow that is disabled part of the month will run less. A webhook may run much more if event volume is high. Failed attempts and retries can add executions.

## Three realistic execution examples

### 1. A small event-driven sales workflow

Suppose a webhook receives 800 qualified-lead events per month. Each run enriches the lead, updates the CRM, posts to Slack, and sends an email. Even though the workflow has several nodes, its baseline is about 800 executions. Starter has room for that workload, assuming other workflows and retries stay below the remaining 1,700 executions.

### 2. One frequent poll plus one report

A source is polled every ten minutes and a reporting workflow runs hourly:

```text
10-minute poll: 4,320
hourly report:     720
total:           5,040 executions/month
```

That total exceeds Starter's 2,500 executions but fits within the listed Pro allowance of 10,000. Converting the poll to a webhook would change the result if the source supports reliable events.

### 3. Two five-minute monitors

Two workflows each run every five minutes:

```text
8,640 × 2 = 17,280 scheduled runs/month
```

That is already above the public 10,000-execution Pro entry point. The correct next step is not automatically a larger contract. First ask whether both sources offer webhooks, whether the interval can be relaxed, whether checks can be combined safely, and whether self-hosting is operationally sensible.

## What happens when the Cloud execution quota is reached?

n8n's official [execution-limit support article](https://support.n8n.io/article/can-you-reset-my-executions) is more precise than the common claim that “all workflows stop.” When the account reaches its monthly allowance:

- trigger- and webhook-based production executions are attempted but fail immediately, before nodes run;
- the executions are not queued for later and are not automatically replayed after the allowance resets;
- workflows and triggers remain active;
- normal production execution resumes after the monthly reset or an eligible plan upgrade;
- manual editor runs, chat executions, and sub-workflows are not affected on paid plans, according to n8n's support guidance.

That still creates a serious production risk. If an upstream service sends a webhook during the blocked period and does not retry it, the business event may need manual reconciliation. A monthly reset restores future execution; it does not backfill missed work.

n8n says Trial, Starter, and the lower Pro configuration may qualify for a one-time courtesy reset. Its higher Pro configuration can buy execution add-ons. Treat those as recovery options, not capacity planning.

For important workflows, alert on allowance consumption before the final day. Also keep a reconciliation job that compares source records with completed workflow outcomes. Quota monitoring tells you capacity is running out; reconciliation tells you what the application missed.

## AI Assistant credits are a separate meter

Workflow executions and AI Assistant credits are different allowances. The Assistant helps build, debug, and explain workflows inside n8n. It is not the token bill from an OpenAI, Anthropic, Google, or other model credential used by a production workflow.

n8n [changed its Assistant credit system on 1 October 2026](https://support.n8n.io/article/fewer-assistant-credits-october-2026). Its support documentation lists 1,600 included monthly credits for Starter, 4,000 for one Pro configuration, and 9,600 for the higher Pro configuration. It also says credits now have a fixed value of $0.01 and that purchased top-ups expire after 12 months.

This creates three separate cost questions for an AI workflow:

1. How many n8n workflow executions will run?
2. How many Assistant credits will builders consume while creating and debugging it?
3. How much will the production model, vector database, and external APIs charge?

A plan can have enough workflow executions while the connected model account runs out of credit, or the reverse. Monitor each meter independently.

## The real cost of n8n Cloud

The useful estimate is not only the plan price. Use:

```text
monthly automation cost =
  n8n subscription
  + execution add-ons
  + production model/API usage
  + external databases and storage
  + engineering and incident time
```

Cloud reduces the infrastructure portion because n8n operates the application service. It does not remove workflow ownership. Your team still owns credentials, data mapping, business rules, retries, idempotency, and the effect of a bad automation.

Cloud is usually easiest to justify when:

- the included execution tier matches measured demand;
- the team values vendor-operated upgrades and application availability;
- standard n8n Cloud controls meet security and data requirements;
- no custom node or infrastructure requirement forces self-hosting;
- predictable subscription cost matters more than low-level control.

The value can weaken when frequent polling dominates the allowance, workload volume changes sharply, or the required feature is only available on a much higher tier.

## What self-hosted n8n actually costs

The Community Edition has no n8n Cloud subscription allowance, but it is not zero-cost automation. n8n describes itself as a **fair-code, source-available** product, not a conventional permissive open-source project. Review the [n8n Sustainable Use License](https://docs.n8n.io/sustainable-use-license/) for the activity you plan to run.

A practical self-hosted estimate is:

```text
self-hosted monthly cost =
  compute
  + database and storage
  + backups
  + network and observability
  + engineer hours
  + expected incident cost
```

The infrastructure can be inexpensive for a small instance. Operations are the variable people omit. Someone must own:

- version upgrades and rollback;
- the persistent n8n data directory or [external database](/databases);
- the encryption key used for stored credentials;
- TLS, DNS, authentication, and network exposure;
- execution-data retention and disk growth;
- monitoring, alerts, and restore tests;
- capacity for webhook bursts and long-running jobs.

n8n's [Docker installation guide](https://docs.n8n.io/hosting/installation/docker/) recommends Docker for most self-hosting needs, while also warning that self-hosting requires server, container, security, and scaling knowledge. For higher-throughput designs, [queue mode](https://docs.n8n.io/hosting/scaling/queue-mode/) separates the main instance from workers and uses Redis plus a supported database. That is useful architecture, but it is more infrastructure to operate.

Do not compare €20 of Cloud only with the price of one small virtual machine. Compare the full operational boundary.

## n8n Cloud, do-it-yourself, or managed self-hosting?

| Option | Billing boundary | Who operates n8n | Execution-plan quota | Best fit |
| --- | --- | --- | --- | --- |
| **n8n Cloud** | Subscription tier and execution allowance | n8n | Yes | Teams that want n8n to operate the service |
| **Community Edition on your infrastructure** | Infrastructure and engineering time | Your team | No Cloud quota; capacity is resource-bound | Teams with infrastructure skills and a reason to own the stack |
| **Managed self-hosting on Darwa** | Selected hosting resources and related services | Darwa manages the deployment surface; the customer owns workflows and credentials | No n8n Cloud execution allowance; compute and upstream limits still apply | Teams that want a dedicated n8n deployment without assembling it manually |

[Darwa's managed n8n hosting](/n8n-hosting) deploys a dedicated n8n service with [persistent storage](/cloud-storage), HTTPS, health visibility, and resource-based hosting instead of an n8n Cloud execution tier. That removes one billing meter; it does not make executions infinite. The deployment remains bounded by CPU, memory, storage, external API limits, workflow design, and any applicable n8n license terms.

Because infrastructure prices vary by region and selected capacity, use [Darwa's live pricing](/pricing) rather than a static number in this article.

Choose **n8n Cloud** when convenience and vendor ownership are the primary requirements and the execution tier fits. Choose **do-it-yourself self-hosting** when your team wants full control and is prepared to operate it. Evaluate **managed self-hosting** when you want a dedicated deployment and resource-based economics without building the hosting layer from scratch.

## How to reduce execution usage without breaking workflows

Optimization should reduce unnecessary starts, not hide legitimate business events.

### Prefer webhooks when the source supports them

A webhook is usually more execution-efficient and lower-latency than checking for changes on a schedule. Validate signatures, respond within the source's deadline, store an event identifier, and make processing idempotent because providers may retry.

### Slow polling to the actual freshness requirement

Changing a five-minute schedule to 15 minutes reduces the theoretical monthly runs from 8,640 to 2,880. That is a useful saving only if a 15-minute delay is acceptable. Write the freshness requirement before selecting the interval.

### Combine compatible checks carefully

One scheduled workflow can sometimes fetch several records or accounts in one execution. Do this only when a single failure will not block unrelated work and the upstream API permits batching. Large combined workflows can become difficult to retry safely.

### Stop unconditional retries

Retry transient failures such as rate limits and temporary timeouts with bounded backoff. Do not retry invalid credentials, malformed data, or rejected business rules indefinitely. A retry loop consumes executions without repairing the cause.

### Separate monitoring from reconciliation

A dashboard should warn about rising execution use. A reconciliation workflow should find source events with no successful outcome. They solve different problems and both matter near a quota.

## A safe Cloud-to-self-hosted migration checklist

Migration is more than importing workflow JSON. Use a staged move:

1. **Inventory workflows and triggers.** Record owners, schedules, webhook URLs, dependencies, credentials, expected monthly volume, and current error rate.
2. **Export workflow definitions.** Keep the export in a private, versioned location and review it for embedded values before committing it.
3. **Prepare credentials separately.** Plan to recreate or re-authorize credentials unless you have a supported encrypted migration method and control the required encryption key.
4. **Provision persistent state.** Back up the database or data directory, retain the encryption key securely, and test restoration into a separate instance.
5. **Match configuration.** Set the public webhook URL, timezone, execution retention, email, task runners, and any allowed community or custom nodes.
6. **Test with production-shaped events.** Verify success, invalid input, provider timeout, retry behavior, duplicate delivery, and restart recovery.
7. **Move triggers deliberately.** Disable the old trigger and enable the new one in a controlled window so the same event is not processed twice.
8. **Reconcile after cutover.** Compare source events with completed outcomes and keep the old instance recoverable until the acceptance window closes.

The most dangerous migration is one where the editor loads successfully but credentials, webhook callbacks, or persistent state fail later.

## Which n8n plan should you choose?

Use measured executions and required controls:

- Choose **Starter** for small event-driven workloads that stay comfortably below 2,500 monthly runs and do not need Pro collaboration or concurrency.
- Choose **Pro** when Cloud is the right operating model and demand fits the selected Pro execution allowance, projects, concurrency, and insights.
- Evaluate **Business** when you need its self-hosted collaboration and governance features. Do not buy it expecting n8n to host the instance.
- Ask about **Enterprise** when custom retention, projects, support, security, or scale are contractual requirements.
- Choose **Community Edition** when included features are sufficient and your team can own production operations.
- Evaluate **managed self-hosting** when execution-tier economics or deployment control matter, but you do not want to assemble the infrastructure alone.

Before committing annually, run a representative workload for at least one business cycle. Count production executions, peak concurrency, retained execution data, model/API spend, failures, and operator time. The cheapest card can be the wrong plan if its quota changes workflow design; a larger plan can also be wasteful when one polling trigger creates most of the volume.

## Bottom line

n8n's per-workflow-run model is easier to reason about than per-step pricing for long automations. The main trap is assuming business events and executions are the same number. They are not when schedules, retries, and errors are involved.

Start with the trigger math. Verify which controls are required. Then compare n8n Cloud's subscription and execution boundary with the complete infrastructure and operating cost of self-hosting.

If dedicated, resource-priced hosting fits that calculation, review [managed n8n hosting on Darwa](/n8n-hosting). If n8n Cloud fits better, buy it directly. The correct answer is the one whose operational boundary your team can support—not the one with the smallest headline price.