Guide pour changer de serveur avec n8n auto-hébergé : approche blue-green avec migration des données, basculement DNS et interruption minimale.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Fondateur de NordFlux. Sept ans d'expérience, du web et du SEO jusqu'à l'automatisation à l'échelle d'un groupe, aujourd'hui pragmatique pour les PME et avec une souveraineté des données allemande.
Certifications
Comment installer n8n avec Docker Compose : Postgres au lieu de SQLite, .env, volumes et mises à jour étape par étape.
Préparer le nouveau serveur, migrer workflows et identifiants, basculer le DNS en blue-green : chaque étape comporte ses propres pièges lorsque les workflows en production doivent continuer à tourner pendant la transition. NordFlux planifie et accompagne votre migration de serveur n8n pour que vos automatisations se poursuivent sans interruption perceptible.
