Installer n8n sur un VPS avec Docker (guide 2026)

n8n tourne très bien sur un petit serveur, à condition de l'installer correctement dès le départ. La version « rapide » que l'on trouve souvent en ligne, un simple conteneur exposé sur le port 5678 avec une base SQLite, fonctionne pour tester mais pose trois problèmes en production : pas de HTTPS, donc des webhooks refusés par de nombreux services ; une base qui supporte mal les écritures simultanées ; et un port ouvert directement sur Internet.

Ce guide met en place une installation propre, celle que nous recommandons à nos clients : n8n, PostgreSQL et le reverse proxy Caddy, orchestrés par Docker Compose, avec un certificat HTTPS renouvelé automatiquement. Comptez une vingtaine de minutes.

1. Ce qu'il vous faut

Un VPS Linux sous Ubuntu 24.04 ou Debian 12, avec un accès root. Pour un usage réel, prévoyez 2 vCPU et 4 Go de RAM au minimum : n8n consomme d'abord de la mémoire, chaque exécution gardant ses données en RAM. Notre article combien de RAM et de vCPU pour un VPS détaille le raisonnement.
Un nom de domaine dont vous gérez la zone DNS, pour y créer un sous-domaine comme n8n.votre-domaine.fr.
Un accès SSH fonctionnel. Si le serveur est neuf, appliquez d'abord les bases de notre guide sécuriser son serveur VPS : utilisateur non root et clés SSH.

Pourquoi PostgreSQL plutôt que SQLite ?

SQLite, la base par défaut de n8n, est un simple fichier. Il convient pour quelques workflows, mais supporte mal les écritures concurrentes quand plusieurs exécutions tournent en même temps, et sa sauvegarde à chaud est délicate. PostgreSQL règle ces deux points et permet plus tard de passer n8n en mode queue avec plusieurs workers.

2. Pointer un sous-domaine vers le serveur

Dans la zone DNS de votre domaine, créez un enregistrement de type A pour n8n qui pointe vers l'adresse IPv4 de votre VPS. Si votre serveur dispose d'une adresse IPv6, ajoutez aussi un enregistrement AAAA. Vérifiez ensuite la résolution depuis votre poste :

dig +short n8n.votre-domaine.fr

La commande doit renvoyer l'IP de votre serveur. N'allez pas plus loin tant que ce n'est pas le cas : au premier démarrage, Caddy demande un certificat à Let's Encrypt, qui vérifie que le domaine pointe bien vers la machine. Si la propagation n'est pas terminée, la demande échoue, et des échecs répétés déclenchent une limite de fréquence qui bloque les tentatives pendant un moment.

3. Installer Docker

Sur nos VPS, Docker peut être installé en un clic au moment de la commande. Sur un serveur déjà livré, le script officiel fait le travail et installe aussi le plugin Compose :

curl -fsSL https://get.docker.com | sh
docker --version
docker compose version

Les deux dernières commandes doivent afficher un numéro de version. Si docker compose est inconnu, vous disposez d'une ancienne installation qui utilise docker-compose avec un tiret : mieux vaut la remplacer par la version actuelle.

4. Configurer le pare-feu

Seuls trois ports doivent être ouverts : SSH, HTTP pour la validation du certificat, et HTTPS.

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Docker contourne UFW

Un port publié par Docker avec la directive ports est ouvert sur Internet même si UFW le bloque, car Docker écrit ses propres règles réseau en amont. C'est la raison pour laquelle, dans la configuration ci-dessous, seul Caddy publie des ports. n8n et PostgreSQL ne sont joignables qu'à l'intérieur du réseau Docker. N'ajoutez jamais ports: 5678:5678 au service n8n.

5. Créer les trois fichiers de configuration

Créez un dossier dédié, par exemple /opt/n8n, et placez-vous dedans. Commencez par les secrets : un mot de passe pour la base et la clé qui chiffre les identifiants enregistrés dans n8n.

mkdir -p /opt/n8n && cd /opt/n8n
echo "POSTGRES_PASSWORD=$(openssl rand -hex 24)" > .env
echo "N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env
chmod 600 .env

