n8n Self-Hosted : guide complet d’installation, de sécurité et de mise en production

n8n self-hosted est la Community Edition gratuite avec des exécutions illimitées, hébergée sur votre propre infrastructure. Docker Compose avec PostgreSQL est la méthode recommandée. Un VPS à 5-10 €/mois suffit pour la majorité des déploiements. Le mode queue (Redis + workers) permet de scaler horizontalement pour les gros volumes.

Licence: Sustainable Use License (fair-code), gratuit pour usage interne
Installation: Docker (recommandé), Docker Compose, npm, Kubernetes
Base de données: SQLite (dev/test) ou PostgreSQL (production recommandé)
Exécutions: Illimitées (pas de plafond)
Coût minimum: ~5-10 €/mois (VPS basique)
Scaling: Queue mode avec Redis + workers (horizontal scaling)
Prérequis: Docker, un domaine/sous-domaine, des compétences serveur de base

Pourquoi choisir le self-hosted ?

Trois raisons principales poussent les équipes techniques vers le self-hosting de n8n plutôt que les plans cloud.

Exécutions illimitées à coût fixe. Là où le plan cloud Pro facture 60 €/mois pour 10 000 exécutions, le self-hosted n’a aucune limite. Un workflow qui tourne 150 000 fois par mois coûte la même chose qu’un workflow qui tourne 100 fois : le prix de votre serveur. Les entreprises migrant depuis Zapier ou Make rapportent des économies de 70 à 90 % sur leur facture d’automatisation.

Souveraineté des données. Vos workflows, vos credentials (clés API, tokens OAuth), et vos données d’exécution restent sur votre infrastructure. Rien ne transite par les serveurs de n8n. C’est un prérequis pour les entreprises soumises au RGPD strict, à HIPAA, ou opérant dans des secteurs réglementés (finance, santé, défense).

Contrôle total. Vous choisissez la version de n8n, le moment des mises à jour, la configuration du serveur, les ressources allouées, et les politiques de sécurité. Vous pouvez installer des nodes communautaires, des paquets npm supplémentaires, et personnaliser l’environnement d’exécution.

Le self-hosted n’est pas pour tout le monde n8n recommande officiellement le self-hosting aux utilisateurs expérimentés. Les erreurs de configuration peuvent entraîner des pertes de données, des failles de sécurité, ou des interruptions de service. Si vous n’êtes pas à l’aise avec Docker, la ligne de commande Linux, et la gestion de serveur, le cloud n8n est un meilleur choix.

Prérequis techniques

Avant de commencer l’installation, vérifiez que vous disposez de ces éléments.

Un serveur : VPS (recommandé), serveur dédié, Raspberry Pi 4/5, ou instance cloud (AWS, GCP, Azure, DigitalOcean, Contabo, Hetzner). Minimum recommandé pour la production : 2 vCPU, 2 Go RAM, 20 Go SSD. Pour les volumes plus importants : 4 vCPU, 4-8 Go RAM.

Un OS Linux : Ubuntu 24.04 LTS est le choix le plus courant et le mieux documenté. Debian, CentOS, et d’autres distributions fonctionnent aussi.

Docker et Docker Compose : Docker gère les conteneurs. Docker Compose permet de définir l’ensemble du stack (n8n + base de données + reverse proxy) dans un seul fichier YAML.

Un domaine ou sous-domaine : Nécessaire pour le SSL (HTTPS) et pour que les webhooks fonctionnent correctement. Créez un enregistrement DNS de type A pointant vers l’IP de votre serveur (par exemple n8n.votredomaine.com).

Accès SSH : Pour vous connecter à votre serveur et exécuter les commandes d’installation.

Installation avec Docker Compose (méthode recommandée)

Docker Compose est la méthode officiellement recommandée par n8n. Elle isole n8n et sa base de données dans des conteneurs, simplifie les mises à jour, et gère automatiquement les dépendances.

Étape 1 : installer Docker

