Auto-héberger n8n sur un VPS.
Votre moteur d'automatisation, vos identifiants, votre métal.

n8n est un moteur d'automatisation de workflows : un canevas visuel où vous câblez un déclencheur — un webhook, une planification, une nouvelle ligne dans une base de données, un message dans une file — vers une chaîne de nœuds qui appellent des API, transforment des données, se ramifient selon des conditions, exécutent du JavaScript ou du Python arbitraire, et transmettent le résultat à ce qui vient ensuite. Plusieurs centaines de nœuds d'intégration sont fournis d'origine, plus un nœud générique HTTP Request qui couvre tout le reste. Depuis la lignée 1.x, il porte aussi des nœuds AI Agent et LLM, ce qui explique pourquoi une large part des personnes qui l'installent en 2026 construisent des agents plutôt que de la plomberie ETL classique.

La partie qui compte avant de taper la moindre commande, c'est la licence, car n8n n'est pas open source au sens OSI, et la différence n'a rien d'académique. Le cœur est distribué sous la Sustainable Use License : une concession mondiale, non exclusive et sans redevance, pour utiliser, copier, modifier et distribuer le logiciel à des fins internes à une activité et pour un usage personnel ou non commercial. Ce qu'elle retient, c'est le droit de facturer autrui pour n8n ou pour un dérivé — la clause qui exclut de bâtir dessus un produit « n8n managé » payant. Séparément, tout fichier portant .ee. dans son nom ou .ee dans son chemin est entièrement exclu de cette licence et nécessite une n8n Enterprise License payante.

En clair : faire tourner n8n sur un VPS pour automatiser sa propre entreprise, le travail de ses propres clients livré comme un service qu'on rend, ou sa propre vie personnelle, relève de la concession gratuite et en a toujours relevé. Vendre du n8n-en-tant-que-produit-d'hébergement, non. Presque toute discussion sur internet du type « n8n est-il vraiment gratuit ? » est un dialogue de sourds entre deux personnes de part et d'autre de cette ligne.

Le côté coût. n8n Cloud est facturé à l'exécution : le plan Starter coûte €20 par mois facturé annuellement pour 2 500 exécutions, Pro est à €50 par mois pour 10 000, Business à €667 par mois pour 40 000. En auto-hébergement, le nombre d'exécutions n'est pas du tout une ligne budgétaire — il est borné par la quantité de CPU et de mémoire dont dispose la machine. Un workflow qui interroge une API toutes les cinq minutes brûle à lui seul 8 640 exécutions par mois ; sur Cloud, ce seul workflow force déjà le palier Pro, et sur un VPS à $3.90 c'est une erreur d'arrondi face au CPU au repos.

Tarifs Cloud tels que publiés sur n8n.io en août 2026, facturation annuelle ; la facturation mensuelle coûte plus cher. L'arbitrage ne se joue pas qu'en argent — l'auto-hébergement fait basculer les mises à jour, les sauvegardes, le renouvellement TLS et la disponibilité de votre côté de la ligne.

Dans le panneau : Order → VPS → Sentinel, image Debian 12. Aucune adresse e-mail n'est requise pour ouvrir le compte, aucun document d'identité n'est demandé à aucun moment, et la facture se règle en Monero, Bitcoin, Lightning ou tout autre actif pris en charge. Choisissez le bastion selon la latence vers les services que vous automatisez plutôt que vers vous-même — un serveur d'automatisation parle aux API bien plus qu'il ne vous parle.

Créez ensuite l'enregistrement DNS avant de toucher au serveur : un enregistrement A pour n8n.example.com pointant vers l'IPv4 du VPS, et un enregistrement AAAA si vous utilisez IPv6. Cela doit être fait en premier, car Caddy demande un certificat à Let's Encrypt dès que la stack démarre, et une demande de certificat pour un nom qui ne se résout pas échoue — puis se met en retrait, et vous passez vingt minutes à vous demander pourquoi le site est injoignable.

