Sommaire
En bref
- Une instance n8n self-hosted réclame un responsable identifié pour la sauvegarde, la supervision et la montée de version.
- Docker rassemble les services, PostgreSQL porte les données d’une production durable, et le reverse proxy publie l’interface sans exposer directement le conteneur.
- SQLite convient aux essais et à un usage restreint ; des workflows continus ou plusieurs utilisateurs orientent vers PostgreSQL.
- Sans capacité interne à traiter une alerte, restaurer une sauvegarde et suivre les mises à jour, la version infogérée reste souvent plus cohérente.
Une automatisation échoue rarement au moment où l’on dessine le workflow. Elle échoue plus tard, lorsqu’un jeton expire, qu’un webhook ne répond plus ou qu’une mise à jour attend sur un serveur sans responsable. Une installation n8n self-hosted répond à un besoin réel de maîtrise, mais elle déplace aussi une part d’exploitation vers votre équipe.
En 2026, le choix se prépare donc avant le premier conteneur. Il faut savoir quelles données circulent, qui les déclenche, à quelle fréquence les exécutions tombent, qui consulte les journaux et qui décide d’arrêter un workflow lorsqu’il produit une erreur. L’objectif n’est pas d’empiler de la technique : il s’agit de construire une automatisation sur infrastructure privée que l’équipe pourra réellement tenir.
Votre PME doit-elle s'auto-héberger ?
Ce questionnaire comporte 6 questions sur votre usage actuel ou prévu de n8n : fréquence des exécutions, sensibilité des données, contraintes de réseau, exploitation, webhooks et maintenance. Vos réponses permettent de situer l'option infogérée face à une instance auto-hébergée, avec les prérequis d'exploitation associés.
n8n self-hosted : décider si l’auto-hébergement est pertinent
En bref
Le cadrage commence par le processus métier. Une personne ressaisit-elle des données chaque semaine ? Plusieurs systèmes échangent-ils des informations sensibles ? Un déclencheur doit-il traiter une demande immédiatement, ou une file d’attente peut-elle absorber le décalage ? Ces réponses dessinent l’architecture utile.
L’auto-hébergement devient cohérent lorsque la maîtrise du serveur, des données et des accès répond à une contrainte précise, et lorsqu’une personne accepte d’exploiter l’instance. Une installation n8n sur serveur ne s’arrête pas à la mise en production.
Les responsabilités à accepter avant l’installation
Désignez un responsable de l’instance, un canal d’alerte et une procédure de reprise sur erreur. Chaque workflow doit conserver un identifiant de corrélation, journaliser son résultat et signaler les exécutions en échec. Sans cela, une erreur silencieuse peut laisser une équipe travailler sur des données incomplètes pendant plusieurs jours.
La version infogérée convient davantage quand personne ne peut suivre le serveur, restaurer les données ou planifier une montée de version. L’hébergement n8n garde alors un coût d’exploitation externe plus lisible que la charge interne déplacée.
SQLite ou PostgreSQL selon l’usage prévu
SQLite convient pour découvrir n8n ou faire tourner une instance limitée. La documentation n8n recommande PostgreSQL lorsqu’une production dépasse une poignée d’utilisateurs ou exécute des workflows en continu. PostgreSQL sépare les données du conteneur, facilite une exploitation plus robuste et prépare une évolution vers des workers.
Le passage de SQLite à PostgreSQL ne transfère toutefois pas automatiquement les données existantes dans l’exemple documenté. Décidez ce point avant de créer des identifiants et des workflows importants.
Quand renoncer à l’instance auto-hébergée
Renoncez si vous ne pouvez pas stocker une sauvegarde hors du serveur, vérifier une restauration ou recevoir une alerte. Renoncez aussi si le processus change chaque semaine et ne produit qu’un faible volume de travail répétitif : le cadrage, la recette et la maintenance peuvent coûter plus que les gestes manuels évités.
Ressources serveur : distinguer les prérequis de la pile Assistant du besoin réel
Le guide Docker Compose de n8n demande au moins 4 Go de mémoire et 2 vCPU pour la pile qui inclut le sandbox d’Assistant. Ce seuil ne décrit pas un minimum universel pour toute instance. Mesurez plutôt les exécutions attendues, les fichiers manipulés et la concurrence, puis observez les journaux avant d’augmenter les ressources.
Installer n8n auto-hébergé avec Docker Compose
Vérifier Docker Engine et Docker Compose v2
Sur Linux, vérifiez d’abord que Docker Engine fonctionne, puis lancez docker compose version. Sur Ubuntu ou Debian, Docker documente l’installation du plugin Compose via le gestionnaire de paquets, à condition que Docker Engine et la CLI soient déjà présents.
Structurer le fichier Compose et les volumes persistants
Le service n8n doit monter un volume persistant pour le dossier .n8n. Ce dossier contient notamment la configuration et la clé qui chiffre les identifiants. Avec SQLite, il porte aussi la base intégrée. Sans volume, une recréation du conteneur peut faire disparaître les données utiles.
Gardez la configuration de déploiement avec le projet, sans y inscrire les secrets. Les variables sensibles peuvent s’appuyer sur le suffixe _FILE, que n8n documente pour éviter de les diffuser dans les variables d’environnement ou les fichiers partagés.
Ajouter PostgreSQL pour une instance de production
Le fichier Compose ajoute alors un service PostgreSQL, un volume persistant pour ses données et les variables de connexion côté n8n. Le service n8n attend que le contrôle de santé de PostgreSQL réussisse avant de démarrer.
Ce découpage ne règle pas tout seul les erreurs métier. Il donne en revanche une base de données adaptée à une exploitation durable et à une future architecture en file d’attente.
Démarrer les conteneurs et lire les journaux
Depuis le dossier du projet, lancez docker compose up -d, puis contrôlez les services avec docker compose ps. docker compose logs --follow suit les journaux et aide à repérer un refus de connexion à la base, une variable absente ou un problème de montage de volume.
Le local documenté par n8n vérifie que le service répond correctement. Gardez ce contrôle dans votre recette de déploiement, avec une alerte si la réponse échoue.
Effectuer la première connexion et la recette locale
Ouvrez l’interface locale après le démarrage et créez le compte propriétaire sur une instance neuve. Avant de bâtir un workflow métier, vérifiez une authentification, une exécution de test et l’écriture dans la base. Cette recette courte évite de confondre un défaut d’infrastructure avec une erreur dans un noeud.
Publier une instance n8n self-hosted avec un domaine et HTTPS
Faire pointer le sous-domaine vers le serveur
Créez un enregistrement DNS de type A pour le sous-domaine choisi, dirigé vers l’adresse IP du serveur. Attendez ensuite que ce nom résolve depuis l’extérieur avant de publier l’interface. Le nom public doit rester stable, car les services tiers l’utiliseront pour appeler les webhooks.
Placer Caddy devant le conteneur n8n
Caddy joue le rôle de reverse proxy Internet et relaie le trafic vers le service interne n8n. L’exemple officiel relaie vers n8n:5678 et configure le sous-domaine dans le Caddyfile. Le proxy concentre l’accès HTTPS et évite d’exposer directement n8n.
La documentation fournie décrit ce relais, mais ne détaille pas ici le cycle d’obtention et de renouvellement du certificat TLS. Validez ce comportement dans la documentation de votre configuration Caddy avant la recette publique.
Régler N8N_EDITOR_BASE_URL, N8N_WEBHOOK_URL et N8N_PROXY_HOPS
N8N_EDITOR_BASE_URL doit reprendre l’URL publique de l’éditeur. N8N_WEBHOOK_URL porte l’URL publique des webhooks de test et de production. N8N_PROXY_HOPS doit correspondre au nombre de reverse proxies placés devant n8n.
Ces variables empêchent n8n de générer des liens internes ou des URL de webhook incohérentes. Réglez aussi le protocole HTTPS et le nom d’hôte public dans la configuration de l’instance.
Limiter les ports exposés et tester le chemin HTTPS
Le pare-feu ouvre les ports HTTP et HTTPS nécessaires au reverse proxy. Le port interne de n8n reste réservé au réseau des conteneurs. Restreignez aussi l’administration du serveur aux personnes qui l’exploitent et conservez les jetons hors des fichiers partagés.
Ouvrez l’interface depuis un navigateur externe, vérifiez le certificat présenté, puis déclenchez un workflow de recette. Une interface accessible ne prouve pas qu’un webhook arrive au bon endroit.
Vérifier un webhook avec un identifiant de corrélation
Créez un webhook de recette qui journalise un identifiant de corrélation transmis dans la requête. Appelez son URL HTTPS, puis retrouvez cet identifiant dans l’exécution et dans le journal. Si l’appel échoue, vérifiez le DNS, le reverse proxy, l’URL publique configurée et les journaux du conteneur.
Sécuriser, superviser et faire évoluer n8n auto-hébergé
Protéger les jetons, l’authentification et la clé de chiffrement
La clé de chiffrement doit rester persistante. Elle conditionne la lecture des identifiants restaurés. Conservez-la avec une protection adaptée et ne la régénérez pas à chaque recréation de conteneur. Placez les mots de passe et paramètres de base dans des fichiers de secrets accessibles uniquement aux comptes d’exploitation.
Sauvegarder le dossier .n8n et la base PostgreSQL
Une sauvegarde complète copie le dossier .n8n. Avec PostgreSQL, elle ajoute une sauvegarde de la base externe réalisée avec ses propres outils. Conservez également la configuration de déploiement. La documentation n8n de sauvegarde et restauration insiste sur ce point : la base seule ne suffit pas à relire les identifiants chiffrés.
Tester une restauration avant d’en dépendre
Arrêtez n8n dans un environnement de recette, restaurez .n8n et PostgreSQL si vous l’utilisez, replacez la configuration puis redémarrez. Vérifiez ensuite l’accès, un identifiant existant et une exécution de test. Une sauvegarde qui n’a jamais été restaurée reste une hypothèse.
Superviser les exécutions et alerter en cas d’échec
Chaque workflow critique doit traiter son chemin d’erreur : journal, alerte et règle de reprise. Une erreur temporaire peut justifier une nouvelle tentative contrôlée ; une donnée invalide doit plutôt arrêter le flux et demander une décision humaine. Ce choix relève du cadrage, car répéter automatiquement une mauvaise opération peut aggraver l’incident.
Mettre à jour après recette en environnement de préproduction
Avant chaque montée de version, sauvegardez l’instance, lisez les notes de version, récupérez l’image puis redémarrez de façon contrôlée. n8n recommande des mises à jour au moins mensuelles et un test préalable dans un environnement dédié. Après la recette, contrôlez l’interface, la connexion à la base, un workflow et un webhook.
Reconnaître les limites d’un workflow unique et du mode standard
Découpez un workflow lorsqu’il mélange plusieurs responsabilités, par exemple réception, contrôle, écriture et notification. Les sous-workflows simplifient les tests et isolent les reprises sur erreur. Si l’interface ralentit sous la charge des exécutions, le processus principal porte probablement trop de travail.
Passer au mode queue sans conserver le stockage binaire sur filesystem
Le mode queue place les exécutions dans Redis. Une instance principale reçoit les déclencheurs, puis des workers exécutent le travail. n8n le présente comme son mode le plus scalable, avec accès partagé des workers à Redis et à la base.
Cette architecture réclame PostgreSQL plutôt que SQLite. Elle ne prend pas en charge le stockage binaire sur filesystem. Consultez la documentation officielle du mode queue avant de modifier une instance active.
Ce qu’il faut retenir
Après cette lecture, établissez une fiche de cadrage sur un processus concret : données traitées, déclencheur, responsable d’exploitation, comportement en erreur et test de restauration. Si ces cinq points trouvent un propriétaire, préparez une recette sur un environnement séparé. S’ils restent sans réponse, retenez la version infogérée ou conservez temporairement le traitement manuel. Le conteneur vient après cette décision.
FAQ
SQLite suffit-il pour une instance n8n auto-hébergée ?
SQLite convient aux essais et à un usage limité. Pour une production avec plusieurs utilisateurs ou des workflows continus, n8n recommande PostgreSQL. Le passage doit se préparer, car l’exemple documenté ne migre pas automatiquement les données SQLite existantes.
Quels éléments faut-il sauvegarder sur n8n self-hosted ?
Sauvegardez le dossier .n8n, la configuration de déploiement et la base PostgreSQL lorsqu’elle existe. Conservez impérativement la clé de chiffrement associée : sans elle, les identifiants restaurés ne pourront pas être lus.
Comment vérifier qu’un webhook n8n est accessible en HTTPS ?
Appelez le webhook depuis l’extérieur avec un identifiant de corrélation. Vérifiez que l’exécution le reçoit, puis consultez les journaux. En cas d’échec, contrôlez le DNS, le reverse proxy et N8N_WEBHOOK_URL.
Quand utiliser PostgreSQL, Redis et des workers ?
Adoptez PostgreSQL pour une production durable. Ajoutez Redis et des workers lorsque la concurrence et le volume d’exécutions dépassent ce que le processus principal absorbe sans dégrader l’interface. Le mode queue demande aussi de revoir le stockage des données binaires.
Pourquoi une mise à jour doit-elle passer par une recette ?
Une montée de version peut modifier un comportement attendu par un workflow. La recette valide l’accès, les identifiants, les webhooks et les exécutions avant que la production ne subisse le changement.