Changement de serveur sans interruption

Un changement de serveur pour n8n auto-hébergé réussit sans interruption notable si vous procédez selon le principe blue-green : le nouveau serveur est entièrement mis en place en parallèle de l'ancien et testé avec les données migrées avant que le basculement DNS ne redirige le trafic. Il est essentiel que les workflows, les identifiants et la base de données n8n soient transférés intégralement et avec la même clé de chiffrement vers le nouveau serveur, car n8n utilise la N8N_ENCRYPTION_KEY pour déchiffrer les identifiants stockés. Quiconque oublie cette clé lors du déménagement perd l'accès à tous les identifiants enregistrés, même si les workflows eux-mêmes ont pu être importés. Situation : juillet 2026.

Préparer le nouveau serveur

Avant de migrer quoi que ce soit, le nouveau serveur (par exemple une instance Hetzner Cloud fraîchement créée) doit être opérationnel, y compris Docker ou Docker Compose, un reverse proxy et des règles de pare-feu pour les ports 80 et 443. Pour les configurations Hetzner, la documentation n8n sur l'hébergement chez Hetzner décrit la mise en place avec Docker Compose et Caddy comme reverse proxy, avec des volumes persistants pour les données n8n.

• Environnement Docker : n8n et le reverse proxy s'exécutent en tant que conteneurs avec leurs propres volumes, afin que les données survivent aux redémarrages.
• Sous-domaine de test : Créez d'abord une deuxième entrée DNS (par exemple n8n-nouveau.votredomaine.fr), afin de pouvoir tester le nouveau serveur avant de basculer le domaine principal.
• Même version n8n : Vérifiez que la version n8n du nouveau serveur correspond à celle de l'ancien serveur, ou qu'elle est mise à jour délibérément, afin d'éviter des erreurs d'importation.

Migrer les workflows, les identifiants et la base de données

n8n propose des commandes dédiées pour l'export et l'import via les commandes CLI pour l'export et l'import qui traitent séparément les workflows et les identifiants. Une sauvegarde complète peut être créée avec les options --backup et --output, et restaurée à l'import avec --input et --separate.

• Exporter les workflows : n8n export:workflow --backup --output=backups/latest/ sauvegarde tous les workflows formatés et sous forme de fichiers individuels.
• Exporter les identifiants : n8n export:credentials --backup --output=backups/latest/ sauvegarde les identifiants toujours chiffrés ; l'option --decrypted les affiche en clair et ne doit être utilisée que pour des migrations contrôlées.
• Importer sur le nouveau serveur : n8n import:workflow --separate --input=backups/latest/ et n8n import:credentials --separate --input=backups/latest/ restaurent les fichiers.
• Reprendre la clé de chiffrement : Définissez N8N_ENCRYPTION_KEY sur le nouveau serveur exactement à la valeur de l'ancien serveur, sinon les identifiants importés ne pourront pas être déchiffrés.
• Tenir compte du dossier de base de données : Le dossier derrière N8N_USER_FOLDER contient, en plus de la base de données SQLite, d'autres données de configuration locales et doit également figurer dans la sauvegarde, sauf si vous passez de toute façon à une base de données PostgreSQL externe.

Selon la documentation n8n, ces commandes exportent également les identifiants internes (ID) des workflows et des identifiants. Si des enregistrements portant les mêmes ID existent déjà sur le serveur cible, ils sont écrasés lors de l'importation, un point important si le nouveau serveur n'est pas configuré totalement vide. Les workflows importés sont en outre désactivés par défaut et doivent être réactivés délibérément après vérification.

Après l'importation : testez manuellement les workflows critiques via le sous-domaine de test, vérifiez les déclencheurs, les webhooks et les connexions aux services externes, et comparez par sondage le nombre de workflows et d'identifiants entre l'ancien et le nouveau serveur.

Basculer le DNS : blue-green sans interruption

Ce n'est que lorsque le nouveau serveur fonctionne de manière fiable sous le sous-domaine de test que le domaine réel est basculé. Réduisez au préalable le TTL de l'entrée DNS concernée à une valeur basse (par exemple 300 secondes), afin que le basculement prenne effet rapidement. Modifiez ensuite l'enregistrement A du domaine principal vers l'adresse IP du nouveau serveur. Pendant la période de transition, l'ancienne et la nouvelle instance fonctionnent en parallèle, de sorte que les requêtes entrantes peuvent être brièvement réparties entre les deux serveurs selon l'état du cache DNS. Pour les workflows pilotés par webhook, cela peut entraîner que certains appels atteignent l'ancien serveur au lieu du nouveau pendant la fenêtre de basculement, c'est pourquoi les workflows fortement utilisateurs de webhooks doivent être particulièrement surveillés pendant cette phase.

Désactiver l'ancien serveur

Après le basculement DNS, attendez au moins la durée de l'ancien TTL plus une marge de sécurité avant de désactiver l'ancien serveur. Pendant ce temps, vérifiez les journaux du nouveau serveur pour le trafic entrant et assurez-vous qu'aucune exécution importante ne s'exécute plus sur l'ancien système. Ce n'est que lorsque le nouveau serveur traite l'ensemble du trafic de manière stable sur une période prolongée que vous devriez arrêter l'ancien serveur et archiver une dernière sauvegarde avant sa suppression définitive. NordFlux applique cette approche par défaut lors des changements de serveur pour les clients disposant d'un n8n auto-hébergé, afin de préserver en permanence la souveraineté des données allemande et le contrôle de l'infrastructure.

Questions fréquentes sur le changement de serveur sans interruption

Combien de temps dure un changement de serveur blue-green avec n8n ?

Cela dépend du nombre de workflows, du volume de données et du TTL des entrées DNS. La migration proprement dite des données est généralement terminée en quelques minutes, le basculement DNS avec marge de sécurité peut prendre quelques heures selon la configuration du TTL.

Que se passe-t-il si la clé de chiffrement n'est pas transférée ?

Sans la N8N_ENCRYPTION_KEY identique, les identifiants importés ne peuvent pas être déchiffrés. Les workflows apparaissent bien, mais les connexions aux services externes échouent jusqu'à ce que les identifiants soient à nouveau renseignés.

Un simple export de base de données suffit-il pour la migration ?

Pour une migration complète, vous devriez exporter à la fois les workflows et les identifiants via les commandes CLI dédiées de n8n, en plus du dossier de base de données proprement dit ou d'une instance PostgreSQL externe, si celle-ci est utilisée.

Faut-il désactiver n8n pendant la migration ?

Non. Avec l'approche blue-green, l'ancien serveur reste actif et utilisable jusqu'au basculement DNS réussi. La véritable interruption se limite dans l'idéal au bref instant de basculement DNS.