Copiez immédiatement la valeur de N8N_ENCRYPTION_KEY dans votre gestionnaire de mots de passe. Si vous la perdez, tous les identifiants enregistrés dans vos workflows deviennent illisibles, même avec une sauvegarde complète de la base.

Créez ensuite le fichier docker-compose.yml :

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s
      retries: 5
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_HOST: n8n.votre-domaine.fr
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.votre-domaine.fr/
      N8N_PROXY_HOPS: 1
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      GENERIC_TIMEZONE: Europe/Paris
      TZ: Europe/Paris
    volumes:
      - n8n_data:/home/node/.n8n
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
volumes:
  pg_data:
  n8n_data:
  caddy_data:

Quelques lignes méritent une explication :

healthcheck et condition: service_healthy : n8n attend que PostgreSQL accepte réellement les connexions avant de démarrer, au lieu de planter au premier lancement.
WEBHOOK_URL : sans elle, n8n affiche des URL de webhook internes du type http://localhost:5678, inutilisables par les services extérieurs.
N8N_PROXY_HOPS: 1 : indique à n8n qu'il se trouve derrière un reverse proxy, pour qu'il lise correctement l'adresse IP réelle des visiteurs.
GENERIC_TIMEZONE : fixe le fuseau utilisé par les déclencheurs planifiés. Sans elle, un workflow prévu « tous les jours à 8 h » s'exécute à 8 h UTC.

Enfin, le fichier Caddyfile, qui tient en trois lignes :

n8n.votre-domaine.fr {
  reverse_proxy n8n:5678
}

Caddy obtient le certificat, redirige HTTP vers HTTPS, renouvelle le certificat avant expiration et gère les WebSockets dont l'éditeur de n8n a besoin, sans aucune configuration supplémentaire.

6. Premier lancement

docker compose up -d
docker compose logs -f n8n

Attendez la ligne indiquant que l'éditeur est accessible, puis quittez l'affichage des journaux avec Ctrl+C, ce qui n'arrête pas les conteneurs. Ouvrez https://n8n.votre-domaine.fr : n8n vous demande de créer le compte propriétaire.

Faites-le tout de suite. Tant que ce compte n'existe pas, la première personne qui ouvre l'adresse peut le créer à votre place. Activez ensuite l'authentification à deux facteurs dans les paramètres du compte, et créez un compte distinct pour chaque personne qui utilisera l'instance.

7. Comprendre les webhooks de test et de production

Le nœud Webhook de n8n affiche deux adresses différentes, source de confusion fréquente :

L'URL de test, qui contient /webhook-test/, ne répond que lorsque vous cliquez sur « écouter un événement de test » dans l'éditeur, et pour un seul appel.
L'URL de production, qui contient /webhook/, ne répond que lorsque le workflow est activé.

Un webhook qui renvoie une erreur 404 alors que tout semble configuré correspond presque toujours à l'une de ces deux situations : le service appelant utilise l'URL de test, ou le workflow n'a pas été activé.

8. Mettre n8n à jour sans mauvaise surprise

n8n publie de nouvelles versions très régulièrement, et certaines modifient le comportement de nœuds existants. Plutôt que de suivre aveuglément la dernière version, adoptez une routine en trois temps :

Lisez les notes de version, en particulier la rubrique des changements incompatibles.
Faites une sauvegarde de la base, avec la commande de la section suivante.
Téléchargez la nouvelle image et redémarrez :

cd /opt/n8n
docker compose pull
docker compose up -d
docker image prune -f

Pour un environnement critique, remplacez l'image docker.n8n.io/n8nio/n8n par une version précise, par exemple docker.n8n.io/n8nio/n8n:1.x.y avec le numéro réel. Vous décidez alors du moment où vous changez de version, au lieu de la subir lors d'un redémarrage.

9. Sauvegarder l'instance

Deux éléments suffisent à reconstruire entièrement votre instance : la base PostgreSQL, qui contient workflows, identifiants chiffrés et historique, et le fichier .env qui contient la clé de chiffrement. Automatisez un export quotidien de la base :

