Comment auto-héberger n8n (guide 2026)

L'auto-hébergement de n8n vous offre la plateforme complète d'automatisation de workflows, sans limite d'exécution et avec une propriété totale de vos données. Ce guide détaille honnêtement la configuration réelle de Docker, Docker Compose et PostgreSQL, puis montre le raccourci de 30 secondes si vous préférez éviter entièrement l'administration serveur.

Que signifie « auto-héberger n8n » ?

n8n est une plateforme d'automatisation de workflows à code source disponible. Contrairement à n8n Cloud, le SaaS hébergé par l'équipe n8n, l'auto-hébergement signifie vous faire tourner l'application n8n sur une infrastructure que vous contrôlez. Le logiciel est gratuit sous une licence fair-code, mais le calcul, la base de données, le stockage et la bande passante nécessaires pour le faire tourner 24/7 ne le sont pas. L'auto-hébergement est le bon choix lorsque vous voulez aucune limite d'exécution, un contrôle total sur les identifiants et les données, des workflows illimités, et la possibilité d'utiliser des nœuds communautaires et du code personnalisé sans qu'un palier SaaS ne les verrouille.

Configuration système requise pour n8n

n8n est léger à démarrer, mais il évolue selon la lourdeur de vos workflows. Une base réaliste :

• CPU : 1 vCPU suffit pour un usage léger ; 2 vCPU ou plus pour de nombreuses exécutions simultanées.
• RAM : 1 à 2GB pour n8n. Les workflows qui traitent de gros volumes (fichiers, images, gros JSON) en demandent davantage.
• Base de données : PostgreSQL est fortement recommandé en production. Le SQLite par défaut convient aux tests, mais ne gère pas bien la concurrence et est plus difficile à sauvegarder en toute sécurité.
• Stockage : Quelques GB suffisent pour démarrer ; l'historique d'exécution et les données binaires grossissent avec le temps.
• Réseau : Un point de terminaison HTTPS public (port 443) pour que les webhooks entrants et les rappels OAuth fonctionnent.

Pour une analyse plus détaillée correspondant aux tailles d'offre, consultez notre Guide de configuration requise pour n8n.

Option 1 : déployer n8n avec Docker

La manière la plus rapide de faire tourner n8n sur votre propre machine ou VPS est l'image Docker officielle. C'est parfait pour un essai local, mais notez qu'elle utilise SQLite et n'a pas de TLS : ce n'est pas ce que vous voulez en production :

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Ouvrez http://localhost:5678, créez le compte propriétaire, et vous avez un n8n fonctionnel. Pour un usage réel, passez à Docker Compose avec PostgreSQL.

Option 2 : Docker Compose avec PostgreSQL

Une configuration de production associe n8n à une base PostgreSQL dédiée, une clé de chiffrement et les bons hôte et URL de webhook. Enregistrez ceci sous docker-compose.yml :

services:
  postgres:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: n8n
    volumes:
      - pgdata:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      N8N_ENCRYPTION_KEY: a-long-random-string
    depends_on:
      - postgres
    volumes:
      - n8ndata:/home/node/.n8n

volumes:
  pgdata:
  n8ndata:

Lancez ensuite docker compose up -d. Plusieurs points comptent : définissez une N8N_ENCRYPTION_KEY solide (elle chiffre vos identifiants stockés ; la perdre oblige à ressaisir chaque identifiant), pointez WEBHOOK_URL vers votre vrai domaine HTTPS public, et n'exposez jamais directement le port 5678 à Internet sans reverse proxy devant.

Les aspects que les tutoriels d'auto-hébergement oublient

Faire tourner n8n est la partie facile, soit 20 % du travail. Le maintenir en fonctionnement en toute sécurité représente les 80 % restants, et c'est là qu'un VPS nu vous pénalise :

• Certificats TLS : Vous avez besoin de HTTPS pour les webhooks et OAuth. Cela suppose Caddy, Traefik ou Nginx plus Let's Encrypt, et un renouvellement des certificats qui ne doit jamais échouer.
• Webhooks et reverse proxy : Les webhooks entrants exigent une URL publique stable et des en-têtes de proxy corrects, faute de quoi les déclencheurs cassent silencieusement.
• Sauvegardes : Vos workflows, identifiants et historique d'exécution vivent dans PostgreSQL. Il vous faut des sauvegardes de base de données automatisées et testées : une sauvegarde non testée n'en est pas une.
• Mises à jour : n8n publie des versions fréquentes. Vous êtes responsable de récupérer les nouvelles images, de lire les notes de rupture de compatibilité et de migrer la base de données.
• Disponibilité : Un VPS unique est un point de défaillance unique. Si l'hôte redémarre à 2 h du matin, vos workflows planifiés et vos webhooks s'arrêtent jusqu'à ce que vous le remarquiez.

Questions fréquentes