Sauvegarder ses workflows n8n sur GitHub ou GitLab : automatisation et restauration

Un workflow n8n represente des heures de configuration : logique metier, connexions API, conditions, tests. Sans sauvegarde, une erreur de manipulation, un crash serveur ou une mise à jour qui casse un workflow peut entrainer une perte seche. n8n ne propose pas de versionning natif intégré - c’est a l’utilisateur de mettre en place sa strategie de backup. Cet article detaille deux méthodes concretes pour automatiser la sauvegarde de vos workflows sur GitHub ou GitLab, avec restauration.

Mis à jour : mars 2026.

Pourquoi sauvegarder ses workflows n8n

n8n stocke les workflows dans sa base de données interne (SQLite par defaut, PostgreSQL en production). Si cette base est corrompue, si le serveur est reinstalle, ou si un utilisateur supprime un workflow par erreur, il n’existe pas de corbeille ni d’historique de versions dans l’interface standard. Voir aussi déployer un serveur MCP avec n8n pour un autre cas de déploiement en production.

Les situations de perte les plus frequentes :

• Erreur humaine : suppression accidentelle d’un workflow ou d’un nœud, sauvegarde d’une version cassee par-dessus la version fonctionnelle
• Mise à jour n8n : une montee de version peut modifier le comportement d’un nœud ou rendre un workflow incompatible
• Crash serveur : perte du volume Docker, corruption de la base de données
• Absence de rollback : n8n ne permet pas nativement de revenir à une version anterieure d’un workflow

Retour d’experience : en debut d’activite avec n8n, la perte d’un ensemble de workflows sans sauvegarde a nécessite deux semaines de reconstruction à partir de la mémoire seule. Depuis, chaque instance client dispose d’un backup automatise des le premier jour de déploiement.

GitHub ou GitLab : quel depot choisir

Les deux plateformes fonctionnent de la même maniere pour le stockage de workflows JSON. Le choix depend du contexte client.

Critere	GitHub	GitLab
Hebergement	Cloud (github.com) ou GitHub Enterprise	Cloud (gitlab.com) ou self-hosted
Souverainete des données	Serveurs aux Etats-Unis	Self-hosted possible sur infrastructure europeenne
Depots prives gratuits	Oui (illimites)	Oui (illimites)
API pour push de fichiers	PUT /repos/{owner}/{repo}/contents/{path}	POST /api/v4/projects/{id}/repository/files/{path}
Authentification API	Token personnel (PAT)	Token personnel ou token de projet

En pratique : GitHub pour les clients qui n’ont pas d’infrastructure propre et veulent une solution rapide. GitLab self-hosted pour les clients soumis a des contraintes de souverainete ou qui disposent deja d’un serveur dedie. Les deux sont compatibles avec la méthode de sauvegarde decrite ci-dessous.

Méthode 1 : sauvegarde automatisee via un workflow n8n

La méthode la plus fiable consiste a créer un workflow n8n dedie qui exporte tous les autres workflows et les pousse vers le depot Git. Ce workflow de backup utilise l’API REST de n8n pour récupérer les données (docs.n8n.io/api).

Architecture du workflow

1. Cron Trigger : déclenchement quotidien (ex: tous les jours a 2h du matin)
2. HTTP Request : appel GET vers l’API n8n pour récupérer tous les workflows
3. SplitInBatches : traitement de chaque workflow individuellement (main[0] = Done, main[1] = Loop)
4. Code : formatage du JSON et génération du nom de fichier
5. HTTP Request : push du fichier vers l’API GitHub ou GitLab
6. Notification (optionnel) : envoi d’un message Discord ou email en cas d’erreur

Configuration de l’appel API n8n

L’API REST de n8n expose les endpoints suivants pour les workflows :

• GET /api/v1/workflows : retourne la liste de tous les workflows au format JSON
• GET /api/v1/workflows/{id} : retourne un workflow spécifique avec tous ses nœuds et connexions
• POST /api/v1/workflows : créé (importe) un workflow

