ovh n8n : installer et maintenir un VPS fiable en 2026

En bref

• Un déploiement ovh n8n exige un VPS sous Debian 11 ou supérieur recommandé, un accès sudo par SSH, un domaine correctement dirigé vers le serveur et les ports 22, 80 et 443 maîtrisés.
• Docker Compose lance n8n derrière Traefik, avec HTTPS et un volume persistant monté sur /home/node/.n8n.
• L’auto-hébergement vous confie les sauvegardes, la supervision, la sécurité du système, la reprise sur erreur et chaque montée de version.
• Renoncez si le processus reste rare, change souvent ou coûte moins à exécuter manuellement qu’à maintenir durablement.

Une équipe peut vouloir importer des commandes chaque matin, rapprocher des factures chaque semaine ou transmettre des données à chaque webhook reçu. Avant d’installer ovh n8n, documentez qui accomplit aujourd’hui cette tâche, à quelle fréquence, avec quelles données et quelles conséquences si une exécution échoue.

Le VPS ne répond pas à ces questions. Il apporte une instance n8n auto-hébergée dont vous maîtrisez le système et le stockage, au prix d’une responsabilité continue. Ce guide couvre l’installation, mais aussi les conditions qui rendent ce choix défendable dans le temps.

En bref

Le guide OVHcloud mis à jour le 23 septembre 2025 recommande Debian 11 ou supérieur, un nom de domaine et un accès administrateur sudo par SSH. Les preuves disponibles ne fixent aucun minimum officiel de CPU, de mémoire ou de stockage. Le dimensionnement devra donc partir des exécutions attendues, de leur concurrence, du volume des données et de leur durée de conservation.

La stack documentée associe Docker Compose, Traefik et n8n. Traefik reçoit le trafic sur les ports 80 et 443, obtient le certificat TLS par ACME puis route les requêtes vers le port interne 5678 de n8n. Le volume n8n_data conserve les données placées dans /home/node/.n8n.

Cette architecture reste exploitable si une personne prend explicitement en charge :

• les mises à jour du VPS et des images ;
• la surveillance des conteneurs et des exécutions ;
• les sauvegardes et leurs tests de restauration ;
• le renouvellement des accès et des secrets ;
• la reprise après une panne ou une montée de version ratée.

Sans cette responsabilité, l’offre infogérée réduit le risque d’exploitation. Si le processus intervient rarement, change sans cesse ou tolère facilement un traitement manuel, l’automatisation peut aussi coûter plus à maintenir qu’elle ne rapporte.

Faut-il choisir ovh n8n plutôt qu’une offre infogérée ?

L’auto-hébergement se décide sur les contraintes du processus. Il faut connaître les données qui traverseront l’instance, leur sensibilité, les systèmes joints, la fréquence des déclencheurs et la personne qui interviendra lorsqu’un conteneur tombe.

Un VPS OVHcloud vous donne la main sur le système, le réseau et le stockage. Cette maîtrise déplace aussi vers votre organisation les sauvegardes, les alertes, les correctifs et les montées de version. Une offre infogérée retire une partie de cette charge d’infrastructure, sans supprimer le cadrage des workflows, la recette ni le traitement des erreurs métier.

Ce qui est propre au compte, au réseau et au DNS OVHcloud

Vous gérez le VPS, son accès administrateur, les règles réseau et les enregistrements DNS. Un enregistrement A dirige le domaine vers une adresse IPv4 ; un enregistrement AAAA remplit le même rôle pour IPv6. Cette adresse doit conduire au serveur sur lequel Traefik reçoit les requêtes.

Le pare-feu réseau du fournisseur et celui du système doivent rester cohérents. Un changement du port SSH demande une préparation minutieuse : adaptez d’abord les règles, conservez une session ouverte pour tester le nouvel accès, puis retirez l’ancien chemin.

Ce qui dépend de Docker, Traefik et n8n

Docker exécute les conteneurs. Docker Compose décrit leurs paramètres, leurs réseaux et leurs volumes. Traefik termine la connexion HTTPS et transmet la requête à n8n, tandis que n8n construit et exécute les workflows.

Ces composants ne dépendent pas exclusivement d’OVHcloud. Les variables d’environnement, le stockage persistant, la configuration du proxy inverse et les procédures de sauvegarde suivent les mêmes principes sur tout hôte Docker compatible.

