n8n Cloud Explained: What You Get, What It Costs, Who It Suits

Last verified: October 2026

n8n Cloud is the hosted version of n8n, run by n8n GmbH, where you pay per month for a plan with a production-execution cap and never touch a server. Plans are priced in euros, every plan includes unlimited users and workflows, and the trial is 14 days with no card required. You give up server access and unverified community nodes.

Everything else about it is the same n8n you would run yourself: same editor, same nodes, same workflow JSON. This post covers what the plans include, what the trial does, where Cloud says no, and who should choose it. For the full argument against self-hosting, or for it, the n8n Cloud vs self-hosted page exists so I do not have to repeat it here.

What n8n Cloud is

When you sign up you get a workspace at a subdomain of n8n.cloud. n8n GmbH runs the instance, applies updates, keeps the database, handles backups and scales the hardware according to your plan. You log in, build workflows, attach credentials and publish. There is no Docker, no Postgres, no reverse proxy and no 2 a.m. page because the disk filled up.

The billing unit is the execution: one run of a workflow, however many nodes it contains. Only production executions count, meaning runs started by a trigger on a published workflow. Manual runs in the editor are free, and polling triggers count only when they find new data. The n8n workflows explainer covers the distinction in detail; the short version is that a webhook workflow firing 40 times a month costs 40 executions, and a one-minute schedule costs about 43,200.

n8n Cloud plans and prices (EUR)

These are the annual-billing figures from n8n's pricing page on 20 October 2026. n8n publishes prices in euros only; any dollar figure you see elsewhere is someone's conversion. Annual billing saves 17 percent against monthly.

Three things changed in 2026 that older write-ups get wrong.

Active workflow caps are gone. Starter used to allow five active workflows, Pro fifteen. The pricing page now says all plans include unlimited users and workflows. If a comparison you are reading mentions a workflow cap, it is out of date.

Business is self-hosted only. The Business plan is a licence for your own instance, adding features such as environments and SSO. n8n's FAQ says the hosted version of Business is on a waitlist. Business overage is published: €4,000 per extra 300,000 executions, invoiced 45 days later. What happens when Starter or Pro reach their cap is not published, so I will not guess.

The startup discount is self-hosted too. The startup plan takes 50 percent off Business for companies under 20 staff and under €5 million in funding, and it applies to self-hosted only. For Cloud, the only lever is annual billing, which is covered on the n8n discount page.

Executions, not features, are what move most people between Starter and Pro. Pro adds things like workflow history to roll back and the insights dashboard, but at 2,500 executions a single busy schedule can exhaust Starter in a week. Run your actual workflow list through the n8n cost calculator before picking; the n8n pricing page has the plan details side by side.

The n8n Cloud trial: 14 days, no card

The trial is the right first step for almost everyone, including people who will end up self-hosting, because it is the fastest way to find out whether n8n fits the job. According to n8n's free trial documentation:

• You get 14 days of Pro plan features, with a limit of 1,000 executions for the trial and the same computing power as the Starter plan.
• No credit card is needed. The pricing page states this directly; only the Business trial asks for a card.
• If you do not upgrade, the trial expires, no charge occurs, and n8n deletes the workspace. You have 90 days after the trial ends to download your workflows.

Two pieces of advice. First, export your workflows before day 14 rather than relying on the 90-day window; the workflow menu's Download option gives you the JSON, and that JSON imports into any n8n instance, Cloud or self-hosted. Second, 1,000 executions goes quickly if you test a schedule trigger at one-minute intervals. Build with manual runs, which are free, and publish only what you want to measure.

If you decide to leave Cloud for a server, this is all it takes to confirm a workflow survived the move. Point the webhook at the new instance and call it:

# production webhook on the new instance
curl -X POST "https://n8n.example.com/webhook/lead-intake" \
  -H "Content-Type: application/json" \
  -d '{"name": "Test Lead", "email": "test@example.com", "source": "migration-check"}'
# then confirm it landed
# Executions list -> filter by workflow -> the newest run should be green

Same workflow JSON, same credentials re-created by name, same result. The portability is real and it is the main reason the trial is a low-stakes decision.

What you cannot do on n8n Cloud

The list is short, but each item is a hard stop rather than an inconvenience.

No server access. You cannot SSH in, read the filesystem, install system packages, or run anything that is not a workflow. Nodes that assume local access (reading local files, executing shell commands) are not available. If your workflow needs to run a script against a local folder, Cloud is the wrong fit.

Community nodes only if verified. Self-hosted n8n can install any community node package from npm. Cloud restricts you to the verified set n8n has reviewed. Most popular integrations have an official node, so this bites less than it used to, but if the one node you need is unverified, you are either waiting for verification or self-hosting. The usual workaround is the HTTP Request node, which can call almost any API the community node wraps.

No environment-level configuration. Queue mode, task runner settings, database choice, binary data storage, execution retention policy: all of these are environment variables on a self-hosted instance and plan settings, or not available, on Cloud.

Execution caps. This is the big one. Self-hosted n8n has no execution limit; Cloud plans do. A workflow that is cheap on a server can be expensive on Cloud purely because it runs often, regardless of how little work each run does.

What Cloud does better: updates arrive without you doing anything, backups and uptime are someone else's job, and there is a support channel. For a small team with no one who wants to own a server, those three cover a lot.

n8n Cloud vs self-hosted: the short version

The decision comes down to two things: how many executions a month you will run, and whether someone will maintain a server.

Under about 2,000 executions a month with nobody keen on servers, Cloud Starter is the sensible default; €20 a month to never think about hosting is cheap. Over about 10,000 a month, or if any workflow needs server access or an unverified node, self-hosting wins on cost and capability, and a small VPS runs n8n comfortably. Between those, it depends on whether the person who would maintain the server actually wants to. The self-host n8n guide covers what that maintenance looks like in practice: monthly updates, a database backup, and reading the release notes before each update.

The comparison page goes through this properly, with the cost crossover worked out, so I will not re-argue it here.

Who n8n Cloud suits

Cloud is the right choice when:

• You are evaluating n8n and want an answer in an afternoon. Start the trial, import a couple of n8n templates, and see whether the editor makes sense to you.
• Your workflows are event-driven rather than schedule-driven: form submissions, new orders, inbound webhooks. These produce dozens or hundreds of executions a month, not thousands.
• Nobody on the team wants to own a Linux box, and the honest answer to "who updates it" is "nobody".
• Compliance or procurement prefers a vendor with a contract over a server you administer.

Cloud is the wrong choice when a single workflow needs to run every minute, when you need a community node that is not verified, when the workflow touches local files or commands, or when execution volume makes Pro look expensive next to a VPS. In those cases the move is the same JSON export described above, and most people make it within a few months of outgrowing Starter.

A sensible first week on the trial

Day one: sign up, open the editor, and build one workflow by hand with a Manual Trigger, an HTTP Request to a public API and an Edit Fields node. Run it manually and read the execution view until the item model makes sense. Day two: import one template from the library, attach your own credential, and run it against a test destination. Day three: build the workflow you actually came for, with a real trigger, and publish it. Days four to ten: watch the execution count on the usage page and compare it with what you expected; this number decides your plan. Day eleven: export everything as JSON and commit it. By then you know whether the editor suits you, roughly what the monthly execution count will be, and therefore whether Starter, Pro or a VPS is the right home.

My own rule: start on Cloud if you are unsure, and keep the exports in git from day one. Then the choice stays open and switching, in either direction, is an afternoon rather than a project.