Laissez une minute au DNS pour se propager et vérifiez-le depuis votre propre machine avant de continuer :

dig +short n8n.example.com
# → the IPv4 of your VPS, and nothing else

Avant que quoi que ce soit n'écoute sur un port public, exécutez la checklist de durcissement de la première heure — SSH par clé uniquement, un pare-feu qui n'autorise que 22, 80 et 443, et les mises à jour de sécurité automatiques. Un serveur d'automatisation est un coffre à identifiants ; il mérite l'heure complète.

Créez d'abord le répertoire et générez les deux secrets. Générez-les maintenant, dans cet ordre, et collez-les dans le .env au fur et à mesure — la clé de chiffrement en particulier doit exister avant le premier démarrage de n8n, pas après.

mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32   # → N8N_ENCRYPTION_KEY
openssl rand -hex 24   # → POSTGRES_PASSWORD

/opt/n8n/.env

DOMAIN=n8n.example.com
LETSENCRYPT_EMAIL=you@example.com
GENERIC_TIMEZONE=Europe/Stockholm

N8N_ENCRYPTION_KEY=paste_the_32_byte_hex_here
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste_the_24_byte_hex_here

Verrouillez le fichier immédiatement — il détient la clé de chaque identifiant que l'instance stockera un jour :

chmod 600 /opt/n8n/.env