Quand la charge de maintenance rend l’auto-hébergement peu rentable

Réexaminez l’auto-hébergement si personne ne peut recevoir une alerte, consulter un journal, restaurer une sauvegarde ou piloter une montée de version. Le même constat vaut lorsque l’équipe ne peut pas protéger durablement la clé de chiffrement.

Le calcul doit intégrer le coût récurrent. Un workflow exécuté quelques fois par mois, fondé sur une procédure encore instable ou corrigé manuellement sans conséquence sérieuse justifie rarement une instance supplémentaire à exploiter. Dans ce cas, simplifiez d’abord le processus, choisissez une offre infogérée ou conservez le traitement humain.

Prérequis pour installer n8n sur un VPS OVHcloud

Réunissez les accès, le domaine et les règles réseau avant de lancer le premier conteneur. Vous éviterez ainsi une interface inaccessible, un certificat impossible à délivrer ou un accès SSH coupé pendant la configuration.

Accès sudo, authentification SSH par clé et compte administrateur

Le guide OVHcloud recommande un VPS sous Debian 11 ou supérieur et un compte capable d’exécuter des commandes avec sudo. Connectez-vous d’abord par SSH et installez une authentification par clé. OVHcloud recommande également des mises à jour régulières du système.

Le compte administrateur n8n appartient à une autre couche. Depuis n8n 1.0, vous le créez obligatoirement lors du premier accès à l’instance. Il ne remplace ni le compte Linux ni la clé SSH.

Nom de domaine et enregistrements A ou AAAA vers le VPS

Choisissez un nom dédié, par exemple un sous-domaine réservé à n8n. Créez son enregistrement A ou AAAA vers l’adresse publique du VPS, puis attendez que la résolution renvoie effectivement cette adresse avant de solliciter le certificat.

Traefik déduit les domaines des règles Host(). Chaque nom concerné doit donc pointer vers le serveur qui reçoit le trafic. Une faute dans le domaine ou une ancienne adresse suffit à faire échouer l’accès et la demande ACME.

Rôle des ports 22, 80 et 443

Port	Usage	Condition
22	Administration SSH du VPS	Restreindre autant que possible et protéger par clé
80	HTTP et challenge ACME HTTP-01	Rendre accessible depuis Internet si ce challenge est utilisé
443	Interface et webhooks en HTTPS, challenge TLS-ALPN-01 éventuel	Rendre accessible depuis Internet pour le trafic HTTPS

Le port interne 5678 sert à n8n dans la stack. Traefik doit le joindre sur le réseau Docker, mais il n’a pas besoin d’être publié directement sur Internet.

Pourquoi le dimensionnement dépend des exécutions et des données

Aucune preuve officielle fournie ici ne chiffre un minimum de CPU, de RAM ou de stockage pour cette installation. Il serait donc trompeur de présenter une taille de VPS universelle.

Dimensionnez après avoir recensé la fréquence des déclencheurs, les pointes de concurrence, la taille des fichiers, la mémoire consommée par les traitements et la conservation des journaux. Un workflow qui déplace de petits objets séquentiellement ne sollicite pas le serveur comme plusieurs exécutions parallèles qui transforment des documents.

Commencez avec des mesures observables. Surveillez ensuite l’usage réel et les erreurs avant d’augmenter les ressources.

Vérifier les ports Docker au-delà des seules règles UFW ou firewalld

La documentation Docker avertit que les ports publiés par les conteneurs peuvent contourner des règles UFW ou firewalld. Une règle locale apparemment restrictive ne prouve donc pas qu’un service reste inaccessible.

Contrôlez les ports publiés avec docker compose ps, puis vérifiez les règles iptables et la chaîne DOCKER-USER. Dans la stack visée, publiez 80 et 443 pour Traefik. Gardez 5678 sur le réseau interne Docker.

Installer Docker et Docker Compose sur le VPS OVHcloud

Les commandes exactes d’ajout du dépôt dépendent de la version de Debian. Suivez la procédure courante de la documentation officielle Docker pour Debian afin de récupérer la clé et le dépôt APT correspondant à votre système.

Préparer Debian et ajouter le dépôt APT officiel de Docker

Mettez d’abord l’index et les paquets du système à jour :

sudo apt update
sudo apt upgrade

