Server change without downtime

A server change for self-hosted n8n succeeds without noticeable downtime if you follow the blue-green principle: the new server is built completely in parallel to the old one and tested with the migrated data before the DNS switch redirects traffic. It is crucial that workflows, credentials and the n8n database are transferred completely and with the same encryption key to the new server, because n8n uses the N8N_ENCRYPTION_KEY to decrypt stored credentials. Anyone who forgets this key during the move loses access to all stored credentials, even if the workflows themselves could be imported. As of: July 2026.

Preparing the new server

Before you migrate anything, the new server (for example a fresh Hetzner Cloud instance) should be set up and operational, including Docker or Docker Compose, reverse proxy and firewall rules for ports 80 and 443. For Hetzner setups, the n8n documentation on hosting on Hetzner describes the setup with Docker Compose and Caddy as reverse proxy, including persistent volumes for the n8n data.

• Docker environment: n8n and the reverse proxy run as containers with their own volumes, so that data survives restarts.
• Subdomain for testing: First create a second DNS entry (for example n8n-new.yourdomain.com), so that you can test the new server before the main domain is switched over.
• Same n8n version: Check that the n8n version on the new server matches the version on the old server, or is deliberately updated, to avoid import errors.

Migrating workflows, credentials and the database

n8n offers dedicated commands for export and import via the CLI commands for export and import that handle workflows and credentials separately. A complete backup can be created with the flags --backup and --output, and restored on import with --input and --separate.

• Export workflows: n8n export:workflow --backup --output=backups/latest/ backs up all workflows formatted and as individual files.
• Export credentials: n8n export:credentials --backup --output=backups/latest/ backs up the credentials still encrypted; the --decrypted option shows them in plain text and should only be used for controlled migrations.
• Import on the new server: n8n import:workflow --separate --input=backups/latest/ and n8n import:credentials --separate --input=backups/latest/ restore the files.
• Transfer the encryption key: Set N8N_ENCRYPTION_KEY on the new server to exactly the value from the old server, otherwise imported credentials cannot be decrypted.
• Note the database folder: The folder behind N8N_USER_FOLDER contains, besides the SQLite database, other local configuration data as well and also belongs in the backup, unless you are switching to an external PostgreSQL database anyway.

According to the n8n documentation, these commands also export the internal IDs of workflows and credentials. If records with the same IDs already exist on the target server, they are overwritten during import, an important point if the new server is not set up completely empty. Imported workflows are also disabled by default and must be deliberately reactivated after checking.

After the import: manually test critical workflows via the test subdomain, check triggers, webhooks and connections to external services, and spot check the number of workflows and credentials between the old and new server.

Switching DNS: blue-green without downtime

Only once the new server runs reliably under the test subdomain is the actual domain switched over. Beforehand, lower the TTL of the affected DNS entry to a low value (for example 300 seconds), so that the switch takes effect quickly. Then change the A record of the main domain to the IP address of the new server. During the transition period, the old and new instance run in parallel, so that incoming requests can briefly be distributed to both servers depending on the DNS cache state. For webhook-driven workflows, this can mean that individual calls reach the old instead of the new server during the switchover window, which is why webhook-intensive workflows should be monitored especially closely during this phase.

Shutting down the old server

After the DNS switch, wait at least the old TTL time plus a safety buffer before shutting down the old server. During this time, check the logs of the new server for incoming traffic and make sure that no important executions are still running on the old system. Only once the new server has been handling all traffic stably for a longer period should you stop the old server and archive one last backup before it is permanently deleted. NordFlux applies this approach by default for server changes for customers with self-hosted n8n to continuously maintain German data sovereignty and control over the infrastructure.

Frequently asked questions about server changes without downtime

How long does a blue-green server change take with n8n?

This depends on the number of workflows, the amount of data and the TTL of the DNS entries. The actual migration of the data is usually done within minutes, the DNS switch with a safety buffer can take a few hours depending on the TTL configuration.

What happens if the encryption key is not transferred?

Without the identical N8N_ENCRYPTION_KEY, imported credentials cannot be decrypted. Workflows do appear, but connections to external services fail until the credentials are re-entered.

Is a simple database export enough for the migration?

For a complete migration, you should export both the workflows and the credentials via the dedicated n8n CLI commands, in addition to the actual database folder or an external PostgreSQL instance, if one is in use.

Does n8n have to be shut down during the migration?

No. With the blue-green approach, the old server remains active and usable until the DNS switch is successful. The actual downtime is, in the ideal case, limited to the brief DNS switchover moment.