Comment mettre à jour son instance n8n sans rien casser ?

Pourquoi mettre à jour son instance n8n régulièrement ?

n8n publie des versions fréquentes qui corrigent des failles de sécurité, ajoutent des nœuds et améliorent les performances. Une instance qui reste bloquée sur une vieille version accumule un retard qui rend chaque mise à jour future plus risquée.

La documentation officielle de n8n recommande explicitement de mettre à jour fréquemment, au moins une fois par mois, pour « éviter d’avoir à sauter plusieurs versions d’un coup, ce qui réduit le risque d’une mise à jour perturbatrice ». C’est l’inverse de l’intuition qui pousse à repousser une mise à jour par peur de casser quelque chose.

Chez Amari Agency, nous voyons régulièrement des instances laissées à l’abandon pendant six mois ou un an : la mise à jour qui suit cumule alors plusieurs changements de comportement en même temps, ce qui rend le diagnostic d’un éventuel incident beaucoup plus long.

Quelles précautions prendre avant une mise à jour ?

Trois vérifications simples évitent la majorité des incidents de mise à jour. Elles prennent quelques minutes et doivent devenir un réflexe avant chaque version majeure.

1. Lire les notes de versionLes release notes officielles de n8n listent les changements cassants (« breaking changes ») avant même de télécharger la nouvelle image.
2. Sauvegarder le dossier .n8n et la base de donnéesCe dossier contient les clés de chiffrement des identifiants, les logs et les assets liés au contrôle de version. Une copie datée avant toute manipulation permet un retour arrière immédiat.
3. Tester dans un environnement de préproductionLa documentation conseille d’utiliser une instance de test pour valider la nouvelle version avant de toucher à la production, notamment si des credentials tiers ou des sous-workflows sensibles sont en jeu.

Comment mettre à jour n8n en Docker ?

Si votre instance tourne en conteneur Docker classique (hors Docker Compose), la documentation d’installation Docker décrit la procédure suivante :

1. Récupérer la dernière imagedocker pull docker.n8n.io/n8nio/n8n télécharge la version stable la plus récente.
2. Identifier et arrêter le conteneur actueldocker ps -a pour retrouver l’identifiant, puis docker stop <container_id>.
3. Supprimer l’ancien conteneurdocker rm <container_id> — le volume de données persistant n’est pas touché.
4. Relancer un conteneur avec la nouvelle imagedocker run --name=<nom> [options] -d docker.n8n.io/n8nio/n8n en reprenant les mêmes options de volume et de variables d’environnement.

En Docker Compose, la même logique se résume à trois commandes : docker compose pull, docker compose down, puis docker compose up -d. La documentation précise aussi que conserver le dossier .n8n reste recommandé même avec PostgreSQL, car il contient les clés de chiffrement, les logs d’instance et les assets liés au contrôle de version.

Comment mettre à jour n8n installé via npm ?

Pour une installation directe avec Node.js, la documentation npm de n8n propose deux commandes selon le canal souhaité :

Après la commande, redémarrez le service n8n (via votre gestionnaire de processus, par exemple PM2 ou systemd) pour que la nouvelle version soit effectivement chargée.

Faut-il faire quelque chose sur n8n Cloud ?

Sur l’offre cloud, l’hébergeur gère lui-même les mises à jour de la plateforme : il n’y a rien à lancer manuellement. La vigilance porte alors sur vos propres workflows, notamment si une note de version signale un changement de comportement sur un nœud que vous utilisez. Notre comparatif n8n cloud ou auto-hébergé détaille cette différence de responsabilité.

Comment gérons-nous les mises à jour chez Amari Agency ?

Voici la méthode que nous appliquons pour nos propres instances et celles de nos clients, sans donnée chiffrée ni promesse artificielle.

Cette discipline coûte peu de temps par rapport à un incident de production découvert a posteriori, en particulier lorsque le workflow touché gère de la facturation ou de la communication client.

Que faire si la mise à jour casse un workflow ?

Si un workflow échoue après la mise à jour, commencez par consulter les logs d’exécution pour identifier le nœud fautif, puis vérifiez si la note de version mentionne un changement de comportement sur ce nœud précis.

Si le retour arrière s’impose, réinstallez l’image ou le paquet npm correspondant à la version précédente, puis restaurez le volume de données sauvegardé. C’est aussi pour cette raison que la documentation officielle recommande de tester d’abord en préproduction : l’incident se produit alors sur une instance qui ne sert pas de production. Pour approfondir le diagnostic d’un workflow en échec, voir notre article sur comment débugger un workflow n8n qui ne fonctionne pas.

Quels contenus lire ensuite ?

Ces ressources complètent cette procédure de mise à jour sans cibler la même requête :

Questions fréquentes sur la mise à jour de n8n