Ajoutez ensuite la clé et le dépôt APT officiels Docker. Ce choix rattache les paquets installés à la source maintenue par Docker plutôt qu’à une commande téléchargée sans contrôle.

Installer Docker Engine et le plugin Docker Compose

Une fois le dépôt configuré, installez les composants documentés :

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Le plugin fournit la commande docker compose. Les anciennes instructions fondées sur un exécutable séparé docker-compose ne décrivent pas cette installation.

Contrôler le service avec systemctl et une exécution hello-world

Vérifiez que le service tourne :

sudo systemctl status docker

Puis lancez l’image de contrôle :

sudo docker run hello-world

Arrêtez-vous si le service reste inactif ou si l’image ne démarre pas. Consultez le journal du service avant de créer la stack n8n :

sudo journalctl -u docker

Déployer n8n sur OVHcloud avec Docker Compose et Traefik

Le déploiement comprend quatre éléments liés : les variables d’environnement, Traefik, le conteneur n8n et le stockage persistant. Comprenez leur rôle avant le premier démarrage, car une erreur de domaine ou de volume peut rester discrète jusqu’au premier webhook ou redémarrage.

Créer le fichier d’environnement sans exposer les secrets

Placez la configuration dans un répertoire réservé à la stack et protégez le fichier .env. Il doit contenir les valeurs utilisées par Compose, dont le domaine, le sous-domaine, le fuseau horaire et une clé de chiffrement longue, aléatoire et stable.

Exemple de structure :

DOMAIN_NAME=example.net
SUBDOMAIN=n8n
GENERIC_TIMEZONE=Europe/Berlin
N8N_ENCRYPTION_KEY=valeur_aleatoire_longue_et_conservee_hors_du_serveur

Remplacez example.net par le domaine réellement contrôlé. Ne placez pas ce fichier dans un dépôt public. Conservez une copie sécurisée de la clé hors du VPS.

Déclarer Traefik, n8n et le volume persistant

Le fichier compose.yaml doit :

• publier les ports 80 et 443 sur Traefik ;
• relier Traefik et n8n sur un réseau commun ;
• router le domaine vers le port interne 5678 ;
• monter n8n_data sur /home/node/.n8n ;
• transmettre à n8n ses URL publiques, son fuseau horaire et sa clé de chiffrement.

Déclarez le volume nommé au niveau supérieur du fichier :

volumes:
  n8n_data:

Puis montez-le dans le service n8n :

volumes:
  - n8n_data:/home/node/.n8n

Ce dossier contient notamment la base SQLite et la clé générée par défaut lorsqu’aucune clé personnalisée n’a été fixée. Définir N8N_ENCRYPTION_KEY rend la conservation du secret explicite.

Préparer ACME et le routage du domaine

La stack OVHcloud documentée utilise Traefik et un fichier letsencrypt/acme.json. Créez ce fichier selon les instructions de la configuration retenue et protégez-le, car Traefik y conserve les informations ACME.

Le routeur Traefik doit employer une règle Host() qui correspond exactement au domaine publié dans le DNS. Il active TLS, sélectionne le résolveur ACME et dirige le trafic vers le port 5678 du service n8n.

Pour un challenge HTTP-01, le port 80 doit rester joignable depuis Internet. Pour TLS-ALPN-01, cette exigence porte sur le port 443.

Démarrer les conteneurs avec docker compose up -d

Contrôlez d’abord la configuration résolue :

docker compose config

Cette sortie peut contenir des valeurs sensibles. Ne la diffusez pas.

Lancez ensuite la stack depuis son répertoire :

docker compose up -d

Compose crée le volume nommé au premier lancement et le réutilise lors des démarrages suivants au sein du même projet.

Vérifier les services, les ports et l’accès HTTPS

Inspectez l’état :

docker compose ps
docker compose logs -f traefik
docker compose logs -f n8n

Ouvrez ensuite l’URL HTTPS déclarée. Vérifiez le certificat dans le navigateur, puis contrôlez que Traefik publie uniquement les ports prévus et que n8n ne publie pas directement 5678.

La supervision commence ici. Si un service s’arrête, une alerte doit conduire quelqu’un vers les journaux ; Compose ne transforme pas seul un redémarrage en diagnostic ni en reprise métier.

Configurer les URL, les webhooks et les accès n8n

