Installer n8n avec Docker : le guide complet (compose, Postgres, production)

Trois façons d'installer n8n en self-hosted circulent dans la documentation et les forums : npm directement sur la machine, Docker, ou un chart Kubernetes pour les gros déploiements. Pour une instance unique sur un VPS — le cas de l'immense majorité des installations — Docker est la voie recommandée, et c'est aussi la plus simple à maintenir dans la durée. Ce guide déroule l'installation complète : prérequis, docker-compose.yml commenté avec PostgreSQL, premier démarrage, et la checklist qui sépare un « ça tourne sur mon serveur » d'une instance réellement prête pour la production. Si vous hésitez encore entre héberger vous-même et prendre un abonnement, notre comparatif self-hosted vs n8n Cloud pose le choix en amont.

Pourquoi Docker est la méthode recommandée

Installer n8n via npm fonctionne, mais lie l'application à la version de Node.js du système, à ses bibliothèques, et à tout ce qui traîne sur la machine. À la première mise à jour du système ou de Node, l'installation peut casser pour des raisons qui n'ont rien à voir avec n8n. Docker élimine cette classe de problèmes : l'image officielle embarque exactement la version de Node.js et les dépendances testées par l'équipe n8n, et l'environnement est identique sur votre VPS, sur votre machine locale et sur celle de la documentation.

Ce n'est pas un argument marketing mais un principe d'ingénierie documenté depuis les débuts de Docker : l'article fondateur de Dirk Merkel, Docker: lightweight Linux containers for consistent development and deployment (Linux Journal, 2014 — voir sur Google Scholar), présentait précisément le conteneur comme la réponse au « ça marchait sur ma machine ». Et côté performances, l'étude de Felter, Ferreira, Rajamony et Rubio publiée à IEEE ISPASS 2015 (Google Scholar) a mesuré que les conteneurs Linux affichent un surcoût égal ou inférieur à celui des machines virtuelles, proche des performances natives dans la plupart des cas : l'isolation ne se paie pas en réactivité des workflows.

Bénéfices concrets pour n8n au quotidien :

• Mises à jour maîtrisées : changer un numéro de version dans un fichier, docker compose up -d, et revenir en arrière est possible tant qu'on a sauvegardé la base.
• Stack complète en un fichier : n8n + PostgreSQL (+ plus tard Redis pour le mode queue) décrits dans un seul docker-compose.yml versionnable dans Git.
• Isolation : n8n ne pollue pas le système hôte, et inversement.

Prérequis

Élément	Recommandation
Serveur	VPS Linux (Debian/Ubuntu), 2 Go de RAM comme base confortable, 1 vCPU minimum
Logiciel	Docker Engine + plugin Docker Compose (v2, commande docker compose)
Réseau	Un nom de domaine pointant vers le VPS si les webhooks doivent être joignables depuis Internet

Sur la RAM : n8n démarre avec moins, mais dès qu'un workflow manipule des pièces jointes, parse de gros JSON ou enchaîne des appels à des modèles IA, la marge fond vite. Le coût réel d'un n8n self-hosted — VPS compris — reste très raisonnable, autant ne pas économiser 3 € par mois sur la mémoire.

Installation de Docker sur un VPS Debian/Ubuntu vierge :

# Installe Docker Engine + le plugin compose via le script officiel
curl -fsSL https://get.docker.com | sh

# Vérifie que le plugin compose v2 répond
docker compose version

Si docker compose version renvoie une version, tout est en place. Évitez le vieux binaire docker-compose (avec tiret) encore présent dans certains dépôts : c'est la v1, dépréciée.

Le docker-compose.yml minimal (n8n + PostgreSQL)

Créez un dossier dédié (par exemple /opt/n8n) et placez-y ce fichier docker-compose.yml :

volumes:
  n8n_data:        # données n8n : clé de chiffrement, config, nodes communautaires
  postgres_data:   # données PostgreSQL

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=changez-ce-mot-de-passe
      - POSTGRES_DB=n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      # n8n ne doit démarrer que quand la base accepte les connexions
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 5s
      timeout: 5s
      retries: 10

  n8n:
    # En production, remplacez "latest" par une version précise (voir checklist)
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      # Identité publique de l'instance
      - N8N_HOST=n8n.mondomaine.fr
      - WEBHOOK_URL=https://n8n.mondomaine.fr/
      # Fuseau utilisé par les triggers planifiés (Cron, Schedule)
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
      # Connexion à PostgreSQL au lieu du SQLite par défaut
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=changez-ce-mot-de-passe
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

Trois points méritent une explication :

