Migrer n8n d'un serveur à l'autre

Ce guide suit la page des commandes en ligne de commande de n8n et la page sur la clé de chiffrement, relues le 15 octobre 2026 ; dernière version publiée à cette date : n8n 2.43.5. Il suppose une installation par Docker Compose comme celle de Installer n8n avec Docker Compose : dossier ~/n8n-compose, service n8n, volume n8n_data monté sur /home/node/.n8n, et les commandes lancées dans ~/n8n-compose.

Ce qu'il faut emporter

D'après la documentation, le dossier .n8n garde les données de l'utilisateur, dont le fichier de la base et la clé de chiffrement. n8n génère cette clé au premier lancement et s'en sert pour chiffrer les identifiants avant de les écrire en base. Trois choses comptent donc :

• les flux, avec leurs réglages ;
• les identifiants, chiffrés avec la clé de l'ancienne instance ;
• la clé de chiffrement elle-même, ou un export des identifiants en clair.

L'historique des exécutions n'est utile que si vous voulez le garder : il pèse souvent lourd.

Méthode 1 : copier le volume entier

C'est la méthode la plus complète : la nouvelle instance repart avec la même base, les mêmes identifiants et la même clé.

1. Sur l'ancien serveur, notez la version qui tourne : docker compose exec n8n n8n --version. C'est cette version que vous lancerez sur le nouveau serveur, en fixant la même étiquette d'image dans compose.yaml.
2. Arrêtez n8n pour figer la base : docker compose stop n8n
3. Copiez le dossier ~/n8n-compose, avec .env et compose.yaml, et le volume n8n_data. La marche à suivre pas à pas, montages et propriétaires compris, est dans Migrer ses applications Docker.
4. Sur le nouveau serveur, restaurez le dossier et le volume, puis lancez : docker compose up -d
5. Ouvrez n8n et vérifiez qu'un flux qui utilise des identifiants s'exécute sans erreur.

Si la base de n8n est PostgreSQL et non SQLite, sauvegardez aussi cette base avec ses outils, en plus du volume n8n_data qui garde la clé.

Méthode 2 : exporter et importer en ligne de commande

Cette méthode convient quand la nouvelle instance existe déjà ou qu'elle a sa propre configuration. La documentation indique de lancer les commandes dans le conteneur, avec l'utilisateur node.

Les exports s'écrivent dans le volume de n8n, où l'utilisateur node a le droit d'écrire, puis sortent du conteneur par docker compose cp, décrite dans la documentation de Docker.

Sur l'ancien serveur, dans ~/n8n-compose :

1. Exportez les flux, un fichier par flux : docker compose exec -u node n8n n8n export:workflow --backup --output=/home/node/.n8n/sauvegarde/flux/
2. Exportez les identifiants en clair : docker compose exec -u node n8n n8n export:credentials --all --decrypted --output=/home/node/.n8n/sauvegarde/identifiants.json
3. Sortez les fichiers du conteneur : docker compose cp n8n:/home/node/.n8n/sauvegarde ./sauvegarde
4. Copiez le dossier sauvegarde vers le dossier ~/n8n-compose du nouveau serveur, par exemple avec scp -r.

Sur le nouveau serveur, dans ~/n8n-compose :

5. Placez les fichiers dans le conteneur : docker compose cp ./sauvegarde n8n:/tmp/sauvegarde
6. Importez les identifiants : docker compose exec -u node n8n n8n import:credentials --input=/tmp/sauvegarde/identifiants.json
7. Importez les flux : docker compose exec -u node n8n n8n import:workflow --separate --input=/tmp/sauvegarde/flux/
8. Effacez les exports partout : rm -r ~/n8n-compose/sauvegarde sur les deux serveurs, docker compose exec -u root n8n rm -r /tmp/sauvegarde sur le nouveau, et docker compose exec -u root n8n rm -r /home/node/.n8n/sauvegarde sur l'ancien.

L'option --decrypted écrit les identifiants en clair, et la documentation prévient que toutes les informations sensibles sont alors visibles dans le fichier. Elle sert précisément à passer d'une instance à une autre qui n'a pas la même clé. Ne gardez ce fichier que le temps de la migration, et ne l'envoyez jamais par courriel ni dans un dépôt.

Sans --decrypted, les identifiants restent chiffrés : la nouvelle instance ne pourra les relire que si elle utilise la même clé, que la variable N8N_ENCRYPTION_KEY permet de fournir avant le premier lancement. Placez-la dans le fichier .env du nouveau serveur, jamais en clair dans compose.yaml, et transmettez-la au service n8n par une ligne N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY} dans sa partie environment.

La documentation signale aussi qu'un import écrase les éléments qui portent le même identifiant : importez de préférence dans une instance vide.

Changer de type de base au passage

Pour passer de SQLite à PostgreSQL en même temps, n8n propose export:entities et import:entities, qui copient toutes les entités d'une base à l'autre. La documentation précise que la base d'arrivée doit être vide, et que l'historique des exécutions n'est exporté qu'avec l'option --includeExecutionHistoryDataTables=true.

Après la migration

1. L'adresse : si le nom de domaine change, mettez à jour SUBDOMAIN et DOMAIN_NAME dans le fichier .env, d'où sont tirés N8N_HOST et N8N_WEBHOOK_URL, puis relancez.
2. Le DNS : faites pointer le sous-domaine de n8n vers le nouveau serveur, en gardant l'ancien en marche le temps de la propagation.
3. Les flux : ouvrez chacun et vérifiez qu'il est actif. Un flux inactif ne réagit ni à ses webhooks ni à ses déclencheurs planifiés.
4. Les webhooks : si leur adresse a changé, reportez la nouvelle dans chaque service extérieur qui les appelle.
5. L'ancienne instance : arrêtez-la une fois la nouvelle vérifiée, pour qu'un même déclencheur planifié ne parte pas deux fois.

Sur un VPS Hubspace

Docker et Compose sont installés à la livraison, et le compte admin les utilise sans sudo. Seuls les ports 22, 80 et 443 sont ouverts depuis Internet : n8n se sert derrière son proxy en HTTPS, comme dans l'article d'installation. La migration VPS est offerte sur toutes les tailles pour des applications lancées avec Docker ou Docker Compose : nous copions fichiers Compose, volumes et bases depuis votre serveur actuel, relançons les conteneurs et vérifions qu'ils répondent, avant que vous ne testiez vous-même. Les conditions de la migration VPS détaillent ce qui reste à votre charge.

Questions fréquentes