Derrière un proxy inverse, n8n doit connaître les adresses que les utilisateurs et les services externes voient. Une URL interne correcte ne suffit pas : les webhooks générés doivent reprendre le domaine public et le protocole HTTPS.

Définir N8N_EDITOR_BASE_URL et l’URL publique des webhooks

Définissez l’URL publique de l’éditeur :

N8N_EDITOR_BASE_URL=https://n8n.example.net/

Pour les webhooks, une divergence documentaire demande de vérifier la version installée. Le guide OVHcloud de 2025 utilise encore WEBHOOK_URL. À partir de n8n 2.35.0, la documentation n8n indique que N8N_WEBHOOK_URL la remplace :

N8N_WEBHOOK_URL=https://n8n.example.net/

Employez la variable attendue par votre version. Après une montée de version, vérifiez l’URL affichée par un noeud Webhook et effectuez un appel de recette depuis l’extérieur du VPS.

Configurer N8N_PROXY_HOPS et les en-têtes transmis par Traefik

Avec un seul proxy inverse devant n8n, configurez :

N8N_PROXY_HOPS=1

Traefik doit transmettre les en-têtes X-Forwarded nécessaires, notamment le protocole et l’hôte d’origine. Sans cette chaîne cohérente, n8n peut construire des URL incorrectes ou mal interpréter la connexion HTTPS.

Si l’architecture ajoute un autre proxy, un répartiteur ou un réseau intermédiaire, recomptez les sauts au lieu de recopier mécaniquement la valeur 1.

Choisir GENERIC_TIMEZONE pour les noeuds planifiés

GENERIC_TIMEZONE fixe le fuseau utilisé par l’instance, avec un impact direct sur les noeuds planifiés :

GENERIC_TIMEZONE=Europe/Berlin

Choisissez le fuseau du processus, puis testez les changements d’heure s’ils affectent les échéances métier. Une exécution planifiée doit laisser un journal horodaté et déclencher une alerte lorsqu’elle manque son résultat attendu.

Fixer et conserver N8N_ENCRYPTION_KEY

Définissez une clé personnalisée avant de créer les identifiants :

N8N_ENCRYPTION_KEY=valeur_aleatoire_longue_et_stable

n8n chiffre les identifiants avec cette clé. Sauvegardez-la séparément du volume et limitez son accès. Une restauration avec une autre encryptionKey récupère éventuellement les données, mais ne rend pas les identifiants chiffrés utilisables.

Tous les workers doivent partager la même clé en mode file d’attente.

Créer le compte propriétaire et limiter l’exposition administrative

Au premier accès, créez le compte propriétaire propre à l’instance. Employez un mot de passe distinct et contrôlé par l’organisation.

L’éditeur n’a pas toujours besoin d’être accessible depuis tous les réseaux. Selon le contexte, limitez son exposition par filtrage réseau ou par une couche d’accès adaptée, sans bloquer les chemins de webhook qui doivent rester publics. Gardez l’administration SSH sous clé et appliquez régulièrement les mises à jour du système.

Choisir l’architecture n8n adaptée à la charge

L’hébergement ne tranche ni la forme des workflows ni la manière de gérer les décisions métier. Ces choix partent du volume, de la concurrence, de la variabilité des données et de la reprise attendue.

SQLite pour une instance simple ou PostgreSQL pour une file d’attente

SQLite reste la base par défaut d’une instance n8n auto-hébergée. Elle convient à une architecture simple lorsque les contraintes du processus et les tests confirment ce choix.

Avec des workers et une file d’attente, privilégiez PostgreSQL. La documentation n8n déconseille SQLite en mode queue et ne la prend pas en charge dans une architecture distribuée. En juillet 2026, n8n prend en charge PostgreSQL 17 et 18, avec la version 16 pour compatibilité ; utilisez le dernier correctif mineur de la version majeure choisie.

PostgreSQL ajoute son propre cycle d’exploitation : sauvegarde, restauration, mises à jour et supervision. Intégrez-le au calcul avant de migrer.

Traitement direct ou workers selon la concurrence attendue

Un traitement direct garde une architecture lisible : l’instance reçoit le déclencheur et exécute le workflow. Il convient tant que la charge observée reste compatible avec les ressources et le niveau de service attendu.

Une file d’attente et des workers séparent la réception du travail de son exécution. Ce montage vise une concurrence plus élevée ou une répartition des traitements, mais ajoute Redis, PostgreSQL, une clé commune et plusieurs composants à surveiller.

