Migrer de n8n Cloud vers l'auto-hébergement

Selon la documentation officielle de n8n, la migration de n8n Cloud vers une instance n8n auto-hébergée n'est pas possible de manière automatisée : les workflows peuvent être exportés sous forme de fichiers et importés dans le nouvel environnement, mais les identifiants (credentials) ne peuvent pas être exportés pour des raisons de sécurité et doivent être entièrement recréés dans le système cible. De plus, l'adresse du webhook change lors du passage à un domaine propre, de sorte que chaque connexion externe qui sollicite n8n via un webhook doit être reconfigurée. Quiconque planifie ces deux points dès le départ évite les pièges les plus courants lors du changement. Situation en juillet 2026.

Pourquoi les entreprises passent-elles de n8n Cloud à l'auto-hébergement ?

Les entreprises changent surtout pour des raisons de souveraineté des données, de contrôle des coûts et d'intégration plus poussée dans leur propre infrastructure. Avec n8n Cloud, les données des workflows et les journaux d'exécution sont hébergés sur les serveurs du fournisseur, tandis qu'avec l'auto-hébergement, vous déterminez vous-même sur quel serveur et dans quel pays les données sont stockées. S'y ajoutent des facteurs tels que des coûts fixes plutôt que des coûts liés à l'utilisation et la possibilité de connecter n8n directement à des systèmes internes, des VPN ou des bases de données propres, ce qui n'est pas possible dans la même mesure avec la variante cloud.

Comment exportez-vous vos workflows depuis n8n Cloud ?

L'export s'effectue via le panneau d'administration de votre instance cloud : vous y ouvrez la section Manage, sélectionnez Export et téléchargez les workflows sous forme de fichiers. Le guide officiel de n8n sur la migration du cloud vers l'auto-hébergement indique explicitement qu'il n'existe pas de voie de migration automatisée et que le processus d'export-import via l'interface utilisateur est la méthode prévue. Vérifiez également les workflows inactifs et les brouillons afin que rien ne manque lors de l'import.

Pourquoi les identifiants doivent-ils être entièrement recréés ?

Les identifiants ne peuvent généralement pas être exportés depuis n8n Cloud, car, pour des raisons de sécurité, ils sont liés au chiffrement de l'instance concernée. Après l'import des fichiers de workflow, vous recréez donc manuellement chaque connexion d'identifiants, par exemple vers Google, Slack, Microsoft ou vos propres API, dans la nouvelle instance, généralement avec une nouvelle autorisation OAuth. L'import lui-même est simple : vous créez un nouveau workflow dans l'instance auto-hébergée, ouvrez le menu à trois points en haut à droite, sélectionnez Import from file et téléchargez le fichier précédemment téléchargé. Prévoyez fermement de recréer les identifiants, car sans identifiants valides, les workflows importés ne peuvent pas être exécutés.

Pourquoi les URL de webhook changent-elles lors du déménagement ?

L'adresse du webhook change parce que n8n la compose à partir de votre propre domaine, ou des variables d'environnement pour le protocole, l'hôte et le port, dès que l'instance ne fonctionne plus sous le sous-domaine cloud mais sur votre propre serveur. Si n8n fonctionne derrière un reverse proxy, la documentation n8n sur la configuration des URL de webhook recommande en outre de définir fermement la variable d'environnement WEBHOOK_URL, afin que n8n affiche l'adresse externe correcte dans l'interface et l'enregistre auprès des services externes. Après le déménagement, vous devez donc basculer manuellement chaque connexion externe, par exemple vers des prestataires de paiement, des outils de formulaire ou d'autres systèmes qui pointaient auparavant vers l'URL de webhook du cloud, vers la nouvelle adresse.

Que devez-vous vérifier avant le déménagement ?

Avant le changement proprement dit, il vaut la peine de faire un état des lieux afin que le fonctionnement reste stable après le déménagement. Cela comprend une liste complète de tous les workflows actifs ainsi que des services externes qui envoient des webhooks à n8n, un aperçu de tous les identifiants nécessaires ainsi qu'un plan de sauvegarde et de mise à jour de la nouvelle infrastructure, car ces tâches ne sont plus assurées par le fournisseur en auto-hébergement, mais par vous-même. Quiconque ne souhaite pas effectuer ce déménagement seul, ou souhaite faire assurer une automatisation n8n existante de manière techniquement propre et dans le respect de la souveraineté des données allemande, trouvera auprès du conseil n8n de NordFlux un accompagnement pour le déménagement et l'exploitation continue.

Questions fréquentes sur le passage de n8n Cloud à l'auto-hébergement

Puis-je exporter les identifiants depuis n8n Cloud ?

Non, selon la documentation officielle de n8n, les identifiants ne peuvent pas être exportés depuis n8n Cloud pour des raisons de sécurité. Ils doivent être recréés manuellement dans l'instance auto-hébergée après l'import des workflows, y compris une nouvelle autorisation OAuth pour des services comme Google ou Microsoft.

Combien de temps dure la migration de n8n Cloud vers l'auto-hébergement ?

La documentation officielle de n8n ne donne pas de durée générale. L'effort dépend surtout du nombre de workflows et d'identifiants, car chaque connexion d'identifiants doit être recréée individuellement et chaque webhook doit être mis à jour individuellement auprès des services externes. Prévoyez également du temps pour tester les workflows restaurés avant de désactiver définitivement l'instance cloud.

Le changement d'URL de webhook s'applique-t-il aussi aux webhooks de test ?

Oui, n8n distingue une URL de test, utilisée lors de l'exécution d'un workflow inactif, et une URL de production, qui n'est enregistrée qu'à l'activation d'un workflow. Après le déménagement vers l'auto-hébergement, l'adresse de base change pour les deux types d'URL, c'est pourquoi les webhooks de test que vous utilisez pendant le développement doivent également être reconfigurés.

Dois-je m'occuper moi-même des sauvegardes et des mises à jour en auto-hébergement ?

Oui, contrairement à n8n Cloud, avec l'auto-hébergement, vous prenez vous-même en charge l'exploitation du serveur, les sauvegardes et les mises à jour. La documentation n8n décrit à cet effet différentes méthodes d'installation, comme npm, Docker ou des déploiements chez des fournisseurs cloud, mais ne propose pas d'exploitation gérée comme pour la version cloud. Clarifiez donc avant le déménagement qui se charge de la surveillance, des sauvegardes et des mises à jour régulières de l'instance.