Choose n8n Cloud when the team wants to build automations without owning the platform that runs them. Choose self-hosted n8n only when control, private-system access, deployment policy or sustained scale is worth taking responsibility for updates, security, backups, monitoring and incident recovery. A cheap virtual server is not the full cost of self-hosting, and a Cloud execution allowance is not the full value of managed service.
Both routes provide the n8n visual workflow model, nodes, triggers, credentials and code-capable automation experience. The difference is the operational boundary. With Cloud, n8n operates the hosted service and packages usage into current plans. With self-hosting, your organization operates the application, database, encryption configuration, network exposure and lifecycle. That choice matters more than a feature-count comparison.
This is a researched comparison, not a deployment test. SaaS Central reviewed current n8n pricing, hosting, Cloud, configuration and edition documentation plus current 2026 operator comparisons. We did not run workflows, benchmark latency, inspect a tenant, deploy a server or audit security. Exact features, limits, regions, support and license terms can change; verify the current plan and documentation before committing production data.
Decision matrix
| Requirement | n8n Cloud | Self-hosted n8n |
|---|---|---|
| Fast start without server ownership | Best fit | Poorer fit |
| Private network or local-only systems | May need exposed/API-accessible route | Strong when deployed inside the required network |
| Automatic service maintenance | Managed route | Your responsibility |
| Complete deployment and update control | Limited by service | Strong |
| Predictable modest execution volume | Straightforward plan comparison | Can be unnecessary operational overhead |
| High or irregular volume | Check plan executions and concurrency | Hardware and architecture become your limits |
| No experienced platform owner | Safer default | Do not choose for invoice savings alone |
| Strict data-location or control requirement | Verify Cloud region/contract | Potential fit, but self-hosting does not create compliance automatically |
Verdict: n8n Cloud is the default for a small team that needs automation rather than infrastructure work. Self-host only after naming the platform owner, backup and restore procedure, update window, monitoring path, security baseline and recovery target. Choose neither until the workflows themselves have clear owners and manual recovery steps.
The most important pricing unit is an execution
n8n’s current Cloud pricing is organized around workflow executions rather than charging for every individual step. An execution is a run of the workflow. A workflow that processes one item and a workflow that loops through many items can therefore place very different load and business risk inside the same nominal execution count.
That model can be attractive for multi-step automations compared with services that meter each action. It also means a buyer must model triggers, retries, polling, error workflows and test runs instead of multiplying only the number of successful business events.
Use this monthly forecast:
| Driver | Example question |
|---|---|
| Scheduled triggers | Does a workflow run every minute even when there is no work? |
| Business events | How many orders, leads, tickets or records start a run? |
| Retries | Does one downstream outage create repeated executions? |
| Manual tests | How often do builders execute workflows during changes? |
| Error handling | Does the error path create a separate execution? |
| Growth and seasonality | What is the plausible high month, not just the average? |
Compare that forecast with the current official n8n pricing page. We do not quote plan prices or allowances because they can vary by billing term, region, tax, offer and date.
Self-hosting removes the Cloud plan’s execution package, but it does not remove limits. CPU, memory, database capacity, worker architecture, queueing, external API quotas and network throughput become the ceiling. Engineering time, monitoring, backups, log storage and incident handling become costs even if the software invoice is low.
What n8n Cloud actually buys
n8n Cloud buys a managed application boundary. The provider handles the underlying hosted service, service updates and core platform availability for the subscribed environment. The team can concentrate on workflows, credentials and business exceptions.
Managed does not mean responsibility-free. The customer still decides which credentials to connect, what data to send, who can edit or activate workflows, how to test changes and how to respond when a third-party API fails. A broken field map is not a hosting incident. Cloud removes server operations, not automation governance.
Cloud is strongest when:
- integrations use public SaaS APIs;
- execution volume fits a plan with reasonable headroom;
- the team lacks an experienced n8n platform operator;
- rapid, supported setup matters more than deployment customization;
- provider-managed updates are acceptable;
- the data path, region, contract and security terms pass review.
Its boundaries appear when a workflow must reach a database or service that is intentionally inaccessible from the public internet, when the team needs a specialized runtime dependency, or when deployment changes must follow an internal change window. Do not expose a private system merely to avoid self-hosting without a security design and qualified review.
What self-hosting really requires
The n8n hosting documentation recommends self-hosting for experienced users and warns that mistakes can cause data loss, security issues and downtime. That warning should drive the decision. Installing a container is only the beginning.
A production owner needs to cover:
- Deployment: supported architecture, database, persistent storage and pinned configuration.
- Secrets: a stable encryption key, credential access, rotation and protected backup.
- Network: TLS, domain, firewall, ingress, outbound rules and private connectivity.
- Identity: user provisioning, least privilege, offboarding and plan/edition capabilities.
- Updates: release review, backup, staging or test, maintenance window and rollback.
- Reliability: health checks, queue/worker design where needed, logs, alerts and capacity.
- Recovery: database and configuration backups plus a regularly tested restore.
- Security: operating-system, container, dependency and n8n vulnerability response.
If nobody is scheduled to receive an alert at the time critical workflows run, the organization does not yet own a reliable service. “The developer who set it up” is not an operating model.
Self-hosting is a strong fit when an existing platform team already provides these controls, the instance needs private-network adjacency, or policy requires deployment inside approved infrastructure. It can also fit sustained high volume, but only after comparing the complete operating cost and risk with Cloud.
Community and paid self-hosted editions are not identical
“Self-hosted” is a deployment choice, not a promise that every enterprise capability is free. n8n documents a self-hosted Community Edition and paid self-hosted offerings with different collaboration, security, governance and support features. The exact current matrix should be checked for projects, environments, source control, external secrets, SSO, log streaming, support and scaling requirements.
This creates a common buying mistake. A team estimates a small server, assumes all Cloud or enterprise controls are included, then discovers that the required governance belongs to another edition or requires additional infrastructure. Write the control list before estimating cost.
The n8n license also deserves review for commercial or embedded use. Running internal workflows and offering n8n functionality to customers are different use cases. Read the current license and obtain appropriate advice rather than inferring rights from the availability of source code.
Data control is not the same as data safety
Self-hosting can give an organization greater control over location, network routes and backups. It can keep n8n close to private systems. It does not automatically make the deployment secure, compliant or private. A publicly exposed instance with weak authentication and untested backups may be worse than a reviewed managed service.
Cloud similarly should not be accepted on brand trust alone. Review current subprocessors, region options, encryption, retention, access controls, backup behavior, deletion, incident terms and contractual commitments for the exact plan. Map every connected service because workflow payloads can cross several providers.
Use a data-path worksheet:
| Stage | Record |
|---|---|
| Trigger | What system sends which data? |
| n8n | What execution data and credentials are stored, and for how long? |
| Nodes | Which third parties receive fields? |
| Logs/errors | Can sensitive payloads appear in retained execution data? |
| Backup | Where are database, key and configuration copies stored? |
| Deletion | How is data removed from active systems and backups? |
Minimize fields, redact logs where supported and avoid using production secrets in test workflows. Obtain qualified security, privacy and compliance review for consequential data.
Code and community nodes increase both power and burden
n8n can move beyond simple no-code connections through expressions, code and community nodes. Self-hosting generally offers more control over the runtime and installed components. That flexibility expands the attack surface and maintenance burden. A community package can access workflow data and credentials within its permissions; it is software, not a harmless template.
Cloud imposes a more controlled environment. Whether that is a limitation or a benefit depends on the workflow. If a standard node or HTTP request covers the job, managed constraints can reduce operational variability. If the workflow needs a private binary or nonstandard package, self-hosting may be necessary, but the package must enter the organization’s dependency and vulnerability process.
Migration is possible, but plan the hidden state
n8n workflows can be exported, which makes movement between environments more practical than rebuilding every node. A production migration still includes credentials, encryption keys, webhooks, callback URLs, environment variables, binary data, users, execution history, network allowlists and external OAuth registrations.
Use a staged migration:
- Inventory workflows, credentials, schedules, webhooks and dependencies.
- Export and protect workflow definitions without exposing secrets.
- Recreate credentials through an approved secret process.
- Disable triggers in the target during testing.
- Test representative success, duplicate, delay and failure cases.
- Plan a trigger cutover that prevents double processing.
- Reconcile business records after the switch.
- Keep a time-limited rollback route and then decommission cleanly.
Portability lowers lock-in but does not eliminate operational change.
Methodology and limits
We reviewed the current n8n pricing, Cloud overview, hosting guidance, Community Edition feature documentation, configuration and security-related documentation. We compared those first-party boundaries with current 2026 operator analyses from OpsHarbor, StackSheriff and York Studio to confirm active demand and surface practical evaluation questions. We did not adopt their quoted hosting costs or unverified universal claims.
We did not deploy or audit either route. This comparison does not guarantee cost, uptime, performance, security, compliance or migration success. Features and plans change. Test with non-sensitive representative workflows and review current official and contractual material.
Bottom line
n8n Cloud is usually the better first production route because it lets a small team prove its workflows before taking on platform operations. Self-hosted n8n becomes the better choice when an organization can operate it responsibly and has a specific reason: private connectivity, deployment control, required data location, specialized runtime needs or scale that survives a full-cost comparison.
Do not self-host because the server price looks lower. Do not choose Cloud because “managed” sounds risk-free. Map executions, data paths, controls, ownership and recovery, then choose the boundary your team can actually sustain. For adjacent planning, use our guides to integration logging and debugging, reducing integration errors, and automation compliance needs.