Pourquoi auto-héberger n8n
n8n propose une offre cloud clé en main. Elle est pratique, mais l’auto-hébergement présente des avantages décisifs dès qu’on automatise sérieusement :
- Coût fixe : un serveur, quel que soit le nombre d’exécutions.
- Données maîtrisées : tout reste sur votre serveur, en France ou en Europe.
- Aucune limite de workflows actifs, d’exécutions ou d’historique imposée par une offre.
- Accès aux services internes : n8n peut appeler votre application sur le même serveur ou le même réseau privé.
- Nœuds communautaires installables librement.
La contrepartie : vous êtes responsable de la sécurité, des sauvegardes et des mises à jour. Ce guide couvre ces trois sujets.
L’architecture cible
Voici l’architecture que j’utilise en production, éprouvée sur plus d’une trentaine de workflows :
- Un VPS Linux (Debian ou Ubuntu LTS), 2 vCPU et 4 Go de RAM suffisent pour démarrer confortablement.
- Docker et Docker Compose pour faire tourner n8n et sa base de données dans des conteneurs isolés.
- PostgreSQL comme base de données de n8n, plutôt que SQLite par défaut, pour la robustesse et les sauvegardes.
- Nginx en reverse proxy devant n8n, qui gère le HTTPS et transmet les requêtes au conteneur.
- Certbot (Let’s Encrypt) pour des certificats HTTPS gratuits renouvelés automatiquement.
- Un pare-feu qui n’ouvre que les ports nécessaires (SSH, HTTP, HTTPS).
- Des sauvegardes automatiques de la base et des workflows, copiées hors du serveur.
Cette base peut accueillir d’autres services à côté, par exemple un moteur de recherche auto-hébergé SearXNG utilisé par les workflows, comme c’est le cas pour EvoRating.
Étape 1 : préparer et sécuriser le serveur
- Mettre à jour le système dès la première connexion, puis activer les mises à jour de sécurité automatiques (unattended-upgrades sur Debian et Ubuntu).
- Créer un utilisateur non root avec les droits sudo, et se connecter avec une clé SSH.
- Durcir SSH : désactiver la connexion root et l’authentification par mot de passe.
- Activer un pare-feu (ufw) : autoriser SSH, 80 et 443, refuser le reste.
- Installer fail2ban pour bloquer les tentatives de connexion répétées.
- Installer Docker depuis le dépôt officiel, avec le plugin Docker Compose.
- Pointer un sous-domaine (par exemple n8n.votredomaine.fr) vers l’adresse IP du serveur, via un enregistrement DNS de type A.
Étape 2 : le fichier Docker Compose
Dans un dossier dédié (par exemple /opt/n8n), un fichier docker-compose.yml décrit deux services :
- postgres : l’image officielle PostgreSQL, avec un volume persistant pour les données, et ses identifiants passés par variables d’environnement.
- n8n : l’image officielle de n8n, avec un volume persistant pour le dossier de données (/home/node/.n8n), dépendant du service postgres, et exposé uniquement en local (127.0.0.1:5678) pour que seul Nginx puisse y accéder.
Les variables d’environnement essentielles de n8n, placées dans un fichier .env à côté du docker-compose.yml (jamais versionné) :
| Variable | Rôle |
|---|---|
| DB_TYPE=postgresdb et DB_POSTGRESDB_* | Connexion à PostgreSQL (hôte, base, utilisateur, mot de passe) |
| N8N_HOST, N8N_PROTOCOL=https | Nom de domaine public de l’instance |
| WEBHOOK_URL | URL publique utilisée pour générer les adresses de webhooks (sinon elles pointent vers localhost) |
| N8N_ENCRYPTION_KEY | Clé de chiffrement des identifiants. À générer une fois, à sauvegarder précieusement : sans elle, les identifiants sauvegardés sont illisibles |
| GENERIC_TIMEZONE et TZ | Fuseau horaire, indispensable pour les déclencheurs planifiés (Europe/Paris) |
| N8N_PROXY_HOPS=1 | Indique à n8n qu’il est derrière un reverse proxy |
| EXECUTIONS_DATA_PRUNE et EXECUTIONS_DATA_MAX_AGE | Purge automatique de l’historique des exécutions pour éviter que la base n’enfle |
Vos propres variables (clés d’API, URL de votre application) peuvent aussi être déclarées ici et lues dans les workflows, à condition d’autoriser leur accès dans la configuration de n8n. Pour les secrets d’API, préférez les identifiants (credentials) chiffrés de n8n.
Étape 3 : Nginx et HTTPS
Nginx reçoit les requêtes sur le sous-domaine et les transmet à n8n. Les points d’attention dans la configuration :
- proxy_pass vers http://127.0.0.1:5678 ;
- transmission des en-têtes Host, X-Forwarded-For et X-Forwarded-Proto ;
- prise en charge des WebSockets (en-têtes Upgrade et Connection), nécessaires à l’éditeur de n8n ;
- désactivation du buffering pour les réponses en flux ;
- taille maximale des requêtes augmentée si vos webhooks reçoivent des fichiers ;
- délais de lecture allongés pour les workflows longs déclenchés par webhook.
Certbot, avec son extension Nginx, obtient le certificat et configure automatiquement la redirection HTTP vers HTTPS. Le renouvellement est ensuite automatique.
Étape 4 : démarrage et premier compte
Un docker compose up -d démarre les deux conteneurs. À la première visite de l’URL, n8n demande de créer le compte propriétaire. Choisissez un mot de passe fort et activez l’authentification à deux facteurs si votre version le propose.
Vérifications à faire tout de suite :
- créer un workflow de test avec un déclencheur Webhook, et vérifier que l’URL affichée commence bien par https://votre-sous-domaine ;
- créer un workflow planifié qui s’exécute dans deux minutes, pour vérifier le fuseau horaire ;
- redémarrer le serveur et vérifier que n8n revient tout seul (option restart: unless-stopped dans le docker-compose).
Étape 5 : sauvegardes
Trois choses à sauvegarder, chaque jour, avec une copie hors du serveur :
- La base PostgreSQL, via un pg_dump planifié.
- Les workflows et identifiants, via les commandes d’export de n8n (n8n export:workflow et n8n export:credentials), utiles pour restaurer ou migrer.
- Le fichier .env et la clé de chiffrement, stockés en lieu sûr (gestionnaire de mots de passe).
Je recommande aussi de versionner les workflows exportés en JSON dans un dépôt Git. On garde l’historique de chaque modification, et on peut redéployer sur un nouveau serveur avec n8n import:workflow. Testez la restauration au moins une fois : une sauvegarde jamais testée n’est pas une sauvegarde.
Étape 6 : mises à jour et supervision
Mettre à jour n8n
n8n publie des versions fréquemment. La procédure : sauvegarde, lecture des notes de version (changements cassants), docker compose pull, docker compose up -d, vérification des workflows critiques. Évitez de suivre l’étiquette « latest » aveuglément en production : fixez une version et montez-la volontairement.
Superviser
- un workflow d’erreur global dans n8n, qui vous notifie (Telegram, email, Slack) à chaque échec d’exécution ;
- un service de surveillance externe qui vérifie que l’URL de n8n répond, et vous alerte sinon ;
- une surveillance de l’espace disque, souvent rempli par l’historique des exécutions ou les journaux Docker.
Combien coûte une instance n8n auto-hébergée
Le coût direct est faible et prévisible :
- Le serveur : un VPS d’entrée ou de milieu de gamme chez un hébergeur européen, de l’ordre de quelques euros à quelques dizaines d’euros par mois selon les ressources.
- Le nom de domaine : vous utilisez généralement un sous-domaine de votre domaine existant, sans surcoût.
- Le certificat HTTPS : gratuit avec Let’s Encrypt.
- Les sauvegardes externes : un stockage objet ou un second serveur, quelques euros par mois.
- Les appels aux services externes : API d’IA, envoi de SMS, etc., facturés par ces services selon votre usage.
Le vrai coût est le temps : installation, sécurisation, mises à jour, supervision. Comptez une demi-journée à une journée pour une installation propre si vous êtes à l’aise avec Linux, puis un peu de temps chaque mois. C’est ce temps que vous économisez en confiant l’hébergement à un prestataire.
Migrer de n8n cloud vers une instance auto-hébergée
- Exporter tous les workflows depuis l’instance cloud (export JSON depuis l’interface ou via l’API publique de n8n).
- Lister les identifiants utilisés : ils ne s’exportent pas en clair d’une instance à l’autre, il faudra les recréer.
- Installer l’instance auto-hébergée selon ce guide, dans une version compatible.
- Importer les workflows, recréer les identifiants et les associer.
- Mettre à jour les URL de webhook chez les services qui appellent vos workflows (formulaires, paiements, outils tiers) : elles changent avec le domaine.
- Tester chaque workflow, en commençant par les plus critiques.
- Désactiver les workflows sur l’ancienne instance, puis résilier l’abonnement cloud.
Prévoyez la bascule à un moment calme, et gardez l’ancienne instance quelques jours en secours.
Monter en charge : le mode file d’attente
Par défaut, n8n exécute tout dans un seul processus. Quand le volume augmente (beaucoup de webhooks simultanés, workflows lourds), le mode file d’attente répartit le travail :
- un processus principal reçoit les déclenchements et gère l’interface ;
- Redis sert de file d’attente des exécutions ;
- un ou plusieurs workers exécutent les workflows en parallèle ;
- éventuellement, des processus dédiés aux webhooks absorbent les pics de requêtes entrantes.
Pour la plupart des TPE et PME, le mode simple suffit largement. Le passage en file d’attente se justifie quand on constate des lenteurs ou des délais d’exécution, et se fait sans changer les workflows.
Bonnes pratiques de production
- Séparer test et production : une instance de test ou au minimum des workflows de test distincts.
- Protéger les webhooks : authentification par en-tête ou par jeton, vérification de signature quand le service émetteur le permet.
- Limiter les accès à l’éditeur : comptes nominatifs, mots de passe forts, et éventuellement restriction par adresse IP.
- Purger l’historique des exécutions pour garder une base légère.
- Documenter chaque workflow : une note en tête qui explique ce qu’il fait, quand, et qui contacter.
- Mode file d’attente (queue mode avec Redis et des workers) quand le volume devient important, pour répartir la charge.