Connectez-vous en SSH à votre serveur. Mettez à jour les paquets système, puis installez Docker et Docker Compose. Sur Ubuntu, la commande rapide est :

sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

Déconnectez-vous et reconnectez-vous pour que le groupe Docker soit reconnu. Vérifiez l’installation :

docker --version
docker compose version

Étape 2 : créer le répertoire de projet

mkdir -p ~/n8n && cd ~/n8n

Étape 3 : créer le fichier .env

Ce fichier contient les variables d’environnement sensibles. Remplacez les valeurs entre chevrons par vos propres paramètres.

# .env
POSTGRES_USER=n8n
POSTGRES_PASSWORD=<mot_de_passe_securise>
POSTGRES_DB=n8n

N8N_ENCRYPTION_KEY=<cle_aleatoire_longue>
N8N_HOST=n8n.votredomaine.com
N8N_PORT=5678
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.votredomaine.com/

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=<mot_de_passe_securise>

N8N_ENCRYPTION_KEY est critique Cette clé chiffre toutes vos credentials (clés API, tokens OAuth, mots de passe) stockées en base de données. Si vous la perdez, toutes vos credentials deviennent illisibles et vous devrez les reconfigurer manuellement. Générez une clé aléatoire forte, notez-la dans un gestionnaire de mots de passe, et ne la changez jamais une fois en production.

Étape 4 : créer le fichier docker-compose.yml

Ce fichier définit les services n8n, PostgreSQL, et Traefik (reverse proxy avec SSL automatique). Le repo officiel n8n-hosting sur GitHub contient des configurations Docker Compose pour différentes architectures.

version: "3.9"
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    env_file: .env
    ports:
      - "5678:5678"
    depends_on:
      - postgres
    volumes:
      - n8n_data:/home/node/.n8n
      - ./local-files:/files

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - pg_data:/var/lib/postgresql/data

volumes:
  n8n_data:
  pg_data:

Cette configuration de base ne contient pas de reverse proxy. Pour la production, ajoutez Traefik ou Nginx devant n8n pour gérer le SSL. La documentation officielle de n8n fournit des configurations complètes avec Traefik intégré.

Étape 5 : lancer et vérifier

docker compose up -d
docker compose ps
docker compose logs -f n8n

Vérifiez que les deux conteneurs (n8n et postgres) sont en status « Up ». Ouvrez https://n8n.votredomaine.com dans votre navigateur (ou http://IP_DU_SERVEUR:5678 en développement). L’assistant de configuration vous demande de créer un compte administrateur. Renseignez nom, email et mot de passe. Votre instance n8n est opérationnelle.

SSL et reverse proxy

En production, n8n doit être accessible en HTTPS. C’est indispensable pour la sécurité des données et pour que les webhooks fonctionnent (la plupart des services refusent d’envoyer des webhooks vers des URLs HTTP non sécurisées).

Deux options principales. Traefik est le reverse proxy recommandé par n8n : il gère automatiquement les certificats SSL via Let’s Encrypt. Les configurations Docker Compose avec Traefik sont fournies dans le repo officiel n8n-hosting. Nginx est l’alternative classique : installez-le sur le VPS, configurez un server block pour votre domaine, et utilisez Certbot pour les certificats Let’s Encrypt.

Dans les deux cas, le résultat est le même : les requêtes HTTPS arrivent sur le reverse proxy, qui les transmet au conteneur n8n sur le port 5678. Le reverse proxy gère le renouvellement automatique des certificats SSL.

Pourquoi PostgreSQL et pas SQLite ?

n8n utilise SQLite par défaut pour stocker les credentials, les workflows et l’historique des exécutions. C’est suffisant pour le développement local et les tests. En production, PostgreSQL est fortement recommandé pour plusieurs raisons.

