n8n Cloud vs Self-Hosted: Cost and Maintenance

Choose n8n Cloud when its deployment and plan limits fit your workflows and the subscription costs less than the operating work it saves. Choose self-hosting when infrastructure control solves a concrete requirement, or when a capable operator can demonstrate lower total cost after licensing, maintenance and recovery are included. A cheap server alone does not establish that saving.

This guide assumes you already want n8n. The decision is who operates it and what that responsibility costs. Use the n8n pricing guide for the current plan lineup; use the worksheet below to compare your own deployment options.

Check eligibility before calculating savings

Starter and Pro are hosted by n8n; Business is self-hosted, and Enterprise offers either deployment. Paid allowances count complete workflow executions rather than individual steps. Select a route that meets your expected runs, peak concurrency, retention and access requirements before comparing its cost. n8n pricing

Self-hosted Community Edition can remain free indefinitely, but it excludes features including workflow and credential sharing, SSO and Git-based version control. A team needing those capabilities must price the appropriate paid edition. Community and Cloud are therefore not automatically equivalent configurations. Compare n8n editions

The free-license assumption also needs a permitted use. n8n's Sustainable Use License includes internal-business, personal and non-commercial use boundaries; enterprise-marked code has separate licensing. This worksheet assumes an eligible internal-business deployment. Resolve uncertain customer-facing or resale arrangements with n8n before treating the license line as zero. Current n8n license

Self-hosting supports infrastructure you operate, including on-premises and private-cloud deployments. That can justify the route even when it costs more. If your requirement is merely custom workflow logic, first establish whether Cloud can run it: owning servers should solve an identified deployment constraint. n8n hosting documentation

Build a total-cost worksheet with named owners

Create normal-month, busy-month and first-year columns for each eligible route. Record currency, billing country, tax treatment, monthly versus annual commitment, and the owner of every subscription or provider account. Convert currencies consistently; do not compare an annual monthly equivalent with a cancellable monthly quote without noting the commitment.

Use this calculation: monthly total = subscription/license + additional usage + infrastructure + backup services + external services + operating hours × loaded hourly cost + expected business loss from disruption. Keep backup, upgrade, routine-operation and incident hours separate so one vague maintenance estimate cannot conceal missing duties. Add transition costs separately to the first-year total.

Loaded labor means the cost or opportunity value of the person doing the work, including relevant employment overhead. Existing staff and spare servers can lower incremental cash spending, but neither has unlimited capacity. Record both cash cost and labor value when those lead to different decisions. Leave an unquoted service or unknown recovery cost unresolved; an empty cell is not zero.

Runtime AI spending needs its own check. Eligible Starter and Pro Cloud instances can use prepaid Gateway credits for supported models and services; self-hosted n8n cannot use that route. Gateway and Assistant balances fund different activities. Workflows using your own provider credentials retain their provider bills. Count each service call under its actual billing arrangement, without adding the same call twice. Gateway credits and billing boundaries

Worked example: when labor reverses the answer

Consider a hypothetical EU business budgeting in EUR before applicable tax. One technical owner runs internal document-routing workflows, estimates 6,000 monthly production executions including reruns, and assumes both candidate configurations meet its peak-load and feature requirements. Community's feature restrictions are acceptable. These are planning assumptions, not a capacity benchmark or a recommendation that every 6,000-run workload fits these configurations.

For the Cloud subscription input, the official euro display lists Pro at €50 per month billed annually, with 10,000 monthly executions. That is €600 over twelve months; it is not a €50 cancellable monthly offer. Every infrastructure, provider and labor figure below is invented for the example. Official Pro pricing

The example assumes delayed internal work causes no additional financial loss beyond the response labor already counted. That is an explicit noncritical-workload assumption, not a claim about either route's reliability. Replace it for revenue-sensitive workflows. Initial workflow construction is assumed equal and excluded from the route comparison; transition spending is considered below.

The incident reserve represents an assumed annual response budget spread across months. It does not predict incident frequency, guarantee coverage or establish a recovery time. Likewise, the €15 infrastructure allocation is not a vendor quote or evidence that a particular server can process this workload.

At €50 per hour, Cloud saves €120 monthly, or €1,440 across twelve months before transition costs. Self-hosting saves €30 in recurring cash but consumes three additional assumed hours. Cloud's operating convenience is worth buying under those inputs.

The labor break-even is €30 ÷ 3 hours = €10 per hour. At €10 per hour, both routes total €100 monthly. Above that rate, Cloud wins this cost calculation; below it, Community wins, provided every eligibility and reliability assumption remains true. At an assumed €5 per hour, Cloud totals €95 and self-hosting €80.

That lower labor valuation still does not justify every migration. If moving from Cloud costs an additional assumed €300, a €15 monthly saving takes 20 months to recover. First-year self-hosting would cost €1,260 including migration, versus €1,140 to remain on Cloud. Add any unavoidable overlap with an existing annual commitment separately.

For your own figures, compare the recurring cash premium for Cloud with the value of the additional self-hosted hours. Recalculate whenever a paid self-hosted license, larger database, extra backup service or different provider route changes the cash difference. Equal provider spending cancels in this example; it need not cancel in your deployment.

Understand which maintenance work transfers

Cloud reduces the infrastructure work you perform, but version management still has an owner. Its update settings let the instance owner select a release track, cadence and maintenance window. n8n recommends Stable for mission-critical workloads and says security and stability updates apply automatically regardless of cadence. Budget time to review changes and check important workflow outcomes. Cloud update controls

For self-hosting, n8n recommends frequent updates, checking release notes for breaking changes and testing updates before production. Our operating recommendation is to budget a repeatable cycle: review the release, verify backups, test representative workflows, apply the update, check outputs and retain a recovery procedure. A successful installation is only the beginning of that obligation. Self-hosted update guidance

Do not assume Community includes n8n's paid Environments or Git promotion features just because an update guide recommends testing. A separately maintained test installation has its own infrastructure, credential and operating costs. Edition boundaries

Recovery also means restoring the business process. For example, after a workflow stops between creating a record and sending confirmation, someone must establish which action completed before replaying it. Budget that reconciliation on both routes. Managed infrastructure does not decide whether an AI classification was correct or whether repeating a successful write would create a duplicate.

Decide whether to buy Cloud, stay put or self-host

Buy Cloud when your workflows fit its supported environment, the selected plan meets access and capacity needs, and avoiding infrastructure work is worth the recurring premium. It is particularly compelling when the alternative depends on one busy person responding outside their normal role.

Do not buy Cloud solely to solve unreliable workflow logic, unclear credentials or uncontrolled model spending. Those need workflow and account changes. Also reconsider Cloud when an essential infrastructure, networking or runtime requirement cannot be met on the offered route.

Keep or choose self-hosting when deployment control is necessary, or when measured operating effort and eligible licensing make it cheaper over your intended ownership period. Do not switch merely because Community has no license charge. A working Cloud deployment can be cheaper to retain once migration effort and existing commitments enter the calculation.

Before committing, complete three practical checks:

1. Run a representative workflow with realistic files, peak arrivals and failed requests. Record operating effort and provider consumption rather than assuming the example's hours.
2. Name the primary and backup operators. Establish how to restore service, reconcile partial writes and verify an upgrade without relying on the original builder's memory.
3. Price the smallest eligible route for a normal month, a busy month and the first year. Identify who can approve upgrades, provider top-ups and emergency spending.

Use the n8n profile to open the relevant official buying and deployment routes. Commit when the worksheet explains both the bill and who will keep the workflows running.