Dans les deux cas, prévoyez un identifiant de corrélation. Il doit relier la requête entrante, l’exécution et l’action produite afin qu’une reprise n’envoie pas deux fois la même commande ou le même message.

Workflow unique ou workflows découpés selon les responsabilités et la reprise sur erreur

Un workflow unique facilite la lecture lorsque le processus reste court, linéaire et porté par une seule responsabilité. Il devient fragile quand plusieurs branches suivent des rythmes, des propriétaires ou des règles de reprise différents.

Découpez lorsque chaque partie peut recevoir un contrat d’entrée, produire un résultat vérifiable et reprendre indépendamment. Ce choix augmente toutefois le nombre de déclencheurs, de journaux et de liens à suivre. Documentez les entrées, les sorties et l’identifiant de corrélation de chaque workflow.

L’échec d’un sous-workflow doit remonter au pilote ou ouvrir un traitement humain. Une chaîne découpée qui masque une erreur coûte plus cher à exploiter qu’un workflow plus long mais observable.

Règle déterministe ou modèle de langage selon la variabilité des données

Une règle déterministe convient lorsque les données suivent un format stable et que la décision s’exprime par des conditions vérifiables. Elle se teste facilement et reproduit la même sortie pour la même entrée.

Un modèle de langage peut traiter un contenu plus variable, mais sa réponse demande une validation, des limites et un chemin de repli. Ne lui confiez pas seul une décision irréversible. Journalisez l’entrée utile, la sortie et la version de la consigne, dans les limites imposées par la confidentialité des données.

Si une règle claire couvre le besoin, elle réduira généralement la charge de recette et de supervision.

Ce que l’hébergement ne permet pas de décider sans cadrage métier

Le VPS ne révèle pas si un doublon reste acceptable, qui corrige une facture rejetée ou combien de temps une donnée peut attendre. Il ne fixe pas non plus la durée de conservation des exécutions.

Avant de choisir l’architecture, consignez :

• l’auteur actuel de chaque action ;
• la fréquence normale et les pointes ;
• les données entrantes et leur source ;
• les effets irréversibles ;
• le délai de reprise acceptable ;
• la personne qui traite l’exception.

Sans ces réponses, dimensionner le VPS ou introduire des workers revient à choisir une solution avant d’avoir défini le problème.

Sauvegarder et restaurer une instance n8n sur OVHcloud

Une sauvegarde n’a de valeur qu’après une restauration testée. Elle doit couvrir les workflows, les identifiants chiffrés, la base, les fichiers de configuration et les secrets nécessaires pour relancer le service.

Inventorier le volume, la base et les secrets

Pour l’installation Docker standard avec SQLite, protégez au minimum :

• le volume n8n_data, monté sur /home/node/.n8n ;
• la valeur exacte de N8N_ENCRYPTION_KEY ;
• le fichier Compose et la configuration Traefik ;
• les variables nécessaires au domaine, au proxy et au fuseau horaire ;
• les informations ACME utiles à la stack.

Si vous utilisez PostgreSQL, le volume .n8n ne remplace pas une sauvegarde cohérente de la base. Ajoutez cette base à l’inventaire et documentez ensemble leurs versions et leur date de capture.

Archiver /home/node/.n8n dans une installation Docker standard

Le guide OVHcloud documente cette commande pour un conteneur nommé n8n :

docker exec n8n tar czvf - /home/node/.n8n > n8n-backup.tar.gz

Adaptez le nom du conteneur si Compose en génère un autre. Contrôlez le code de sortie, l’existence du fichier et sa taille, puis transférez l’archive vers un stockage distinct du VPS.

Cette commande couvre le chemin n8n par défaut. Elle ne constitue pas à elle seule une sauvegarde PostgreSQL ni une copie de la clé personnalisée conservée hors du volume.

Restaurer les données avec la même clé de chiffrement

Recréez la stack avec une configuration cohérente, remettez le contenu sauvegardé dans /home/node/.n8n et réinjectez exactement la même clé de chiffrement. Sans elle, n8n ne pourra pas relire correctement les identifiants protégés.

Évitez d’écrire dans le volume pendant la restauration. Vérifiez ensuite son montage, démarrez les services et ouvrez l’éditeur. Testez un identifiant sur une opération sans effet irréversible avant de réactiver les déclencheurs de production.

