n8n Cloud or self-hosting: assign operating responsibility

Three choices. These are three different choices. A self-hosted server can run Community Edition or a paid edition. An external supplier can perform technical work without automatically providing every licence or security feature you require. Equally, a cloud subscription does not identify who will fix an incorrect CRM mapping in your workflow.

Edition-dependent features. The official deployment overview distinguishes Cloud, self-hosting and edition-dependent capabilities. Check permissions, sharing, version control and identity integration against the actual plan. Self-hosting does not mean every enterprise feature is included for free. This research was checked on 26 September 2026.

Ownership matrix. Begin with an ownership matrix. Assign an owner for the platform, database, workflow logic, credentials and connected applications. These responsibilities can sit with different organisations, but their handoffs still need to work. If each supplier assumes another party owns recovery, the architecture has an operational gap before the first workflow is launched.

The table pairs five starting situations with a plausible starting choice between n8n Cloud and self-hosting and the points to establish first.

Decision aid. This is a decision aid, not a compatibility guarantee. An internal system may communicate with a hosted platform through an approved interface. Conversely, installing n8n locally does not authorise access to every private system. Network and application owners still need to approve the connection.

Regions. Do not make geographic assumptions from a supplier's headquarters or your own office location. Record the actual deployment region, connected services and support arrangements when those affect your requirements.

Expired token. Imagine a workflow transferring approved service orders to a CRM. At 10 am its access token expires. In either deployment model, the business process remains blocked until somebody notices the failure and restores access. Cloud hosting does not repair a customer-controlled permission problem.

Database failure. If the self-hosted database fails, your operations team must arrange recovery. In a hosted service, infrastructure handling follows the provider's contracted scope. The relevant evidence is the agreement and your internal operating arrangement, rather than the word “managed” on a product page.

For every important process, establish who:

• receives the alert
• checks which orders were already written
• renews access
• processes waiting cases
• informs the business team

These questions should be answered before choosing hosting. They often reveal whether the apparently cheaper option actually covers the service you need.

Operating basics. An accessible editor is only the beginning. Plan the domain and encrypted access, persistent storage, database, backups, monitoring and a tested update procedure. The official self-hosting guide describes supported installation approaches. Obtain version-dependent commands from current documentation rather than an older tutorial.

Capacity. Your operating plan also needs to cover storage growth, saved execution cleanup and large files. A short text workflow has a different resource profile from several simultaneous document-processing jobs. Measure representative file sizes and peak activity before choosing server capacity.

Test environment. A test environment must not send genuine notifications, initiate payments or create accounting entries. Use separate credentials and controlled targets. During recovery exercises, initially prevent schedules and incoming events from activating so that two instances do not process the same business transaction.

Surrounding infrastructure. Someone also needs to maintain the surrounding infrastructure. Certificates expire, database volumes fill and identity policies change. Decide whether these duties sit with your team or a supplier, and make absence cover explicit.

Backup scope. A workflow export is not a complete instance backup. Depending on the deployment, recovery also requires the database, configuration, encryption material and external storage. The official backup guide provides the technical baseline.

Two objectives. Define two business objectives in plain language: how much captured work could be lost in the worst case, and how long the process may remain unavailable. A nightly backup might suit a process whose source events can all be read again. It may be inadequate for transactions that cannot be reconstructed.

Recovery demonstration. Require a practical recovery demonstration. After the infrastructure is restored, somebody must reconcile the business results. A running server does not prove that an order was sent exactly once or that an approval is still valid.

Cloud boundary. For a cloud option, establish what the provider restores and what your team must reconstruct from the source applications. Keep that boundary in the same operating document used for the self-hosted comparison.

Example 1: no server administrator. The following examples are invented planning scenarios. An Austrian service business uses a public CRM, Microsoft 365 and an internal file server. Two employees will maintain workflows, but nobody currently administers servers. The initial process needs only CRM and email; files already arrive through another approved route.

Cloud pilot. A cloud pilot is a plausible starting decision. The team first checks account permissions, data categories and required administrative features. Its decision record states that direct file-server integration is outside the initial scope. A later proposal to connect it directly triggers a fresh architecture review.

Example 2: existing platform team. A second business has a platform team, an internal API, established backups and existing monitoring. Self-hosting may fit well. However, the decision becomes credible only after that team accepts n8n into its maintenance and incident procedures. Existing servers alone do not demonstrate spare operating capacity.

What the examples show. Neither example proves one option is universally cheaper or safer. They show why the same product can require different deployment choices in two otherwise similar companies.