/opt/n8n/docker-compose.yml

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DOMAIN=${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://${DOMAIN}
      - WEBHOOK_URL=https://${DOMAIN}/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_VERSION_NOTIFICATIONS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  caddy_data:
  caddy_config:
  pg_data:
  n8n_data:

/opt/n8n/Caddyfile

{$DOMAIN} {
    encode zstd gzip
    tls {$LETSENCRYPT_EMAIL}
    reverse_proxy n8n:5678
}

Deux choix de conception qui méritent d'être nommés. D'abord, n8n ne publie aucun port. Seul Caddy se lie aux ports 80 et 443 ; n8n écoute sur le 5678 à l'intérieur du réseau Compose, où rien en dehors de l'hôte ne peut l'atteindre. Un nombre surprenant d'instances n8n auto-hébergées se retrouvent sur l'internet public sur le port 5678 sans TLS devant, et les moteurs de recherche de services exposés les indexent. Ensuite, le volume de données n8n reste monté même si PostgreSQL héberge désormais les workflows — ce répertoire porte encore les réglages de l'instance, les fichiers de log et les éléments de contrôle de source.

Démarrez-le :

cd /opt/n8n
docker compose up -d
docker compose logs -f caddy   # watch the certificate being issued

Un n8n qui démarre, affiche l'éditeur et exécute un test manuel n'est pas encore un n8n fonctionnel. La moitié qui casse en silence, ce sont les webhooks entrants, et elle casse de façons qui font croire que le service tiers est en cause.

WEBHOOK_URL. Sans elle, n8n construit les URL de webhook à partir de N8N_HOST et N8N_PORT et vous remet quelque chose comme http://localhost:5678/webhook/abc — que vous collez ensuite dans Stripe ou GitHub, où elle ne pourra jamais être atteinte. Le fichier Compose ci-dessus fixe WEBHOOK_URL à la racine HTTPS publique, qui est ce que l'éditeur affichera et ce que le monde extérieur pourra réellement appeler.

N8N_EDITOR_BASE_URL. L'URL publique que n8n utilise pour les liens dans les e-mails qu'il envoie — réinitialisations de mot de passe, invitations d'utilisateurs. Une erreur ici donne un lien d'invitation qui pointe vers localhost, ce qui se traduit par un ticket de support d'un collègue plutôt que par une intégration cassée.

N8N_PROXY_HOPS. n8n lit l'IP du client depuis X-Forwarded-For, et ne fait confiance qu'au nombre de sauts que ce chiffre indique. Avec un seul reverse proxy devant — le Caddy de cette stack — la valeur est 1. Placez Cloudflare devant Caddy et elle devient 2. Laissez-la au 0 par défaut et chaque requête semble venir du proxy lui-même, ce qui casse en silence les limites de débit et toute logique basée sur l'IP dans vos workflows.

N8N_SECURE_COOKIE. Il vaut true par défaut, ce qui signifie que le cookie de session n'est envoyé que via HTTPS. C'est le bon réglage et cette stack le respecte. Cela vaut la peine d'être su, car cela explique le symptôme classique d'une première tentative en http simple : le formulaire de connexion accepte le mot de passe puis vous renvoie vers le formulaire de connexion, indéfiniment. Le correctif, c'est le TLS, pas désactiver le drapeau.

Testez-le correctement. Créez un workflow avec un nœud Webhook, activez le workflow, copiez l'URL de production, puis appelez-la depuis une machine qui n'est pas le serveur :

curl -i https://n8n.example.com/webhook/<path>
# → HTTP/2 200, and a new execution visible in the editor

La distinction qui piège tout le monde une fois : l'URL de test n'écoute que tant que vous avez l'éditeur ouvert avec « Listen for test event » armé. L'URL de production n'existe que lorsque le workflow est basculé sur Active. Un webhook qui fonctionne dans l'éditeur et renvoie 404 en production est presque toujours un workflow inactif.

Par défaut, n8n s'exécute en mode normal : le même processus qui sert l'éditeur et reçoit les webhooks exécute aussi les workflows. C'est simple et c'est correct jusqu'à ce qu'un long workflow fasse attendre les autres. Le symptôme est sans ambiguïté — les exécutions restent « en cours » pendant des minutes, l'éditeur devient poussif, et un webhook qui devrait répondre en 200 ms répond en huit secondes.

Le mode file d'attente divise le travail. L'instance principale garde l'éditeur, les déclencheurs et les points d'accès webhook ; elle pousse les ID d'exécution dans Redis ; des processus worker séparés les récupèrent, chargent le workflow depuis PostgreSQL, l'exécutent, et rendent compte via Redis. Trois règles découlent de cette architecture, et toutes les trois mordent ceux qui les négligent : chaque instance doit partager la même base PostgreSQL, chaque instance doit porter la même N8N_ENCRYPTION_KEY, et SQLite n'est pas du tout pris en charge.

Les ajouts au fichier Compose sont un service Redis et un service worker, qui est la même image n8n exécutée avec la commande worker :

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--save", "60", "1", "--appendonly", "no"]
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker --concurrency=5
    depends_on:
      - redis
      - postgres
    environment:
      # the SAME encryption key and the SAME database as the main instance
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}

Ajoutez aussi EXECUTIONS_MODE=queue et QUEUE_BULL_REDIS_HOST=redis au service n8n principal — les deux côtés doivent s'accorder sur le mode. Deux options méritent d'être fixées dès le premier jour : OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true, pour que cliquer sur « Test workflow » dans l'éditeur n'accapare pas le processus principal, et N8N_GRACEFUL_SHUTDOWN_TIMEOUT, qui vaut 30 secondes par défaut et détermine combien de temps un worker est autorisé à terminer sa tâche en cours lors d'un redéploiement. Si vos workflows durent régulièrement plus d'une demi-minute, augmentez-la, sinon chaque déploiement tue le travail en cours.

Ne commencez pas ici. Le mode file d'attente ajoute deux pièces mobiles et une classe de panne que le mode normal n'a tout simplement pas. Restez en mode normal jusqu'à ce que vous voyiez la file grossir ou qu'un workflow en bloque un autre, puis ajoutez un seul worker sur la même machine avant d'ajouter une deuxième machine. Cette progression — Sentinel en mode normal, Garrison avec un worker, Ravelin avec trois — couvre tout, sauf un déploiement vraiment massif.