Tester la restauration et alerter en cas d’échec de sauvegarde

Programmez un contrôle qui vérifie le résultat de chaque sauvegarde et déclenche une alerte si la commande échoue, si le fichier manque ou si son transfert n’aboutit pas. Le message doit identifier le VPS, la sauvegarde concernée et la personne chargée de la reprise.

Testez périodiquement la restauration dans un environnement isolé. La recette doit ouvrir les workflows, relire les identifiants et exécuter un parcours représentatif sans toucher aux systèmes de production.

Mettre à jour n8n sans traiter la production comme un test

Une montée de version touche l’image, la base, les variables et parfois le comportement des noeuds. Préparez donc un retour arrière et une recette avant d’arrêter la stack.

Les sources disponibles documentent séparément la sauvegarde, les commandes de mise à jour et les contrôles. Elles ne réunissent pas ces éléments dans une procédure officielle unique. La séquence ci-dessous les articule comme une pratique d’exploitation à valider sur votre architecture.

Lire les notes de version et préparer une reprise

Consultez les notes de version n8n et repérez les changements incompatibles, les variables renommées et les migrations de base. La transition de WEBHOOK_URL vers N8N_WEBHOOK_URL à partir de n8n 2.35.0 illustre ce point.

Notez l’image actuellement déployée, conservez le fichier Compose correspondant et définissez les critères d’arrêt de la recette. Lorsque l’édition et l’organisation le permettent, testez d’abord dans un environnement de préproduction.

Sauvegarder avant la montée de version

Sauvegardez le volume .n8n, la base PostgreSQL si elle existe, la configuration et la clé de chiffrement. Contrôlez que les fichiers produits peuvent être lus depuis un autre emplacement.

Une alerte de sauvegarde non résolue bloque la montée de version. Poursuivre supprimerait le seul chemin de reprise documenté.

Mettre à jour les images et redémarrer la stack

Depuis le répertoire Compose, la séquence documentée utilise :

docker compose pull
docker compose down
docker compose up -d

pull récupère les images déclarées, down arrête la stack et up -d la recrée en arrière-plan. Vérifiez le tag d’image afin de savoir précisément quelle version vous déployez.

Contrôler les journaux, les webhooks et un workflow de recette

Après le redémarrage, contrôlez :

docker compose ps
docker compose logs -f n8n
docker compose logs -f traefik

Ouvrez l’éditeur en HTTPS, vérifiez les identifiants, appelez un webhook de recette depuis l’extérieur puis exécutez un workflow représentatif. Suivez l’identifiant de corrélation jusqu’au résultat final et vérifiez aussi le chemin d’échec.

Ne réactivez les déclencheurs critiques qu’après cette recette.

Revenir à la version précédente si la recette échoue

Arrêtez les déclencheurs, collectez les journaux et déterminez si l’échec vient de l’image, d’une migration ou de la configuration. Redéployez la version précédente à partir du fichier conservé lorsque ce retour reste compatible avec les changements déjà appliqués.

Si la base ou les données ont subi une migration incompatible, restaurez l’ensemble cohérent préparé avant la montée de version. Gardez le service arrêté tant que les identifiants, les webhooks ou les traitements irréversibles ne passent pas la recette.

Superviser ovh n8n et diagnostiquer les échecs

La supervision n8n doit relier un symptôme à une action. Chaque workflow critique produit un journal exploitable, conserve un identifiant de corrélation et envoie une alerte à une personne désignée. En cas d’échec, le système reprend de façon contrôlée ou confie l’élément à un traitement humain.

Conteneur arrêté : vérifier docker compose ps et les journaux

Commencez par :

docker compose ps
docker compose logs -f n8n
docker compose logs -f traefik

docker compose ps montre l’état courant et les ports publiés. Les journaux révèlent ensuite une erreur de démarrage, de variable, de connexion à la base ou de certificat.

Après correction, relancez le service concerné et rejouez seulement les exécutions dont l’effet peut être contrôlé. Vérifiez d’abord si l’action externe a déjà abouti.

Domaine inaccessible : contrôler DNS, pare-feu et ports publiés

Résolvez le domaine et comparez l’adresse retournée à celle du VPS. Contrôlez ensuite les règles du pare-feu réseau, celles du système et les ports publiés par Docker.