• WEBHOOK_URL est la variable la plus souvent oubliée. C'est elle qui détermine l'URL affichée (et enregistrée auprès des services tiers) pour vos webhooks. Sans elle, derrière un reverse proxy, n8n génère des URL de webhook injoignables.
• GENERIC_TIMEZONE pilote l'heure des triggers planifiés. Sans elle, un workflow « tous les jours à 8 h » se déclenche à 8 h UTC, pas à 8 h de Paris.
• Le volume n8n_data monté sur /home/node/.n8n contient notamment la clé de chiffrement des credentials, générée au premier démarrage. Perdre ce volume sans en avoir noté la clé rend tous les credentials enregistrés indéchiffrables — le point est détaillé dans notre guide pour sécuriser les credentials API dans n8n.

Pourquoi PostgreSQL plutôt que le SQLite par défaut

Sans les variables DB_*, n8n utilise SQLite : un simple fichier de base de données dans le volume n8n_data. C'est parfait pour découvrir l'outil, et parfaitement insuffisant dès que l'instance devient un maillon de production :

Critère	SQLite (défaut)	PostgreSQL
Mise en route	Zéro configuration	Un service à déclarer dans le compose
Historique d'exécutions volumineux	Le fichier grossit, les performances se dégradent	Conçu pour ce volume d'écritures
Sauvegarde à chaud	Délicate (fichier potentiellement en cours d'écriture)	pg_dump propre et scriptable
Mode queue (workers multiples)	Non supporté	Requis

Le passage SQLite → PostgreSQL après coup implique une migration des données : autant partir directement sur PostgreSQL, le surcoût dans le docker-compose.yml se limite à une quinzaine de lignes. La sauvegarde et la restauration de cette base sont couvertes en détail dans notre guide sauvegarde et restauration PostgreSQL pour n8n self-hosted.

Premier démarrage et création du compte owner

Depuis le dossier contenant le docker-compose.yml :

docker compose up -d        # démarre postgres puis n8n en arrière-plan
docker compose logs -f n8n  # suit les logs jusqu'au message "Editor is now accessible"

Ouvrez ensuite http://IP-du-serveur:5678 (ou votre domaine une fois le proxy en place). Au premier accès, n8n propose de créer le compte owner : l'administrateur principal de l'instance, celui qui gère les utilisateurs et les réglages. Utilisez une adresse email réelle et un mot de passe robuste — cette étape n'arrive qu'une fois, tant que la base est vierge.

Deux vérifications rapides valident l'installation :

# La base utilisée est bien PostgreSQL (aucun fichier database.sqlite ne doit exister)
docker compose exec n8n ls /home/node/.n8n

# Les deux conteneurs sont "running" / "healthy"
docker compose ps

Checklist production

Une instance qui répond sur le port 5678 n'est pas une instance de production. Les quatre chantiers à traiter, dans cet ordre :

1. HTTPS et nom de domaine. Ne laissez pas l'interface et les webhooks en HTTP sur une IP publique : placez un reverse proxy devant n8n pour terminer le TLS avec un certificat Let's Encrypt, et cessez de publier le port 5678 vers l'extérieur. La mise en place complète, avec Traefik ou Caddy et les variables à ajuster (N8N_PROTOCOL, WEBHOOK_URL), est décrite dans notre guide n8n en HTTPS avec un nom de domaine.

2. Sauvegardes. Deux choses à sauvegarder, toujours ensemble : la base PostgreSQL (pg_dump planifié) et le volume n8n_data — ou a minima la clé de chiffrement qu'il contient. Une sauvegarde de la base sans la clé de chiffrement restaure des credentials illisibles. Le guide de sauvegarde/restauration fournit les scripts et la procédure de test de restauration.

3. Mises à jour épinglées. Remplacez latest par une version précise (docker.n8n.io/n8nio/n8n:1.x.y, à relever sur les releases officielles) dès que l'instance porte des workflows réels. Avec latest, un simple docker compose pull un mauvais jour peut sauter plusieurs versions majeures d'un coup, migrations de base comprises. La bonne procédure — sauvegarde, lecture des notes de version, montée incrémentale — est détaillée dans mettre à jour n8n sous Docker sans rien casser.

4. Monitoring. restart: unless-stopped relance n8n s'il crashe, mais ne vous prévient pas qu'il a crashé, ni que le disque se remplit ou que les exécutions échouent en série. Un healthcheck externe sur /healthz et quelques alertes de base sont couverts dans notre guide pour superviser une instance n8n.

Et ensuite ?

L'instance tourne, en HTTPS, sauvegardée, épinglée sur une version connue : reste à la remplir. Vous pouvez construire vos premiers workflows à la main — notre guide pour débuter avec les nodes IA de n8n est un bon point d'entrée — ou importer des workflows prêts à l'emploi : le Pack Inbox IA (79 €) fournit par exemple un tri et des brouillons de réponse automatiques pour votre boîte mail, importables en quelques minutes sur une instance fraîchement installée. C'est souvent la meilleure façon de rentabiliser le self-hosted dès la première semaine : l'infrastructure décrite dans ce guide est exactement celle qu'il faut pour les faire tourner.