Sauvegarde n8n : workflows, identifiants et clé de chiffrement

Une sauvegarde n8n n'est complète que lorsqu'elle sécurise ensemble les workflows, les identifiants et la clé de chiffrement correspondante. Si la clé manque ou diffère de l'original, n8n ne peut plus déchiffrer les identifiants enregistrés, et chaque connexion enregistrée vers une boîte e-mail, un CRM ou une API doit être reconfigurée manuellement. Les workflows eux-mêmes peuvent être exportés et importés au format JSON via l'interface web ou la CLI ; les identifiants nécessitent en plus la clé de chiffrement d'origine ou un export déchiffré délibérément. Pour les entreprises qui hébergent elles-mêmes n8n et assument la responsabilité de leurs automatisations, la clé de chiffrement est donc l'élément le plus important d'une stratégie de sauvegarde fonctionnelle. Situation au : juillet 2026.

Que fait réellement la clé de chiffrement dans n8n ?

La clé de chiffrement chiffre tous les identifiants enregistrés dans n8n avant leur stockage dans la base de données ; sans la clé correspondante, ces données restent définitivement illisibles. Au premier démarrage, n8n génère automatiquement une clé aléatoire et la stocke dans le dossier ~/.n8n. Quiconque souhaite utiliser sa propre clé doit définir la variable d'environnement N8N_ENCRYPTION_KEY avant la création du fichier de configuration ; un changement ultérieur n'est pas repris automatiquement. Si n8n fonctionne en mode file d'attente avec plusieurs workers, la documentation indique que la même clé de chiffrement doit être définie pour chaque worker (documentation n8n sur la clé de chiffrement).

Que se passe-t-il si la clé de chiffrement est perdue ?

Si la clé de chiffrement est perdue ou diffère de celle utilisée à l'origine pour chiffrer les identifiants, n8n signale que les identifiants n'ont pas pu être déchiffrés, probablement parce qu'une autre clé de chiffrement a été utilisée. La logique du workflow elle-même reste intacte sous forme de structure JSON, mais chaque identifiant enregistré, comme les clés API, les jetons OAuth ou les accès SMTP, devient inutilisable et doit être reconnecté manuellement. Avec quelques workflows, c'est gênant ; avec des automatisations développées comportant de nombreuses connexions à la comptabilité, au CRM ou à la gestion des stocks, cela signifie en pratique un redémarrage complet de toute la gestion des identifiants. La clé de chiffrement doit donc faire partie de chaque routine de sauvegarde, séparément de la sauvegarde de la base de données, mais tout aussi fiable qu'elle.

Comment sauvegarder correctement workflows et identifiants ?

Pour les sauvegardes, n8n propose des méthodes à la fois via l'interface et via la CLI du serveur ; pour des sauvegardes régulières, la CLI est la méthode la plus fiable. Dans l'interface web, un workflow peut être téléchargé au format JSON via le menu à trois points, ou importé depuis un fichier ou une URL.

• Exporter les workflows : n8n export:workflow avec les options --backup et --output sauvegarde tous les workflows individuellement, dans un format lisible, dans un dossier cible.
• Exporter les identifiants : n8n export:credentials --all sauvegarde les identifiants chiffrés ; avec l'option supplémentaire --decrypted, ils peuvent aussi être exportés en clair, par exemple pour les transférer spécifiquement vers une instance avec une clé de chiffrement différente.
• Import : n8n import:workflow et n8n import:credentials réintègrent les fichiers JSON ; les identifiants (ID) qu'ils contiennent écrasent les workflows ou identifiants existants portant le même ID.

Les détails de toutes les commandes se trouvent dans la documentation n8n sur l'export et l'import ainsi que sur la ligne de commande (Export et import dans n8n, Commandes CLI n8n).

À quoi devez-vous faire attention lors du changement de la clé de chiffrement ou du partage d'exports ?

Changer la clé de chiffrement n'est pas une opération de routine, mais une intervention qui peut entraîner une perte de données définitive sans sauvegarde préalable. n8n distingue la clé de chiffrement de l'instance, qui en tant que clé maîtresse ne change jamais, et une clé de chiffrement des données sous-jacente, qui chiffre réellement les identifiants et peut être renouvelée via sa propre fonction de rotation. Selon la documentation, cette rotation n'est explicitement pas réversible ; si la fonction associée est de nouveau désactivée, toutes les données chiffrées depuis lors deviennent définitivement inaccessibles, une sauvegarde complète préalable de la base de données étant la seule protection (documentation n8n sur la rotation des clés). Il convient également d'être prudent lors du partage de fichiers JSON de workflows exportés, car les fichiers contiennent des noms d'identifiants et des ID, et les nœuds de requête HTTP importés depuis cURL peuvent même contenir des en-têtes d'authentification en clair. Ces informations doivent être supprimées avant toute transmission.

Quiconque exploite sa propre instance n8n et recherche un accompagnement pour la mise en place de routines de sauvegarde ou le déménagement entre serveurs trouvera un soutien dans l'offre n8n de NordFlux.

Questions fréquentes sur la sauvegarde n8n et la clé de chiffrement

Une sauvegarde de la base de données suffit-elle à elle seule pour sauvegarder complètement n8n ?

Non, une simple sauvegarde de la base de données sécurise certes les workflows et les identifiants chiffrés, mais sans la clé de chiffrement associée, ces identifiants restent illisibles lors de la restauration. Par défaut, la clé se trouve dans un fichier de configuration séparé, dans le dossier ~/.n8n, et doit donc être sauvegardée délibérément, idéalement séparément de la sauvegarde de la base de données, dans un emplacement protégé contre les accès.

Puis-je exporter des workflows sans les identifiants associés ?

Oui, l'export d'un workflow via l'interface ou avec n8n export:workflow ne contient que la structure du workflow avec des références aux noms d'identifiants et aux ID, et non les identifiants eux-mêmes. Pour emporter également les identifiants, un export séparé avec n8n export:credentials est nécessaire, et la destination doit soit disposer de la même clé de chiffrement, soit les identifiants doivent d'abord être exportés en clair avec l'option --decrypted.

Comment migrer des identifiants vers une instance n8n avec une clé de chiffrement différente ?

La méthode la plus fiable est l'export déchiffré avec n8n export:credentials --all --decrypted sur l'instance source, suivi de l'import habituel sur l'instance de destination, qui rechiffre automatiquement les données avec sa propre clé de chiffrement. Comme le fichier est brièvement en clair pendant cette opération, il doit être supprimé de manière sécurisée immédiatement après l'import.

Que faire si la clé de chiffrement a réellement été perdue ?

Sans la clé d'origine ni sauvegarde du fichier de configuration, les identifiants déjà chiffrés ne peuvent plus être récupérés ; chaque connexion concernée doit être réauthentifiée manuellement dans les workflows respectifs. La logique du workflow elle-même n'est pas perdue dans ce cas ; l'effort se limite à ressaisir les identifiants, ce qui peut néanmoins représenter plusieurs heures de travail pour des automatisations étendues.