SQLite stocke tout dans un seul fichier. Avec des volumes d’exécution élevés et des accès concurrents (plusieurs workflows qui tournent en parallèle), SQLite devient un goulet d’étranglement : verrouillages, lenteurs dans l’éditeur, et risque de corruption. PostgreSQL gère les accès concurrents nativement, supporte des volumes de données beaucoup plus importants, et offre une meilleure récupération après crash.

De plus, le mode queue (scaling avec Redis) nécessite PostgreSQL. SQLite ne supporte pas les architectures distribuées.

Seuil de migration Si vos workflows dépassent 100 exécutions par jour, migrez vers PostgreSQL. La migration se fait via les commandes CLI d’export/import de n8n : exportez vos workflows et credentials en JSON depuis l’instance SQLite, puis importez-les dans la nouvelle instance PostgreSQL.

Sécuriser votre instance

Authentification

n8n intègre un système de gestion d’utilisateurs (pas un simple Basic Auth). Lors du premier lancement, vous créez un compte propriétaire. Vous pouvez ensuite inviter d’autres utilisateurs avec des rôles (Admin, Editor, Viewer). Activez le 2FA (authentification à deux facteurs) dans les paramètres de compte pour une couche de sécurité supplémentaire.

Réseau et firewall

Ne jamais exposer le port 5678 directement sur Internet sans reverse proxy SSL. Configurez votre firewall (UFW sur Ubuntu) pour n’autoriser que les ports 22 (SSH), 80 (HTTP, redirection vers HTTPS), et 443 (HTTPS). Bloquez tout le reste. Si possible, restreignez l’accès SSH par clé (désactivez l’authentification par mot de passe).

Protection des credentials

n8n chiffre toutes les credentials en base de données avec la N8N_ENCRYPTION_KEY. Ne stockez jamais de clé API en clair dans un node Code ou dans une URL. Utilisez exclusivement le système de credentials n8n. Pour les informations sensibles dans les variables d’environnement Docker, utilisez le suffixe _FILE pour charger les valeurs depuis des fichiers Docker Secrets au lieu de les mettre en clair dans le .env.

Mises à jour

n8n publie une nouvelle version mineure la plupart des semaines. Avant de mettre à jour, exportez vos workflows comme backup :

# Backup avant mise à jour
docker compose exec n8n n8n export:workflow --all 
  --output=/home/node/.n8n/backup.json

# Mise à jour
docker compose pull n8n
docker compose up -d --no-deps n8n

n8n exécute automatiquement les migrations de base de données au démarrage. Consultez toujours le changelog avant de mettre à jour pour vérifier les breaking changes potentiels.

Queue mode : scaler pour les gros volumes

Quand votre instance n8n commence à ralentir sous la charge (éditeur lent, exécutions en file d’attente, webhooks qui timeout), il est temps de passer en mode queue.

Architecture du mode queue

Le mode queue sépare n8n en trois types de processus :

Le processus principal (editor) : Gère l’interface utilisateur, l’API, le scheduling, et reçoit les webhooks. Il ne exécute pas les workflows. À la place, il pousse les jobs dans une file Redis.

Redis : Le message broker. Il stocke temporairement les jobs en attente d’exécution. Chaque workflow en attente est un message dans la file Redis.

Les workers : Un ou plusieurs processus n8n qui récupèrent les jobs depuis Redis, exécutent les workflows, écrivent les résultats dans PostgreSQL, et signalent à Redis que l’exécution est terminée.

Cette architecture permet de scaler horizontalement : ajoutez des workers pour traiter plus de workflows en parallèle, sans impacter la réactivité de l’éditeur. Le processus principal reste léger et réactif même quand des dizaines de workflows lourds tournent simultanément.

Configuration Docker Compose

Ajoutez Redis et un service worker à votre docker-compose.yml existant. Les variables d’environnement clés :

# Ajouter au .env
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
QUEUE_HEALTH_CHECK_ACTIVE=true

Le service worker se configure comme une copie du service n8n mais avec la commande worker :

  worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    env_file: .env
    command: worker
    depends_on:
      - redis
      - postgres
    volumes:
      - n8n_data:/home/node/.n8n

  redis:
    image: redis:7-alpine
    restart: unless-stopped