L’authentification se fait via le header X-N8N-API-KEY avec une clé API générée dans les parametres de n8n (Settings > API > Create API Key). Source : docs.n8n.io/api.

Push vers GitHub (API REST)

Pour chaque workflow, le nœud HTTP Request envoie le fichier JSON vers GitHub :

• Méthode : PUT
• URL : https://api.github.com/repos/{owner}/{repo}/contents/workflows/{nom-du-workflow}.json
• Header : Authorization: Bearer {GITHUB_TOKEN}
• Body : {"message": "backup {date}", "content": "{base64 du JSON}", "sha": "{sha du fichier existant si mise à jour}"}

Le champ sha est obligatoire pour mettre à jour un fichier existant. Il faut donc faire un GET au prealable pour récupérer le sha actuel du fichier. Sans ce sha, GitHub refuse la mise à jour.

Push vers GitLab (API REST)

La même logique s’applique pour GitLab, avec un endpoint different :

• Méthode : PUT (mise à jour) ou POST (création)
• URL : https://gitlab.example.com/api/v4/projects/{project_id}/repository/files/workflows%2F{nom}.json
• Header : PRIVATE-TOKEN: {GITLAB_TOKEN}
• Body : {"branch": "main", "commit_message": "backup {date}", "content": "{JSON brut}"}

À la difference de GitHub, GitLab accepte le contenu en texte brut (pas de base64 nécessaire) et ne requiert pas de sha pour les mises à jour. Source : docs.gitlab.com/api/repository_files.

Méthode 2 : sauvegarde à chaque modification (temps réel)

En complement du backup quotidien, une sécurité supplementaire consiste a sauvegarder un workflow à chaque fois qu’il est modifie et active. n8n expose un webhook interne ou un Trigger sur les événements d’instance. L’approche la plus simple : utiliser le nœud n8n Trigger configure sur l’événement “Workflow activated” ou “Workflow updated”.

À chaque publication ou activation d’un workflow, le workflow de backup se déclenché, récupéré le workflow modifie via l’API, et le pousse vers le depot Git. Cette approche garantit qu’aucune modification n’est perdue entre deux backups planifies. Pour securiser davantage vos workflows critiques, consultez notre guide sur la validation humaine dans n8n.

Structure recommandee du depot Git

Un fichier JSON par workflow, nomme de maniere lisible. Convention de nommage recommandee :

n8n-backups/
  workflows/
    001-backup-workflows-github.json
    002-envoi-factures-automatique.json
    003-synchronisation-crm-email.json
    ...
  README.md

Chaque fichier JSON contient la définition complete du workflow : nœuds, connexions, parametres, position des nœuds dans le canvas. Un workflow pese typiquement entre 5 KB et 200 KB selon sa complexite (nombre de nœuds et volume de données statiques configurees).

Le README documente la liste des workflows, leur fonction et leur statut (actif/inactif). Ce fichier facilite la restauration en identifiant rapidement quel workflow restaurer en cas de besoin.

Restaurer un workflow depuis une sauvegarde

Via l’interface n8n

La méthode la plus directe : dans n8n, cliquer sur le menu principal > Import from file > selectionner le fichier JSON. Le workflow est recree avec tous ses nœuds et connexions. Les credentials devront être re-associes manuellement (voir section suivante).

Via l’API n8n

Pour une restauration programmatique ou massive :

• Méthode : POST
• URL : /api/v1/workflows
• Header : X-N8N-API-KEY: {cle}
• Body : le contenu JSON du workflow

Pour restaurer une version anterieure spécifique, l’historique Git est le levier principal : git log --oneline workflows/mon-workflow.json pour voir les versions, puis git show {commit}:workflows/mon-workflow.json pour récupérer le contenu à une date donnée.

Gestion des credentials lors de la restauration

Point critique : les credentials (clés API, tokens OAuth, mots de passe) ne sont jamais inclus dans l’export JSON des workflows. C’est un choix de sécurité de n8n - le fichier JSON contient uniquement l’identifiant de la credential, pas sa valeur. Source : docs.n8n.io.

