When n8n Cloud fits and when self-hosted n8n fits
The core trade is simple. n8n Cloud is fully managed with no setup or maintenance, but customization is limited to the options n8n offers. Self-hosting gives you full control over where n8n runs and what it can do, but installation, configuration and maintenance become your responsibility, and n8n's own guidance is that self-hosting requires technical expertise. Choose cloud when the workflows you need fit inside the hosted feature set and your team has no capacity to operate a workflow platform. Choose self-hosting when you need features that only run on your own servers, or when you must control where the data sits. Several conditions should drive the decision. Hosted plans store data in the EU, on servers in Frankfurt, Germany, which may satisfy residency requirements for some teams but not others. Self-hosted data stays wherever you host n8n, so you can select a jurisdiction, network zone or air-gapped environment yourself. Also check the plan itself: the Business plan is currently available only for self-hosted n8n, so if you need SSO, environments with Git or log streaming and want the lower-cost route, you are pointed toward self-hosting. Confirm current plan availability on the n8n pricing page before you commit, because plan terms change.
The Sustainable Use License applies in the same way wherever you host. It permits use and modification for your own internal business purposes or for non-commercial or personal use, and it does not change because the instance runs on n8n's cloud rather than yours. Hosting choice therefore does not settle whether your use case is permitted. Ask your counsel to review the license against any plan to embed n8n in a product or offer it to customers, since that falls outside internal use. Files with .ee in their name also require an n8n Enterprise License regardless of host.
Before deciding, write down three things: which cloud execution and concurrency limits your workflows would hit, which self-hosted-only features (such as custom nodes or bash scripts) you rely on, and who on your team will patch, back up and upgrade the instance. Test the limits against your own volume, because the cloud plan limits are the binding constraint on hosted use. If you self-host, budget for a database, encryption key handling and upgrades as ongoing work rather than a one-time install.
How n8n Cloud and self-hosted n8n compare on limits and features
This table compares the execution limits, plan gates and features that differ between n8n's hosted cloud plans and self-hosted n8n. Read each row against your expected execution volume, the longest workflows you run, and whether you need custom nodes, SSO or Git-based environments.
| Factor | n8n Cloud | Self-hosted n8n |
|---|---|---|
| Executions and concurrency | Starter: 2,500 executions and 5 concurrent executions per month at 20 euros billed annually. Pro: 10,000 executions and up to 50 concurrent at 50 euros billed annually (n8n pricing page) | No execution quota set by n8n on the free Community edition; your hardware and database set the practical ceiling. Confirm current license terms for execution counts on paid editions |
| Maximum execution duration | 5 minutes on Starter; 40 minutes on Pro and Enterprise (n8n pricing page) | Set by your own configuration; confirm the timeout settings for your version in the n8n docs |
| Saved execution and log retention | Saved executions: 2,500 (Starter), 25,000 (Pro), 50,000 (Enterprise). Log retention: 7 days, 30 days and unlimited by tier | Retention is controlled by your database and your own policies, so you set and store the history |
| Custom nodes and bash scripts | Not available on n8n Cloud | Available; running bash scripts and custom nodes is a self-hosted feature |
| Tracing options | LangSmith and OpenTelemetry tracing are not available on n8n Cloud | LangSmith and OpenTelemetry tracing are available in self-hosted n8n |
| SSO and LDAP | Included only on Business and Enterprise plans | Included on Business and Enterprise self-hosted plans; SAML guides exist for Okta and Azure AD |
| Git environments and log streaming | Included only on Business and Enterprise plans | Included on Business and Enterprise self-hosted plans; confirm the edition that covers your exact setup |
| Business plan (667 euros per month billed annually) | Not offered on n8n Cloud; currently self-hosted only | Available as a self-hosted plan; confirm current availability and terms on the pricing page |
| Free trial and free entry point | Trial includes 1,000 executions, 5 concurrent, 180-second timeout and 1 team project, without admin roles or the public API | Free Community edition is the self-hosted entry point; you bear the infrastructure and operations cost |
Where your workflow data lives in each model
Hosted plans store data in the EU, on servers in Frankfurt, Germany, while self-hosted data stays wherever you host n8n. For a data residency review, that difference decides the first question: is the workflow data, including execution records and stored credentials, a processor-held dataset you must document under a contract with n8n, or a dataset that never leaves your own cloud account, data center or network? Pull the n8n pricing FAQ and confirm with n8n the exact data handling terms, subprocessors and retention behavior that apply to your jurisdiction and sector before the review starts. Do not assume that the Frankfurt location alone answers a transfer, access or breach-notification question. Ask n8n in writing what it can contractually commit to and what it cannot.
With self-hosting, your team holds the encryption key and the credentials it protects. In a single-process deployment, that key sits with the instance that stores encrypted credentials in its database. In queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read those credentials, so the key is copied to each process that runs executions. Treat that copy as a secret with its own owner: restrict where it is stored, rotate it through a planned procedure, and confirm that a worker host compromise does not expose more than the credentials that worker needs. Test a restore on a separate host to confirm that the key and database backup are kept together under the same controls.
Before you approve either model, write down three answers: which region hosts the database and any binary data, who can read the encryption key, and which party signs the data processing terms. Verify each answer against your own architecture diagram rather than the vendor summary. If the answers point to a hosted plan, ask n8n to confirm the Frankfurt storage scope in writing. If they point to self-hosting, your evidence will come from your own infrastructure records, so start collecting it early.
What compliance teams should check before choosing a host
Choosing between n8n Cloud and self-hosted n8n moves several compliance questions with it: where data sits, who controls the keys and logs, and who changes the host. The cards below set out the decisions to document before a workflow platform touches regulated data. DeployOpen prepares systems, controls and evidence for assessment, but independent auditors issue any attestation, and neither option described here is presented as certified or audited.
Data residency and location
Hosted n8n plans store data in the EU on servers in Frankfurt, Germany, according to the n8n pricing FAQ. Self-hosted data stays wherever you host n8n, which may be a region, a data center or an air-gapped network. Ask which regions your data protection rules allow, where backups and execution logs are copied, and whether any sub-processors receive workflow data. Record the answer in your data map before go-live.
SSO and access control by plan
SSO and LDAP are included only in the Business and Enterprise plans, according to n8n's pricing page. SAML single sign-on is documented for Okta Workforce Identity and Azure AD. Check which plan you need before assuming federated login, then confirm how role assignments, deprovisioning and admin accounts are handled. Your identity team should test a leaver scenario end to end.
Audit and log streaming access
Log streaming is included only in the Business and Enterprise plans. Execution log retention on cloud plans is 7 days on Starter, 30 days on Pro and unlimited on Enterprise, per n8n's pricing comparison. Ask whether your assessors need logs for longer than your plan keeps them, and whether logs can be streamed to your own SIEM. If you self-host, you own log retention and storage from the start.
Custody of the encryption key
Self-hosted queue mode requires the main instance's encryption key to be shared with every worker and webhook processor so they can read credentials stored in the database. Key custody is therefore a design decision you control when self-hosting. On a hosted plan, ask the vendor how keys are generated, stored, rotated and destroyed, and whether you can hold any key material yourself. Document who can read the key and how access is logged.
Change control over the host
On n8n Cloud, the platform team controls upgrades and infrastructure, and your options are limited to those the vendor exposes. When self-hosting, you choose when to move between n8n 1.x and 2.x releases, when to apply patches and how to test them. Ask for a written change process, a rollback path and a record of which version ran in each period. Also confirm whether custom nodes and bash scripts are part of your change scope, since they are self-hosted only.
Evidence for assessors
Assessors usually ask for configuration records, access reviews, backup tests and incident logs, not a single certificate. DeployOpen can prepare systems, controls and evidence for a compliance assessment, but it does not issue audit reports or certifications. Independent auditors and certification bodies make that determination. Before choosing a host, list the evidence each assessor expects and confirm which of it the hosting option can produce without manual reconstruction.
Which features you can use on Cloud and which need self-hosting
The hosted plans run n8n's managed service, and data on hosted plans is stored in the EU on servers in Frankfurt, Germany. Starter costs 20 euros per month billed annually and Pro costs 50 euros per month billed annually, and both include unlimited users, workflows and integrations. The limits below decide whether a hosted plan fits your workload, so read them against your run volume and your longest workflow before you commit.
- Execution quota: Starter includes 2,500 workflow executions and Pro includes 10,000. Each execution counts as one run of a whole workflow, regardless of how many steps it contains.
- Concurrency: Starter allows 5 concurrent executions and Pro allows up to 50.
- Duration: A single execution can run for up to 5 minutes on Starter and up to 40 minutes on Pro.
- Saved executions and logs: Starter keeps 2,500 saved executions with 7 days of log retention. Pro keeps 25,000 with 30 days.
- Self-hosted only: Running bash scripts, custom nodes, LangSmith tracing and OpenTelemetry tracing are not available on Cloud.
Before choosing a hosted plan, confirm the current figures on n8n's pricing page, since limits change and a long-running job may reach the duration cap first.
The Community edition is free to self-host and includes the core workflow engine, with unlimited users, workflows and integrations. The cloud execution quotas and concurrency caps do not apply, so capacity depends on the hardware, database and queue design you run. You also take on setup, upgrades, backups and monitoring, which n8n's Choose n8n guidance describes as requiring technical expertise.
- Custom code: Custom nodes and bash scripts run only on self-hosted n8n, so this edition gives you access to them without a paid plan.
- Tracing: LangSmith and OpenTelemetry tracing are self-hosted features, subject to the tracing backend you configure.
- Queue mode: Regular mode runs everything in one process. If you move to queue mode, you add Redis and workers on PostgreSQL, and every worker and webhook processor needs the main instance's encryption key to read stored credentials.
- Identity and governance gaps: SSO, LDAP, environments with Git and log streaming are included in the Business and Enterprise plans, not in Community.
- No multi-main high availability: Running several main instances for high availability is limited to Enterprise self-hosted deployments.
Confirm with n8n which features your Community version includes and whether any limits apply to your installation, and plan the operations work before you rely on it for production workflows.
The Business plan is listed at 667 euros per month billed annually and is currently available only for self-hosted n8n. Enterprise uses custom pricing and covers both self-hosted and cloud deployments. Self-hosted Business and Enterprise keep your data wherever you host n8n, which matters when policy or regulation sets a required location.
- Identity: SSO and LDAP are included in Business and Enterprise. The SAML documentation includes setup guides for Okta Workforce Identity and Azure AD.
- Team controls: Environments with Git and log streaming are included in Business and Enterprise.
- Enterprise only: Multi-main high availability is restricted to Enterprise self-hosted deployments, and files with .ee in their name require an n8n Enterprise License.
- Support: Enterprise adds dedicated support with an SLA. Confirm the SLA terms in the written order form, not from the pricing page alone.
- Operations: Queue mode still needs Redis, workers and PostgreSQL, and the encryption key must be shared with every worker and webhook processor.
Ask n8n for a written quote that maps each feature you need to a specific edition, and confirm current plan terms before you buy.
What your team runs in each model
This table lists each operational task and who carries it on n8n Cloud versus self-hosted n8n. Read the self-hosted column as the work your team would take on, and confirm the detail against the current n8n documentation before you commit.
| Component or task | n8n Cloud | Self-hosted n8n |
|---|---|---|
| Installation and configuration | n8n runs the instance, and your options are limited to those the plan exposes | Your team installs and configures n8n, which the n8n Choose n8n docs describe as requiring technical expertise |
| Hosting and data location | Hosted plans store data in the EU on servers in Frankfurt, Germany, per the n8n pricing FAQ | Data stays wherever you host n8n, so you choose the region, network and access controls |
| Upgrades across 2.x and 1.x | n8n applies updates to the hosted service | Your team plans and applies upgrades, including moving between the 2.x line and 1.x releases that still receive fixes |
| Database | Managed by n8n | You provide the database; queue mode uses PostgreSQL, and SQLite is not recommended for queue mode |
| Redis and worker sizing | Concurrency and execution limits are set by the plan | You run Redis for queue mode and size the worker pool against your execution volume |
| Encryption key management | Handled by n8n | You generate, store and share the main instance key with every worker and webhook processor, since they need it to read credentials |
| Backups and monitoring | Managed by n8n within the plan | Your team designs backups of the database and configuration and monitors the instance and its workers |
| Customization | Limited to the options the plan offers, and bash scripts and custom nodes are not available | Custom nodes and bash scripts are available, but your team owns their code, testing and upkeep |
How to move between n8n Cloud and self-hosted n8n
This sequence gives you a tested inventory of workflows, credentials and dependencies, a target instance that runs them under its own limits, and a clean cutover that leaves the source instance retired rather than running in parallel by accident.
Export and review workflows and credentials
The operator who owns the source instance exports every workflow and reviews the list against the active set, including workflows that are disabled but still needed for quarterly or emergency runs. Confirm the export method and what it includes, including whether credentials move with workflows, with n8n before you start, because export tooling and steps can change between releases. Record each workflow's trigger type, owner and the business process it supports. This step is done when you have a complete inventory that a second person has checked against the live canvas list.
Flag nodes that depend on custom code
Review each workflow for custom nodes, bash script execution and any integration that relies on local files or host-level tools. The n8n pricing page marks running bash scripts and custom nodes as available in self-hosted n8n rather than on n8n Cloud, so any workflow that depends on them cannot move to Cloud as-is. Mark these as either blocked on Cloud or a reason to choose self-hosting. Also note OpenTelemetry and LangSmith tracing, which the same page lists as self-hosted features. This step is done when every workflow has a recorded target: Cloud, self-hosted, or needs redesign.
Recreate credentials and encryption key handling
Credentials are tied to the encryption key of the instance that stores them, so moving to a different instance means re-entering or re-authorizing each credential on the target rather than assuming a copy will decrypt. On self-hosted queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read credentials from the database. Your security team should decide where that key is held and who can read it, and record the decision. This step is done when every credential is working on the target and the key distribution is documented.
Test webhooks and execution limits on the target
Run each migrated workflow on the target with representative inputs and confirm webhook URLs, authentication headers and response behavior. Compare the workflow's longest run with the target plan's limits: the n8n pricing page lists maximum execution durations of 5 minutes on Starter and 40 minutes on Pro and Enterprise, and the trial has a 180-second execution timeout. Check monthly execution volume and concurrency against the plan you are buying. Self-hosted instances are not bound by those cloud plan figures, but they carry their own capacity and database sizing. This step is done when test runs pass and each workflow's peak duration and volume fit the chosen target.
Confirm plan requirements before committing
Check the features your workflows rely on against the plan you intend to use. The Business plan is currently available only for self-hosted n8n, so if you need SSO, environments with Git or log streaming, moving to that tier means running your own infrastructure, not staying on Cloud. The n8n Cloud free trial also lacks the public API, admin roles and the project editor role, so do not use the trial to test administrative or API-driven parts of your process. Confirm pricing, edition terms and the availability of any feature with n8n directly, since these pages change. This step is done when the target edition is chosen in writing and every required feature is confirmed as available on it.
Cut over triggers and communicate the change
Switch production triggers in a planned window: update webhook URLs in upstream systems, re-point schedules and confirm that only one instance is active for each trigger, since two instances firing the same schedule or webhook produces duplicate executions. Notify the teams that call these workflows and agree on a rollback path that re-enables the source instance. Watch the first production executions and error logs on the target. This step is done when the upstream systems send traffic to the target, the source instance has no active triggers, and the first live runs complete without errors.
Retire the source instance
Once the target has run cleanly for the period your operations team agreed on, deactivate the source workflows, revoke credentials that are no longer needed, and archive the final export along with its checksum and the owner's sign-off. For self-hosted sources, remove the old encryption key from systems that no longer need it and decommission database and storage resources after you confirm backup retention rules. For Cloud sources, close or downgrade the plan through the account owner. This step is done when the source has no active triggers, its credentials are revoked, and the archive and sign-off are stored with your records.
Questions buyers ask before choosing a hosting model
What drives the cost of self-hosting n8n compared with the cloud plan prices?
The published cloud prices are fixed monthly subscriptions: Starter at 20 euros and Pro at 50 euros per month, both billed annually, and Business at 667 euros per month billed annually, which is currently self-hosted only, according to n8n's pricing page. Self-hosting removes the subscription for the Community edition but adds costs that n8n does not bill you for: the cloud accounts or servers, the database, Redis if you run queue mode, backups, monitoring, upgrades and the staff time to run them. Those costs recur every month, and the staff time is usually the largest. Ask any quote to separate one-time setup from recurring operations, and to state which n8n edition it assumes, since SSO, Git environments and log streaming are only in Business and Enterprise.
How long does a self-hosted n8n rollout take?
We cannot give a duration without a written scope, because the time depends on the number of workflows to migrate, the integrations and credentials involved, whether you need queue mode with separate workers, the identity provider you connect, and the network and approval steps in your environment. A single-instance install on infrastructure you already run is a different job from a production deployment with backups, monitoring and an upgrade process. Ask for a fixed-scope proposal that lists the deliverables and the timeline for each, and confirm the assumptions about your environment before work starts.
What skills does our team need to run self-hosted n8n?
n8n's Choose n8n documentation says self-hosting requires technical expertise for installation and configuration and leaves infrastructure and maintenance to the customer. In practice, you need people who can operate a Node.js application, a relational database, and a reverse proxy with TLS, and who can handle backups and restores. If you run queue mode, you also need someone comfortable with Redis and worker processes, and someone who understands that the encryption key must be shared with every worker and webhook processor so they can read stored credentials. Security owners should own access control, secrets handling and the upgrade cadence.
Can a small team run self-hosted n8n without outside help?
Yes, a small team can run a single n8n instance internally if it has the skills above and accepts the ongoing maintenance. Whether it should depends on how much workflow depends on n8n, how often the team can patch and back up, and whether anyone can respond outside working hours. Teams that choose Cloud avoid that work but accept limits on execution duration, concurrency and customization. Many teams split the work: they keep day-to-day workflow building in-house and buy help for the initial hardening, upgrades or continuous support through a retainer. Be clear about which of these tasks the team will own after handover.
Can we lift the execution limits on n8n Cloud?
The cloud plans come with fixed limits. The pricing comparison lists maximum execution durations of 5 minutes on Starter and 40 minutes on Pro and Enterprise, and concurrent execution limits per plan, with the free trial capped at a 180-second timeout. Those limits are part of the plan you buy, so if a workflow needs longer runs or more concurrency, the practical options are a higher cloud plan where it covers your need, or self-hosting, where you set the limits yourself within the capacity you provide. Confirm current limits on the pricing page before deciding, because plan terms change.
How do we ask for a fixed-scope quote for a self-hosted n8n deployment?
Send a written brief that lists the target environment, such as which cloud account, data center or air-gapped network, the n8n edition you intend to use, whether you need queue mode or multi-main high availability, the identity provider you want to connect, the number and type of workflows to move, and the backup, monitoring and upgrade expectations. Ask for deliverables, acceptance criteria, assumptions, client responsibilities and the timeline in writing before work starts. DeployOpen works to fixed scopes agreed in writing and does not publish a price list, so the quote follows from that scope. Ask for ongoing support or upgrades as a separate retainer so the one-time and recurring costs stay visible.
Which team profile should pick each option
The deciding question is usually who will operate the instance and where the data must sit. The three profiles below are hypothetical and illustrative, but each one maps to a specific fact in the n8n documentation. Start with a team that has no platform staff and modest volume. For this team, n8n Cloud is usually the better fit, because the hosted plans remove installation and upgrades. The Starter plan covers 2,500 workflow executions with 5 concurrent executions and a 5-minute maximum execution duration, per n8n's pricing page. The cost of being wrong here is a long-running workflow that hits the duration cap, or a burst of runs that queues behind the concurrency limit. Before committing, export a week of real run counts and longest run times and compare them with those limits.
A second profile is a team with data residency rules that require control over the hosting location. n8n states that hosted plan data is stored in the EU on servers in Frankfurt, Germany, while self-hosted data stays wherever the customer hosts n8n. If your regulator, contract or internal policy requires a specific country, a specific cloud region or a specific data center, the hosted Frankfurt option may not satisfy it, and self-hosting becomes the default. The condition that matters is whether the location itself is the constraint. If it is, the cost of being wrong is a migration of workflows, credentials and execution history after go-live, which is far more expensive than deciding up front. Confirm the exact requirement with your legal and compliance owners, and ask any self-hosting partner to document where the database, Redis and binary data reside.
A third profile is a team that needs custom nodes or bash scripts. According to n8n's pricing page, running bash scripts and custom nodes is available only in self-hosted n8n, not on n8n Cloud. For an engineering team that wraps internal APIs in custom nodes or calls scripts on the host, self-hosting is the only option that works, regardless of volume. The cost of being wrong is building flows on Cloud and then rewriting them after discovering the limit. Self-hosting shifts that cost onto the team, so ask who will patch the host, manage the encryption key shared with worker processes and handle upgrades across n8n's release lines before choosing this path.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For n8n, that means working out first whether self-hosting fits your licensing, data residency and operations model, then building and handing over only what the agreed scope covers.
How we scope
- Written scope fixes which workflows, credentials, integrations and environments are in and out before work starts.
- We confirm your n8n edition needs, including which SSO, Git or log streaming features your plan must include.
- Engagements are fixed-scope, and ongoing support is available as a retainer once the handover is complete.
How we build
- We install and configure n8n in your infrastructure, choosing regular or queue mode based on agreed execution volume.
- Queue mode setup covers Redis, PostgreSQL, worker nodes and the shared encryption key that workers need.
- We test workflows, credential handling, webhook paths and access controls against the scope before release.
How we hand over
- Deliverables include architecture notes, configuration documentation and backup and restore procedures for your team.
- We document which features depend on self-hosting, such as custom nodes and bash script execution, so owners understand them.
- Handover walks your operators through upgrades, release tracking and the decisions that remain with your team.
How we support
- Retainers cover ongoing support, upgrades, continuous testing and documentation updates for the self-hosted instance.
- Upgrade planning follows n8n's release line, so changes are tested in your environment before production rollout.
- Before any quote, ask us to confirm hosting location, data residency needs and who will own day-to-day operations.