mkdir -p /root/backups
crontab -e

Puis ajoutez cette ligne, qui exporte la base chaque nuit à 3 h et supprime les exports de plus de 14 jours :

0 3 * * * cd /opt/n8n && docker compose exec -T postgres pg_dump -U n8n n8n | gzip > /root/backups/n8n-$(date +\%F).sql.gz && find /root/backups -name 'n8n-*.sql.gz' -mtime +14 -delete

Une sauvegarde stockée sur le même serveur ne protège ni d'une erreur de manipulation sur la machine, ni d'une compromission. Envoyez ces fichiers ailleurs : notre documentation sauvegardes VPS avec Borg explique comment les chiffrer et les exporter automatiquement. Et testez au moins une fois la restauration : c'est la seule façon de savoir qu'une sauvegarde fonctionne.

10. Les problèmes les plus fréquents

Le certificat HTTPS n'est pas émis

Consultez docker compose logs caddy. Dans l'immense majorité des cas, le sous-domaine ne pointe pas encore vers le serveur, ou le port 80 est fermé : Let's Encrypt en a besoin pour valider le domaine.

L'éditeur affiche « Connection lost »

L'éditeur communique en temps réel avec le serveur. Derrière Caddy, cela fonctionne sans réglage ; le problème apparaît surtout lorsqu'un autre proxy, placé en amont, ne transmet pas les WebSockets. Vérifiez sa configuration.

Des exécutions échouent sans raison apparente

Lancez docker stats pendant l'exécution d'un workflow lourd. Si la mémoire du conteneur n8n atteint le plafond du serveur, le processus est tué. Deux solutions : traiter les données par lots avec le nœud de découpage, ou passer à une offre avec plus de RAM.

La base de données grossit sans cesse

n8n conserve l'historique des exécutions. Limitez sa durée de conservation en ajoutant par exemple EXECUTIONS_DATA_MAX_AGE: 168 dans les variables d'environnement du service n8n : l'historique est alors purgé au-delà de sept jours.

Récapitulatif

Sous-domaine pointé · Docker installé · pare-feu limité à 22, 80 et 443 · n8n, PostgreSQL et Caddy en Compose · clé de chiffrement sauvegardée · compte propriétaire créé avec 2FA · export quotidien de la base envoyé hors du serveur.

Avec cette base, votre instance est prête pour la production. Si vous hésitez encore entre héberger n8n vous-même et utiliser la version cloud, notre comparatif n8n Cloud ou auto-hébergé : combien ça coûte vraiment chiffre les deux options. Et pour ajouter un modèle d'IA local à vos workflows, lisez notre guide Ollama sur un VPS sans GPU.

Questions fréquentes

Quelle configuration minimale pour installer n8n sur un VPS ?

Pour tester, 2 vCPU et 2 Go de RAM suffisent. Pour la production avec PostgreSQL, prévoyez au moins 2 vCPU et 4 Go de RAM, et 8 Go si vos workflows traitent des fichiers ou appellent des modèles d'IA.

Faut-il obligatoirement un nom de domaine pour n8n ?

Pour une instance utilisée en production, oui. Le HTTPS nécessite un certificat, lui-même lié à un nom de domaine, et de nombreux services refusent d'envoyer des webhooks vers une adresse non chiffrée.

Pourquoi mon webhook n8n renvoie-t-il une erreur 404 ?

Soit le service appelant utilise l'URL de test, qui ne fonctionne que pendant une écoute lancée depuis l'éditeur, soit le workflow n'est pas activé, ce qui est indispensable pour que l'URL de production réponde.

Que se passe-t-il si je perds la clé N8N_ENCRYPTION_KEY ?

Les identifiants enregistrés dans n8n, comme les clés d'API et les mots de passe, deviennent illisibles, même si la base de données est intacte. Il faudra les ressaisir un par un. Conservez cette clé dans un gestionnaire de mots de passe.

Installer n8n sur un VPS avec Docker, HTTPS et PostgreSQL