Lancez aussi :

docker compose config
docker compose ps

La première commande expose la configuration résolue, y compris des secrets éventuels ; consultez-la localement. Vérifiez que la règle Host() de Traefik reprend exactement le domaine demandé.

Certificat absent : vérifier le routeur Traefik et le challenge ACME

Pour HTTP-01, Let’s Encrypt doit joindre Traefik sur le port 80. Pour TLS-ALPN-01, il doit le joindre sur le port 443. Contrôlez le DNS, le routeur, le résolveur ACME et les journaux Traefik.

Chaque domaine et chaque nom alternatif demandé doit posséder les enregistrements A ou AAAA appropriés. Une demande portant sur un nom qui ne mène pas à Traefik bloque la délivrance attendue.

Webhook incorrect : contrôler les URL publiques et le proxy inverse

Comparez l’URL générée par n8n au domaine public. Contrôlez N8N_EDITOR_BASE_URL, ainsi que N8N_WEBHOOK_URL pour n8n 2.35.0 ou supérieur ou la variable historique attendue par les versions précédentes.

Vérifiez ensuite les en-têtes transmis par Traefik. Effectuez l’appel depuis un réseau extérieur, avec un identifiant de corrélation, puis retrouvez l’exécution dans n8n. Si elle échoue, conservez la charge utile nécessaire au diagnostic en respectant les contraintes de confidentialité.

Données perdues après redémarrage : inspecter Source, Destination et RW

Inspectez le conteneur :

docker inspect n8n

Dans la section Mounts, vérifiez :

• Source, qui doit désigner le volume attendu ;
• Destination, qui doit valoir /home/node/.n8n ;
• RW, qui doit valoir true.

Un volume nommé déclaré dans Compose doit être réutilisé lors des démarrages suivants du même projet. Un changement de répertoire, de nom de projet ou de volume peut toutefois conduire Compose vers un autre stockage. Identifiez la source réellement montée avant toute copie.

Permissions défectueuses : constater le montage sans inventer de procédure UID ou GID

Avec un bind mount, le répertoire hôte doit exister avec une propriété et des permissions qui laissent le processus du conteneur écrire. Les preuves disponibles établissent ce contrôle, mais ne fournissent pas de procédure officielle complète pour diagnostiquer puis corriger un UID ou un GID défectueux dans n8n_data.

Relevez donc le type de montage, son chemin, son mode lecture-écriture et le message exact du journal. N’appliquez pas récursivement une propriété ou des droits copiés d’un autre serveur sans avoir identifié l’utilisateur effectif du conteneur et l’étendue des fichiers concernés.

Définir les alertes, la reprise sur erreur et la responsabilité d’intervention

Une surveillance utile couvre au moins l’arrêt des conteneurs, l’échec des sauvegardes, l’indisponibilité HTTPS et les exécutions critiques en erreur. Chaque alerte indique l’instance, le workflow, l’identifiant de corrélation, l’heure et le point de reprise.

Classez ensuite les traitements :

• reprise automatique pour une erreur transitoire dont l’opération reste idempotente ;
• reprise manuelle lorsque l’action externe a peut-être déjà eu lieu ;
• mise à l’écart des données invalides avec notification au responsable ;
• arrêt du flux lorsque poursuivre créerait une incohérence.

N’automatisez pas une reprise qui pourrait doubler un paiement, une commande ou un envoi. Le workflow doit vérifier l’état externe avant de rejouer l’action.

ovh n8n : installer et maintenir un VPS fiable en 2026

Retenez un VPS OVHcloud si votre organisation peut exploiter durablement Docker, Traefik, les sauvegardes, la supervision et les montées de version. La maîtrise de l’instance a un coût permanent. Une offre infogérée mérite d’être réexaminée dès que cette charge repose sur une personne sans relais.

Renoncez aussi à automatiser lorsque le processus reste rare, instable ou peu coûteux à traiter manuellement. Une automatisation fiable exige toujours une recette, des alertes et un propriétaire pour les exceptions.

L’étape suivante consiste à documenter un processus réel : qui l’exécute aujourd’hui, combien de fois par semaine, quelles données il manipule, ce qu’un échec provoque et qui assure la reprise. Ce relevé guidera ensuite le choix d’architecture et le dimensionnement du VPS, sans inventer un minimum matériel que les sources officielles ne donnent pas.