Annual comparison. Compare a full year of implementation, platform charges, connected services and internal labour. Check renewal prices and support boundaries in hosting offers. For a fair comparison, both options must cover the same recovery objectives and workflow maintenance responsibilities.

Exit plan. An exit plan needs organisation-owned accounts, documented connections, exportable workflows and a secure method for transferring or recreating credentials. Establish which features disappear if you change edition. A workflow file may move successfully while its permission model or an operational feature does not.

Decision record. Record the final decision on one page: connected systems, network routes, edition, accountable people, recovery objectives and unresolved assumptions. Revisit it when user numbers, data sensitivity or business criticality changes substantially. This keeps the decision understandable after the original project lead has moved on.

Different service scopes. Managed hosting can describe very different services. One supplier may install the platform and update the operating system. Another may also manage the database, n8n updates, monitoring and recovery. Business validation of your workflows can remain separate in either case. Describe each service through its outcome and owner.

Backups, updates and monitoring. For backups, ask more than whether they are included. Which components are covered, how long are backups retained, who controls the required encryption key and who can request recovery? For updates, ask about testing, maintenance windows and an incompatible node. For monitoring, establish whether the service checks only platform availability or also detects business cases that remain unprocessed.

Out-of-hours cover. Agree who acts outside normal working hours. An alert sent to an inbox nobody reads until Monday offers little help to a time-sensitive weekend process. Conversely, a weekly internal report does not automatically require expensive round-the-clock cover. The process and its manual fallback determine the service required.

Handoffs. Make handoffs explicit as well. If a hosting supplier identifies an expired CRM credential, someone still needs authority to renew it. The incident should not bounce between providers because each considers its own component healthy. Give one person responsibility for coordinating recovery of the overall business process.

These cases are synthetic. The same technical platform is available to both, but their requirements differ substantially.

Weekly internal report: All source information remains in the authoritative CRM. An outage on Tuesday may be recoverable on Wednesday. A nightly backup and documented rebuild might be sufficient if lost intermediate work can be recreated from the source. The process owner must confirm whether that meets the actual reporting need.

Timely service coordination: Incoming jobs are assigned and promised callbacks recorded across several systems. After an outage, restoring last night’s database and executing everything again may be unsafe because some destination actions already happened. Recovery also needs a dependable intake list, stored destination references and reconciliation before processing resumes.

What differs. The difference is not simply backup frequency. It concerns whether prior work can be reconstructed and completed actions identified. A higher hosting price can be justified if it includes the recovery service you need. It achieves little when the business references required for reconciliation were never stored.

Supplier evaluation. Use these scenarios during supplier evaluation. Ask the proposed operator to describe the recovery sequence, who makes the restart decision and what information would be needed from the business team. That discussion often reveals more than a general uptime statement.

Prepare the move. Cloud and self-hosting are not permanent decisions, but a future move should be considered before an incident forces one. Record workflow files, required nodes, environment settings, account ownership and functions tied to the current edition.

Controlled test. Test the destination with separate or restricted credentials first. Keep schedules, webhooks and other production triggers controlled so that both environments cannot write simultaneously. Agree a clear cutover point and identify which environment will complete cases already in progress.

After cutover. After cutover, compare intake records, successful destination actions and unresolved exceptions. Do not leave the old instance indefinitely connected with active credentials. Define when it will be retired, which records must remain available and how obsolete secrets will be revoked. Moving then becomes a traceable process rather than simply exporting a file.

Assess every option using the same five questions:

• Can it reach the required systems?
• Does it include the necessary features?
• Are named people and cover available?
• Can recovery objectives be met?
• Is the annual total effort affordable?

A mandatory requirement can eliminate an option even when it performs well on several other measures.

Assumptions. Record assumptions explicitly. “The supplier probably handles updates” is not a contractual service. “Our administrator has a server” is not a capacity commitment. Resolve those points before signing. If no specific requirement favours self-hosting and nobody can operate it, a low server rental price should not decide the architecture.

Understandable record. Keep the resulting decision understandable to the next owner. A short record explaining the business requirement and the accepted limitation is more useful than a scoring sheet with unexplained numbers. Revisit it when the business process becomes more critical or its scale changes materially.

Review after the pilot. Finally, schedule a review after the pilot. Use observed workload, incidents and support needs to replace assumptions with evidence from your own process.

These pages cover the service overview and the related decisions for n8n Cloud and self-hosting:

• n8n implementation and workflow operations
• Calculate n8n costs beyond the subscription
• Review n8n data flows and retention
• Back up and restore n8n beyond workflow exports

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.