Pour ajouter des workers supplémentaires, utilisez l’option scale de Docker Compose :

docker compose up -d --scale worker=3

Commencez avec 1-2 workers et ajoutez-en selon la charge observée. Pour la plupart des déploiements, 2-3 workers sur un VPS standard suffisent.

Webhook processors (optionnel)

Pour les scénarios à très haut volume de webhooks entrants, n8n permet de configurer des processus webhook dédiés. Ces processus ne font que recevoir les requêtes HTTP entrantes et les pousser vers Redis, laissant les workers gérer l’exécution. Placez un load balancer devant plusieurs webhook processors pour une scalabilité maximale. C’est un pattern avancé, utile uniquement au-delà de milliers de webhooks par heure.

Multi-main (Enterprise) Le plan Enterprise self-hosted supporte le multi-main : plusieurs instances principales pour la haute disponibilité. Un système d’élection de leader basé sur Redis désigne automatiquement un leader parmi les instances. Si le leader tombe, un follower prend le relais. C’est la configuration recommandée pour les déploiements critiques en production.

Sauvegardes : ne perdez jamais vos workflows

Trois éléments critiques à sauvegarder :

La base de données PostgreSQL : Elle contient vos workflows, credentials (chiffrées), et l’historique des exécutions. Planifiez un pg_dump quotidien vers un stockage externe (S3, Google Cloud Storage, ou un autre serveur).

Le volume Docker n8n_data : Contient la configuration n8n et la clé de chiffrement (si elle n’est pas définie via variable d’environnement). Sauvegardez ce volume régulièrement.

Le fichier .env : Contient vos variables d’environnement, y compris la N8N_ENCRYPTION_KEY. Stockez-le dans un gestionnaire de secrets ou un coffre-fort numérique.

# Backup automatique quotidien (exemple cron)
# Ajouter au crontab : crontab -e
0 3 * * * docker compose -f ~/n8n/docker-compose.yml exec -T postgres 
  pg_dump -U n8n n8n | gzip > ~/backups/n8n_$(date +%Y%m%d).sql.gz

Testez régulièrement la restauration de vos backups. Un backup non testé n’est pas un backup.

Self-hosted AI Starter Kit

n8n propose un kit de démarrage IA auto-hébergé (self-hosted-ai-starter-kit) sur GitHub (14 000+ stars). Ce template Docker Compose combine n8n avec des outils IA compatibles : Ollama pour les modèles locaux, Qdrant pour le stockage vectoriel, et les composants nécessaires pour construire des pipelines RAG entièrement en local.

C’est le moyen le plus rapide de déployer un environnement d’automatisation IA complet sans qu’aucune donnée ne quitte votre serveur. Idéal pour les entreprises qui veulent expérimenter avec des agents IA autonomes tout en maintenant une confidentialité totale des données.

Monitoring en production

Une instance n8n en production nécessite un monitoring actif. Voici les métriques à surveiller.

Santé des conteneurs : docker compose ps pour vérifier le statut. Configurez un health check dans votre Docker Compose. Le endpoint /healthz de n8n retourne le statut de l’instance. En mode queue, /healthz/readiness vérifie les connexions DB et Redis.

Ressources serveur : docker stats pour CPU et RAM en temps réel. Alertez quand la RAM dépasse 80 % ou le CPU 90 %. Un workflow mal conçu peut consommer des ressources excessives.

Exécutions : L’onglet Executions de n8n montre l’historique des runs (succès/échecs). Configurez un workflow d’erreur global qui envoie une alerte Slack ou email à chaque échec. Sur le plan Business self-hosted, activez le log streaming vers Datadog ou ELK Stack pour un monitoring avancé.

Base de données : Surveillez la taille de la table d’exécutions PostgreSQL. Configurez le pruning (purge automatique) des anciennes exécutions pour éviter que la base ne grossisse indéfiniment. Les variables d’environnement EXECUTIONS_DATA_PRUNE et EXECUTIONS_DATA_MAX_AGE contrôlent cette purge.

