Versionnement de workflows : Change History, export JSON, solution de contournement de sauvegarde Git pour la Community Edition

Quiconque construit des workflows dans n8n les modifie sans cesse : un node est ajouté, un filtre est ajusté, une gestion d'erreur est ajoutée après coup. Sans versionnement, chacune de ces modifications est un écrasement silencieux, et la question "Quelle version tournait encore de façon stable hier ?" ne peut plus recevoir de réponse. n8n propose pour cela un Change History intégré, mais l'historique complet et la synchronisation Git native via Source Control sont réservés aux plans Business et Enterprise, pas à la Community Edition gratuite.

Pour tous les autres, l'export JSON manuel reste la solution de contournement : les workflows peuvent être téléchargés à tout moment sous forme de fichier JSON et intégrés dans son propre dépôt Git. Cet article montre ce que le Change History intégré permet réellement, où se situent ses limites, et comment construire soi-même, avec les moyens du bord, un système de sauvegarde et de versionnement fonctionnel, même sans licence Enterprise.

Que montre le Change History de workflow intégré ?

Chaque workflow dans n8n possède sa propre icône d'historique, à travers laquelle tu ouvres un menu avec toutes les versions enregistrées, chacune accompagnée d'un aperçu du canvas de la version sélectionnée. Selonla documentation n8n sur le Change History n8n crée automatiquement une nouvelle version quand tu enregistres le workflow, restaures une ancienne version (la version active précédente est alors d'abord sauvegardée) ou effectues un pull depuis un dépôt Git via Source Control.

Plusieurs actions sont disponibles pour chaque version enregistrée :

• Restaurer la version : remplace le workflow actuel par la version sélectionnée.
• Cloner dans un nouveau workflow : crée une copie de la version comme workflow autonome.
• Ouvrir la version dans un nouvel onglet : permet une comparaison directe de deux versions côte à côte.
• Télécharger : exporte la version sélectionnée sous forme de fichier JSON.
• Nommer la version : la protège du nettoyage automatique, cette fonctionnalité est réservée aux utilisateurs Pro et Enterprise.

La portée de cet historique compte en pratique. Elle diffère nettement selon le plan :

• Enterprise (Cloud ou Self-hosted) : historique complet des workflows sans limite de temps.
• Cloud Pro : versions des cinq derniers jours.
• Tous les autres utilisateurs, y compris la Community Edition : seulement les versions des dernières 24 heures.

Concrètement, cela signifie que quiconque utilise la Community Edition ou un plan Cloud simple perd l'accès aux anciens états intermédiaires au plus tard après un jour. Pour un historique de versions réellement durable, la fonctionnalité intégrée ne suffit pas dans ces cas.

Pourquoi Source Control via Git n'est-il pas disponible pour tout le monde ?

Avec Source Control, n8n propose une intégration Git native permettant de synchroniser automatiquement les workflows avec un dépôt, y compris plusieurs environnements via des branches Git séparées. Selonla documentation n8n sur Source Control et les environnements cette fonctionnalité est cependant "Available on Business and Enterprise plans", donc elle ne fait pas partie de la Community Edition gratuite, ni des offres Cloud simples.

Là où Source Control est disponible, la configuration se fait via Settings > Environments. Tu y renseignes l'URL du dépôt Git, soit par SSH avec une Deploy Key, soit par HTTPS avec un Personal Access Token, et n8n génère automatiquement une clé SSH pour cela (ED25519 par défaut). Les propriétaires d'instance et les administrateurs d'instance peuvent ensuite aussi bien pousser que tirer, les administrateurs de projet peuvent seulement pousser. Quiconque travaille de manière productive avec plusieurs environnements et possède la licence Business ou Enterprise devrait utiliser cette voie native, elle t'évite l'entretien manuel de l'export.

La solution de contournement : sauvegarde Git manuelle via export JSON

Sans licence Business ou Enterprise, l'export JSON reste le moyen le plus fiable de sécuriser les workflows durablement et de façon versionnée. Selonla documentation n8n sur l'export et l'import n8n stocke fondamentalement les workflows au format JSON, et c'est précisément ce format qui peut être exporté, intégré dans un dépôt Git, puis commité, tagué et annulé comme toute autre modification de code.

Export via l'interface

Pour des workflows individuels, l'interface de l'éditeur suffit amplement :

• Ouvre le workflow et clique sur le menu à trois points en haut à droite.
• ChoisisDownload pour télécharger le workflow actuel sous forme de fichier JSON sur ton ordinateur.
• Tu peux aussi sélectionner des nodes individuels, les copier avec Ctrl+C ou Cmd+C et les coller dans un éditeur de texte, ce qui donne également un JSON de workflow valide pour des sections partielles.
• ViaImport from File ouImport from URL un fichier JSON peut être rechargé plus tard dans n8n.

La documentation indique explicitement que les fichiers JSON exportés contiennent des noms d'identifiants et des ID d'identifiants. Avant de partager un tel fichier ou de le placer dans un dépôt partagé, tu devrais supprimer ou anonymiser ces informations afin qu'aucune donnée d'accès sensible ne se retrouve accidentellement dans l'historique des versions.

Export via la ligne de commande pour des instances entières

Pour une sauvegarde complète de tous les workflows d'une instance n8n auto-hébergée, la CLI convient mieux que le téléchargement manuel individuel. Selonla documentation n8n sur la ligne de commande des commandes d'export et d'import dédiées sont disponibles pour cela :

• `n8n export:workflow --all --output=backups/latest/` exporte tous les workflows dans un répertoire.
• `n8n export:workflow --backup --output=backups/latest/` utilise le mode de sauvegarde dédié, qui définit en interne `--all --pretty --separate` : tous les workflows, formatés de façon lisible, chacun comme fichier séparé.
• `n8n export:workflow --id=<ID> --output=file.json` exporte spécifiquement un seul workflow.
• `n8n import:workflow --separate --input=backups/latest/` importe de nouveau un répertoire complet contenant des fichiers JSON individuels.
• `n8n import:workflow --separate --input=backups/latest/ --activeState=fromJson` reprend aussi lors de l'import le statut d'activation d'origine de chaque workflow.

Comment construire à partir de cela une sauvegarde Git

Combine le mode de sauvegarde de la CLI avec un cron job régulier et un dépôt Git, tu obtiens alors un versionnement fait maison mais solide :

1. Crée un dépôt Git privé, séparé du reste de ton code applicatif.

2. Mets en place sur le serveur n8n un cron job quotidien qui exécute `n8n export:workflow --backup --output=backups/latest/`.

3. Commite les fichiers exportés dans le dépôt, de façon automatisée ou manuelle, avec un message de commit explicite.

4. Avant chaque commit, vérifie qu'aucune référence d'identifiant non nettoyée n'est incluse, idéalement via un script simple qui filtre ou marque des motifs connus comme `credentialId`.

5. Utilise `git tag` si besoin pour marquer clairement les états de production stables, afin de pouvoir les retrouver aussi des mois plus tard.

Tu obtiens ainsi, au fond, ce que Source Control offre nativement, simplement sans mécanisme automatique de push-pull et avec un peu plus de travail manuel lors de la restauration. Pour les petites équipes et les freelances individuels, c'est souvent un compromis acceptable avant qu'une licence Business ne soit rentable.

Combien de temps n8n conserve-t-il automatiquement les versions ?

Quiconque utilise l'historique de workflow intégré et souhaite contrôler lui-même la durée de conservation trouvera le bon réglage dans la configuration du serveur. Selonla documentation n8n sur les variables d'environnement du workflow history la variable `N8N_WORKFLOW_HISTORY_PRUNE_TIME` détermine combien d'heures les anciennes versions sont conservées avant que n8n ne les supprime automatiquement. La valeur par défaut est `-1`, ce qui signifie que techniquement toutes les versions sont conservées indéfiniment, bien que les limites dépendantes du plan de la section précédente s'appliquent encore à la visibilité.

Pour les instances auto-hébergées sans licence Enterprise, il vaut quand même la peine de définir cette variable en connaissance de cause et d'établir en plus la solution de contournement par export JSON. Ainsi tu gardes le contrôle sur ton historique de versions, indépendamment de ce que l'interface affiche ou masque actuellement.

Questions fréquentes

Ai-je absolument besoin d'une licence Enterprise pour le versionnement de workflows ?

Non. Le Change History intégré avec l'historique complet et la synchronisation Git native via Source Control sont certes réservés aux plans Business et Enterprise, mais l'export JSON manuel fonctionne dans chaque version de n8n, y compris dans la Community Edition gratuite. Combiné avec ton propre dépôt Git et un export CLI régulier, tu obtiens un versionnement à part entière, même s'il est manuel.

Combien de temps n8n stocke-t-il les versions de workflow sans plan Business ou Enterprise ?

Dans la Community Edition et dans les plans simples, seules les versions des dernières 24 heures sont consultables via l'interface, même si la variable d'environnement `N8N_WORKFLOW_HISTORY_PRUNE_TIME` est réglée sur une conservation illimitée. Pour tout ce qui doit remonter plus loin, tu as besoin soit d'un plan supérieur, soit de ton propre système de sauvegarde via export JSON.

Les fichiers JSON exportés contiennent-ils mes données d'accès ?

Selon la documentation n8n, les fichiers JSON de workflow exportés contiennent des noms d'identifiants et des ID d'identifiants, mais pas de mots de passe ni de tokens en clair. Néanmoins, tu devrais supprimer ou anonymiser ces références avant de les partager ou de les intégrer dans un dépôt partagé, afin que personne ne puisse tirer de conclusions sur la structure de tes identifiants à partir des ID.

Puis-je sauvegarder des nodes individuels au lieu du workflow entier ?

Oui. Si tu sélectionnes des nodes individuels dans le canvas et les copies avec Ctrl+C ou Cmd+C, tu obtiens également un JSON de workflow valide qui peut être enregistré dans un éditeur de texte et collé de nouveau plus tard. Cela convient bien pour versionner séparément des blocs réutilisables comme une gestion d'erreur ou une configuration HTTP standard.

Quelle est la différence entre l'option de sauvegarde CLI et un simple export de tous les workflows ?

La commande `n8n export:workflow --backup` définit automatiquement les flags `--all --pretty --separate`, exportant ainsi tous les workflows de l'instance, formatant le JSON de façon lisible et créant un fichier séparé pour chaque workflow. Un export simple avec `--all` sans ces flags peut en revanche écrire tous les workflows dans un seul fichier ou sans formatage, ce qui rend les comparaisons de diff ultérieures dans Git nettement moins claires. Pour une sauvegarde Git propre, le mode de sauvegarde est donc le meilleur choix.