Self-Hosted to Cloud: When Switching Makes Sense for n8n

The switch from a self-hosted n8n instance to n8n Cloud is worthwhile above all when the effort for servers, updates and backups outweighs the benefit of a fully controlled environment. However, not everything automatically carries over: according to the n8n documentation, unverified community nodes and self-built nodes only run self-hosted, executions are numerically capped depending on the Cloud plan, and credentials must be manually recreated after the move, because exported workflow files only contain the names and IDs of credentials, not their values. Anyone who knows these points in advance avoids nasty surprises after the migration. As of: July 2026.

When switching to the Cloud makes sense

With self-hosted n8n, according to n8n itself, you bear full responsibility: you provide the infrastructure, manage it, and are responsible for updates, security patches and backups. n8n Cloud reverses this relationship. According to the official overview of usage options it is fully managed, no setup is needed, and n8n takes care of maintenance and operation. For teams without their own IT capacity or with little time for server upkeep, this is a real advantage. The price for this: you give up part of the control you deliberately built up with self-hosting, and pay an ongoing subscription instead of pure infrastructure costs.

What does not automatically come along with the move

The biggest difference concerns nodes. On n8n Cloud, according to the documentation on the installation of community nodes you can only install verified community nodes via the node panel. Unverified nodes and installation via npm are only possible self-hosted. Anyone using their own or rare nodes must therefore check before the move whether these nodes are verified, because otherwise they will simply disappear in the Cloud.

• Nodes: Only verified community nodes run in the Cloud, npm installations and self-built nodes remain self-hosted.
• Credentials: According to the export and import documentation, exported workflow JSONs only contain names and IDs of credentials, not their values. After the import you must manually re-enter all credentials.
• Configuration: Fine-tuning via environment variables, which forms the basis of configuration when self-hosted, is only possible to a limited extent in the Cloud, since the instance is managed.

Execution limits and resources compared

Self-hosted, the number of executions is practically limited only by your own server hardware. In the Cloud, fixed quotas apply per plan. According to the n8n pricing list, the Starter plan includes 2,500 executions per month with 5 concurrent runs, the Pro plan 10,000 executions with 20 concurrent runs, the Business plan 40,000 executions plus SSO, SAML, LDAP and Git-based environments. The storage of execution logs is also capped: according to the Cloud data management, the Starter plan stores a maximum of 2,500 executions with 7 days of retention, Pro up to 25,000 with 30 days, Enterprise up to 50,000 with unlimited retention. From 85 percent storage utilization, n8n can automatically clean up older execution data. Memory is also tiered, from 320 MiB in the Starter and trial plan up to 4,096 MiB in Enterprise, while self-hosted you choose the server size yourself.

What specifically needs to be done for the migration

Workflows can be exported as JSON and imported into the Cloud instance. Before doing so, it is worth taking a short inventory: which nodes are in use, and are all of them listed as verified in the Cloud. After that, the credentials are created by hand in the new environment, since, as described, the exported files contain no secrets. Anyone who has previously worked with environment variables or their own database settings should document this configuration before the move, because it does not exist in the same form in the managed Cloud environment. For teams that want to plan the move technically cleanly and with clear prioritization, n8n consulting is available, which checks in advance which workflows run unchanged and where adjustments are needed.

Frequently asked questions about self-hosted to Cloud migration with n8n

Do all self-hosted workflows run unchanged in the Cloud?

Only if all nodes used are among the verified community nodes or are n8n standard nodes. Workflows with unverified or self-built nodes must be adapted or replaced before the move, because, according to n8n documentation, these cannot be installed in the Cloud.

What happens to my credentials during the move?

They must be recreated. The workflow export only contains names and IDs of the credentials, no passwords, tokens or keys. This makes sense from a security perspective, but it means manual effort after the import.

Can I switch back to self-hosted later?

In principle, workflows can be exported again and imported into a self-hosted instance. Cloud-specific restrictions then no longer apply, but in return you again take on full responsibility for operation, updates and backups.

How many executions are included in the cheapest Cloud plan?

According to the current pricing list, the Starter plan offers 2,500 executions per month with a maximum of 5 concurrent runs. Anyone who needs more must switch to Pro or Business, or stay self-hosted, where the limit depends on their own server hardware.