Quand passer du cloud au self-hosted (et inversement)

La migration du cloud vers le self-hosted (ou l’inverse) est simple : exportez vos workflows en JSON depuis l’ancienne instance, importez-les dans la nouvelle. Les credentials doivent être reconfigurées manuellement (elles ne sont pas transférables entre instances pour des raisons de sécurité). L’historique des exécutions ne migre pas, mais les workflows actifs reprennent dès activation.

Passez du cloud au self-hosted quand : votre facture cloud dépasse 100-200 €/mois, vous avez les compétences techniques pour gérer un serveur, ou la souveraineté des données devient un prérequis.

Passez du self-hosted au cloud quand : le temps de maintenance serveur dépasse la valeur des économies réalisées, ou que vous perdez votre DevOps et que personne ne peut maintenir l’infrastructure.

Questions fréquentes

Peut-on installer n8n self-hosted sur un Raspberry Pi ?

Oui. Le Raspberry Pi 4 (4 Go RAM) et le Pi 5 sont des plateformes viables pour un usage personnel ou une petite équipe. L’installation par npm est recommandée sur Pi (plus légère que Docker). Vous devez installer Node.js v20.19 ou supérieur manuellement, car les repos par défaut de Raspberry Pi OS fournissent des versions plus anciennes. Pour quelques workflows légers, un Pi est suffisant et ultra-économique. Pour un usage intensif, préférez un VPS.

Le self-hosted est-il vraiment gratuit ? Quel est le coût total réel ?

La licence n8n Community Edition est gratuite. Le coût total inclut l’infrastructure (VPS 5-20 €/mois pour un usage standard), le temps de maintenance (mises à jour, sauvegardes, monitoring, environ 1-2 heures par mois si tout va bien), et les éventuels coûts d’APIs externes (OpenAI, Anthropic, etc., facturés séparément). Pour une PME sans DevOps dédié, comptez 20-50 €/mois tout compris pour un déploiement standard. C’est significativement moins cher que le cloud pour les volumes supérieurs à 5 000 exécutions/mois.

Comment mettre à jour n8n self-hosted sans perdre mes données ?

Exportez d’abord vos workflows comme backup (docker compose exec n8n n8n export:workflow --all). Puis tirez la dernière image Docker (docker compose pull n8n) et relancez le conteneur (docker compose up -d --no-deps n8n). Les migrations de base de données sont automatiques au démarrage. Consultez toujours le changelog n8n avant la mise à jour pour vérifier les éventuels breaking changes. Si un problème survient, vous pouvez revenir à la version précédente en spécifiant le tag d’image dans votre docker-compose.yml.

Faut-il utiliser le mode queue dès le départ ?

Non. Pour un déploiement avec moins de quelques centaines d’exécutions par jour, le mode single-node (par défaut) est suffisant et plus simple à maintenir. Le mode queue ajoute de la complexité (Redis, workers, configuration supplémentaire). Passez en mode queue quand vous observez des symptômes concrets : éditeur lent pendant les exécutions, webhooks qui timeout, workflows qui s’accumulent en file d’attente. En règle générale, au-delà de 1 000 exécutions par jour ou si vous avez des workflows lourds (IA, manipulation de fichiers volumineux), le mode queue améliore sensiblement les performances.

La clé de licence Business fonctionne-t-elle en self-hosted ?

Oui. Le plan Business (800 €/mois) est disponible en self-hosted. Vous recevez une clé de licence qui débloque les fonctionnalités Business (SSO SAML, intégration Git native, multi-environnement, log streaming) sur votre propre infrastructure. La clé doit contacter le serveur de licences n8n quotidiennement pour rester active. Vous pouvez appliquer la même clé sur un nombre illimité d’instances. L’usage combiné de toutes les instances compte pour votre quota de 40 000 exécutions.