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 a jour qui casse un workflow peut entrainer une perte seche. n8n ne propose pas de versionning natif integre - c’est a l’utilisateur de mettre en place sa strategie de backup. Cet article detaille deux methodes concretes pour automatiser la sauvegarde de vos workflows sur GitHub ou GitLab, avec restauration.

Mis a jour : mars 2026.

Pourquoi sauvegarder ses workflows n8n

n8n stocke les workflows dans sa base de donnees 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 deployer un serveur MCP avec n8n pour un autre cas de deploiement en production.

Les situations de perte les plus frequentes :

• Erreur humaine : suppression accidentelle d’un workflow ou d’un noeud, sauvegarde d’une version cassee par-dessus la version fonctionnelle
• Mise a jour n8n : une montee de version peut modifier le comportement d’un noeud ou rendre un workflow incompatible
• Crash serveur : perte du volume Docker, corruption de la base de donnees
• Absence de rollback : n8n ne permet pas nativement de revenir a 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 necessite deux semaines de reconstruction a partir de la memoire seule. Depuis, chaque instance client dispose d’un backup automatise des le premier jour de deploiement.

GitHub ou GitLab : quel depot choisir

Les deux plateformes fonctionnent de la meme 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 donnees	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 methode de sauvegarde decrite ci-dessous.

Methode 1 : sauvegarde automatisee via un workflow n8n

La methode la plus fiable consiste a creer 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 recuperer les donnees (docs.n8n.io/api).

Architecture du workflow

1. Cron Trigger : declenchement quotidien (ex: tous les jours a 2h du matin)
2. HTTP Request : appel GET vers l’API n8n pour recuperer tous les workflows
3. SplitInBatches : traitement de chaque workflow individuellement (main[0] = Done, main[1] = Loop)
4. Code : formatage du JSON et generation 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 specifique avec tous ses noeuds et connexions
• POST /api/v1/workflows : cree (importe) un workflow

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

Push vers GitHub (API REST)

Pour chaque workflow, le noeud HTTP Request envoie le fichier JSON vers GitHub :

• Methode : 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 a jour}"}

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

Push vers GitLab (API REST)

La meme logique s’applique pour GitLab, avec un endpoint different :

• Methode : PUT (mise a jour) ou POST (creation)
• 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}"}

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

Methode 2 : sauvegarde a chaque modification (temps reel)

En complement du backup quotidien, une securite supplementaire consiste a sauvegarder un workflow a chaque fois qu’il est modifie et active. n8n expose un webhook interne ou un Trigger sur les evenements d’instance. L’approche la plus simple : utiliser le noeud n8n Trigger configure sur l’evenement “Workflow activated” ou “Workflow updated”.

A chaque publication ou activation d’un workflow, le workflow de backup se declenche, recupere 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 definition complete du workflow : noeuds, connexions, parametres, position des noeuds dans le canvas. Un workflow pese typiquement entre 5 KB et 200 KB selon sa complexite (nombre de noeuds et volume de donnees 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 methode la plus directe : dans n8n, cliquer sur le menu principal > Import from file > selectionner le fichier JSON. Le workflow est recree avec tous ses noeuds et connexions. Les credentials devront etre re-associes manuellement (voir section suivante).

Via l’API n8n

Pour une restauration programmatique ou massive :

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

Pour restaurer une version anterieure specifique, 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 recuperer le contenu a une date donnee.

Gestion des credentials lors de la restauration

Point critique : les credentials (cles API, tokens OAuth, mots de passe) ne sont jamais inclus dans l’export JSON des workflows. C’est un choix de securite 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-deploiement
• 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 etape en amont pour minimiser l’interruption

Contexte Docker et Coolify

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

• Volumes Docker : la base de donnees n8n est stockee dans un volume Docker. Si le conteneur est recree sans que le volume soit preserve, toutes les donnees 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’execute dans la meme 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 a la commande CLI n8n export:workflow car elle ne necessite pas d’acces docker exec au conteneur et fonctionne de la meme 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 a chaque publication de workflow en complement. Les deux approches se combinent : le backup quotidien sert de filet de securite, le backup a la publication capture chaque changement en temps reel.

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 donnees sensibles. Les credentials doivent etre gerees separement via un coffre-fort securise.

Comment restaurer un workflow a 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 meme temps ?

Oui. Dans le workflow de backup, dupliquer la branche de push avec un noeud 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-meme est perdu ?

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

Fiche technique

Element	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