Le Change History des workflows n'affiche que 24 heures sans plan Enterprise. Voici comment sécuriser toi-même tes workflows n8n durablement via l'export JSON et Git.
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.
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 :
La portée de cet historique compte en pratique. Elle diffère nettement selon le plan :
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.
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.
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.
Pour des workflows individuels, l'interface de l'éditeur suffit amplement :
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.
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.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.
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.
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.
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.
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.
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.
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.
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
n8n Community Edition : ces fonctionnalités manquent vraiment, et ces trois fonctionnalités sont débloquées par la clé de licence gratuite.
Comment exporter et importer des workflows n8n via la CLI, et réinitialiser le mot de passe d'un utilisateur en ligne de commande en cas de verrouillage.
L'édition Community est gratuite et illimitée, Business coûte 667 EUR par mois. Ce qui différencie vraiment les plans et quand une PME a besoin d'Enterprise.
Sans plan Enterprise, la Change History de n8n ne remonte qu'à un jour en arrière, un workflow supprimé ou cassé ne peut donc plus être restauré au-delà. NordFlux met en place une sauvegarde Git fiable avec export JSON pour votre installation et en assure la maintenance continue. Lors d'un premier échange, nous vérifions comment vos workflows sont sauvegardés aujourd'hui.