En pratique, deux approches pour gerer la restauration des credentials :

• Coffre-fort de credentials : stocker les credentials dans un gestionnaire securise (Bitwarden, 1Password, vault self-hosted) pour pouvoir les re-saisir sans dependre du client. Cela evite de perturber l’activite du client pour un simple re-déploiement
• Validation client obligatoire : certaines credentials necessitent une double authentification (OAuth2, services bancaires, outils securises). Dans ce cas, le client doit intervenir pour valider la connexion. Planifier cette étape en amont pour minimiser l’interruption

Contexte Docker et Coolify

Les instances n8n deployees via Coolify tournent dans des conteneurs Docker. Deux points spécifiques a ce contexte :

• Volumes Docker : la base de données n8n est stockee dans un volume Docker. Si le conteneur est recree sans que le volume soit preserve, toutes les données sont perdues. Le backup Git est independant du volume - c’est sa valeur principale
• Acces a l’API depuis le workflow de backup : le workflow de backup s’exécuté dans la même instance n8n. L’URL de l’API est donc l’URL interne ou publique de l’instance (ex: https://n8n.client.fr/api/v1/workflows)

L’export via l’API n8n depuis le workflow de backup est preferable à la commande CLI n8n export:workflow car elle ne nécessite pas d’acces docker exec au conteneur et fonctionne de la même maniere quelle que soit l’infrastructure d’hebergement.

FAQ

A quelle frequence sauvegarder ses workflows ?

Un backup quotidien planifie (Cron Trigger a heure fixe) couvre la majorite des cas. Pour les instances avec des modifications frequentes, ajouter un backup à chaque publication de workflow en complement. Les deux approches se combinent : le backup quotidien sert de filet de sécurité, le backup à la publication capture chaque changement en temps réel.

L’export JSON inclut-il les credentials ?

Non. L’export contient l’identifiant de la credential (ex: "credentials": {"myApi": {"id": "12", "name": "Mon API"}}) mais pas la valeur secrete. C’est un comportement voulu par n8n pour eviter la fuite de données sensibles. Les credentials doivent être gerees separement via un coffre-fort securise.

Comment restaurer un workflow à une version anterieure ?

L’historique Git conserve chaque version du fichier JSON. Utiliser git log --oneline workflows/nom.json pour lister les commits, puis git show {hash}:workflows/nom.json > restore.json pour extraire la version souhaitee. Importer ensuite ce fichier dans n8n via l’interface ou l’API POST /api/v1/workflows.

Peut-on sauvegarder vers GitHub et GitLab en même temps ?

Oui. Dans le workflow de backup, dupliquer la branche de push avec un nœud pour chaque destination. En pratique, une seule destination suffit pour la plupart des cas. La double sauvegarde se justifie quand le client exige une redondance geographique ou une separation entre depot operationnel et depot d’archivage.

Que se passe-t-il si le workflow de backup lui-même est perdu ?

Le workflow de backup doit être le premier sauvegarde manuellement. Exporter son JSON et le stocker dans le depot Git avant d’activer l’automatisation. Ainsi, même en cas de perte totale de l’instance, le workflow de backup peut être restaure en premier, puis utilise pour reimporter tous les autres.

Fiche technique

Élément	Detail
API n8n	GET/POST /api/v1/workflows - auth par X-N8N-API-KEY (docs.n8n.io/api)
API GitHub	PUT /repos/{owner}/{repo}/contents/{path} - auth par Bearer token
API GitLab	PUT /api/v4/projects/{id}/repository/files/{path} - auth par PRIVATE-TOKEN
Format d’export	JSON (5-200 KB par workflow)
Credentials dans l’export	Non incluses (identifiant uniquement, pas la valeur secrete)
Declencheurs recommandes	Cron Trigger (quotidien) + n8n Trigger (a chaque publication)
Infrastructure	Compatible Docker, Coolify, instances self-hosted et cloud