n8n : qu’est-ce que c’est et comment l’installer sur un VPS avec Docker Compose

30/08/202610 min de lecture

Tropic

n8n : qu’est-ce que c’est et comment l’installer sur un VPS avec Docker Compose

n8n sur un VPS : votre propre plateforme d’automatisation, sans tâches manuelles répétitives

Une demande arrive depuis le site. n8n vérifie les données, recherche les doublons, crée une opportunité, prépare un brouillon de réponse à l’aide de l’IA et avertit le responsable dans Telegram. Une personne n’intervient que lorsqu’une décision est nécessaire, et non pour copier des données d’un onglet à l’autre.

Nous allons voir ci-dessous comment fonctionne n8n et comment l’installer sur un VPS avec Docker Compose, PostgreSQL, HTTPS et une exécution du code isolée.

n8n en sept étapes

Le plan de lancement minimal :

Créez un VPS et faites pointer un sous-domaine vers celui-ci, par exemple n8n.example.com.
Installez Docker et Docker Compose.
Lancez n8n avec PostgreSQL, un task runner externe et Caddy.
Ouvrez l’interface en HTTPS et créez le compte propriétaire.
Connectez Telegram, un CRM, la messagerie ou n’importe quelle API externe.
Configurez la gestion des erreurs et la durée de conservation des exécutions.
Automatisez les sauvegardes de la base de données, des données et de la clé de chiffrement.

Pour une petite installation en production, il est raisonnable de commencer avec 2 vCPU et 4 Go de RAM. Pour des tests, 2 Go suffisent souvent, mais PostgreSQL, Docker et les processus parallèles consomment rapidement la marge disponible.

Qu’est-ce que n8n et comment fonctionne-t-il ?

n8n est une plateforme d’automatisation de workflows. Un scénario est assemblé à partir de nœuds : le premier déclenche le processus, les suivants récupèrent et transforment les données, et le dernier exécute une action.

Un workflow simple ressemble à ceci :

Webhook → vérification des données → CRM → Telegram → réponse au site

La chaîne peut être déclenchée par un webhook, une planification, un e-mail, un message ou un événement provenant d’un service externe. Entre les nœuds, vous pouvez utiliser des conditions, des boucles, des filtres, des attentes et une gestion des erreurs.

L’un des points forts de n8n est que l’automatisation ne se limite pas aux intégrations prêtes à l’emploi. Tout service disposant d’une API peut être appelé avec HTTP Request, tandis qu’une logique particulière peut être écrite dans un Code node en JavaScript ou en Python. n8n se situe ainsi entre un constructeur no-code simple et du code serveur développé sur mesure.

Pourquoi ce n’est pas qu’un simple transfert de données

n8n est utile lorsqu’un processus traverse plusieurs systèmes et nécessite une décision :

formulaire → vérification → recherche de doublon → évaluation par l’IA → validation du responsable → CRM

L’intervention humaine peut être limitée à un point de contrôle. Par exemple, l’IA prépare une réponse, mais le message n’est envoyé au client qu’après l’approbation d’un employé.

Scénarios courants :

vente et assistance : collecte des demandes, répartition des prospects et création d’opportunités ;
contenu et IA : création de brouillons, classification des demandes et publication après validation ;
DevOps : notifications d’incidents, webhooks issus de Git et vérifications d’API ;
opérations internes : synchronisation des feuilles de calcul, des e-mails, des calendriers et des systèmes d’entreprise.

Une installation self-hosted vous donne le contrôle sur le processus et la base de données, mais ne rend pas les services externes locaux. Les données envoyées à Telegram, à un CRM ou à un modèle d’IA dans le cloud quittent le VPS.

n8n Cloud ou votre propre serveur

Paramètre	n8n Cloud	n8n sur un VPS
Lancement	Aucune configuration de serveur	Domaine, Docker et HTTPS nécessaires
Mises à jour	Réalisées par n8n	Réalisées par le propriétaire
Base de données et fichiers	Dans l’infrastructure du service	Sur le serveur choisi
Mise à l’échelle	Selon les conditions de l’offre cloud	Configuration autonome
Responsabilité	Moins d’administration	Sauvegardes, sécurité et supervision à la charge du propriétaire
Pour qui	Démarrage rapide sans DevOps	Contrôle, personnalisation et processus permanents

Community Edition peut être hébergée gratuitement sur votre propre serveur et utilisée pour des processus personnels ou internes à l’entreprise. Toutefois, n8n n’est pas distribué sous une licence open source classique, mais selon le modèle fair-code Sustainable Use License. Celle-ci autorise l’utilisation interne et les modifications, mais ne permet pas de simplement déployer n8n, d’y apposer votre logo et de vendre l’accès comme un SaaS indépendant. Pour un tel produit, il faut vérifier séparément les conditions de licence.

Configuration serveur requise pour n8n

La charge dépend du volume de données, du niveau de parallélisme et du type d’opérations. Les fichiers, les longues listes, les Code nodes et les workflows intégrant de l’IA nécessitent davantage de mémoire que le transfert de petits objets JSON entre des API.

Scénario	Configuration de départ
Tests et workflows personnels basés sur du texte	1 vCPU, 2 Go de RAM, 20 Go NVMe
Petite installation en production	2 vCPU, 4 Go de RAM, 25–40 Go NVMe
Processus parallèles, IA ou fichiers	4 vCPU, 8 Go de RAM ou plus
Plusieurs processus worker en queue mode	Dimensionnement selon le nombre d’exécutions

SQLite convient à la découverte et à une petite instance unique. Pour une installation en production, PostgreSQL est plus pratique : les sauvegardes sont plus simples et un passage ultérieur au queue mode est plus facile.

Comment installer n8n sur un VPS

Cet exemple utilise Ubuntu 24.04, PostgreSQL, Caddy et un task runner externe. Remplacez n8n.example.com et le fuseau horaire par vos propres valeurs.

1. Configurez le DNS et préparez le serveur

Créez un enregistrement DNS A pointant vers l’adresse IPv4 du VPS, puis connectez-vous en SSH :

ssh root@SERVER_IP
apt update && apt upgrade -y
apt install -y ca-certificates curl ufw openssl

Installez Docker Engine et le plug-in Compose depuis le dépôt officiel :

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

cat > /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

apt update
apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
docker compose version

N’ouvrez que SSH, HTTP et HTTPS :

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

Ne fermez pas la session SSH actuelle tant que vous n’avez pas vérifié qu’une nouvelle connexion fonctionne.

2. Créez les variables d’environnement

Préparez le répertoire :

mkdir -p /opt/n8n
cd /opt/n8n

Créez .env. Les commandes ci-dessous génèrent immédiatement des secrets aléatoires différents pour PostgreSQL, le chiffrement de n8n et le task runner :

cat > .env <<EOF
N8N_VERSION=stable
N8N_HOST=n8n.example.com
GENERIC_TIMEZONE=Europe/Berlin

POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=$(openssl rand -hex 32)

N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)
RUNNERS_AUTH_TOKEN=$(openssl rand -hex 32)
EOF

chmod 600 .env

Le tag stable est pratique pour le premier lancement. Après avoir vérifié l’installation, il est préférable de figer une version précise de n8n afin qu’une prochaine mise à jour de l’image ne se produise pas de manière inattendue.

Il ne faut pas perdre N8N_ENCRYPTION_KEY. n8n utilise cette clé pour chiffrer les mots de passe, les jetons et les autres identifiants enregistrés. Si vous restaurez uniquement PostgreSQL sans la clé, les enregistrements resteront dans la base, mais n8n ne pourra pas les lire.

3. Créez la configuration Docker Compose

Créez le fichier compose.yaml :

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

  n8n:
    image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
    restart: unless-stopped
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: "5432"
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}

      N8N_HOST: ${N8N_HOST}
      N8N_PORT: "5678"
      N8N_PROTOCOL: https
      N8N_EDITOR_BASE_URL: https://${N8N_HOST}
      N8N_WEBHOOK_URL: https://${N8N_HOST}/
      N8N_PROXY_HOPS: "1"
      GENERIC_TIMEZONE: ${GENERIC_TIMEZONE}
      TZ: ${GENERIC_TIMEZONE}

      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: "true"
      N8N_BLOCK_ENV_ACCESS_IN_NODE: "true"

      N8N_RUNNERS_MODE: external
      N8N_RUNNERS_AUTH_TOKEN: ${RUNNERS_AUTH_TOKEN}
      N8N_RUNNERS_BROKER_LISTEN_ADDRESS: 0.0.0.0

      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: "168"
      EXECUTIONS_DATA_PRUNE_MAX_COUNT: "10000"
    volumes:
      - n8n_data:/home/node/.n8n
    expose:
      - "5678"
    depends_on:
      postgres:
        condition: service_healthy

  n8n-runner:
    image: n8nio/runners:${N8N_VERSION}
    restart: unless-stopped
    environment:
      N8N_RUNNERS_AUTH_TOKEN: ${RUNNERS_AUTH_TOKEN}
      N8N_RUNNERS_TASK_BROKER_URI: http://n8n:5679
    depends_on:
      - n8n

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    environment:
      N8N_HOST: ${N8N_HOST}
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - n8n

volumes:
  postgres_data:
    name: n8n_postgres_data
  n8n_data:
    name: n8n_data
  caddy_data:
    name: n8n_caddy_data
  caddy_config:
    name: n8n_caddy_config

Le task runner externe exécute le code séparément du processus principal de n8n. Cette méthode est plus sûre que le mode interne et réduit le risque qu’une erreur dans un Code node affecte l’éditeur et le traitement des webhooks.

4. Activez HTTPS

Créez le fichier Caddyfile :

{$N8N_HOST} {
    reverse_proxy n8n:5678
}

Caddy obtiendra automatiquement un certificat TLS si le DNS pointe déjà vers le VPS et si les ports 80 et 443 sont accessibles. Le port interne 5678 n’est pas publié sur Internet : seuls les ports 80 et 443 sont accessibles depuis l’extérieur, tandis que Caddy communique avec n8n via le réseau Docker.

Les variables N8N_WEBHOOK_URL et N8N_PROXY_HOPS sont nécessaires pour que l’éditeur génère les bonnes adresses publiques de webhook et fasse confiance aux en-têtes provenant d’un reverse proxy.

5. Lancez n8n

Vérifiez la configuration finale et démarrez les conteneurs :

docker compose config
docker compose up -d
docker compose ps
docker compose logs --tail=100 n8n caddy

Ouvrez :

https://n8n.example.com

Créez le compte propriétaire. Ne partagez pas son mot de passe avec vos collègues : pour le travail en équipe, utilisez des comptes séparés et n’accordez que les accès nécessaires.

Premier workflow utile

Le traitement d’une demande provenant du site constitue un bon test :

Ajoutez un nœud Webhook avec la méthode POST.
Avec Edit Fields, ne conservez que le nom, l’adresse e-mail et la source.
Utilisez un nœud If pour refuser une demande à laquelle il manque des données obligatoires.
Créez une opportunité dans le CRM ou envoyez une requête avec HTTP Request.
Ajoutez une notification Telegram.
Terminez la chaîne avec un nœud Respond to Webhook.
Après le test, activez le workflow et remplacez le webhook de test par l’URL de production.

Cet exemple vérifie immédiatement le domaine, HTTPS, les requêtes entrantes, les identifiants et le fonctionnement de l’intégration externe. Ajoutez ensuite un Error Workflow distinct qui enverra une notification en cas d’échec de la chaîne principale.

Sécuriser n8n après l’installation

Une instance n8n installée n’est pas encore une instance fiable. Après le lancement, vérifiez que :

l’éditeur n’est accessible qu’en HTTPS ;
.env dispose des droits 600 et n’est pas ajouté à Git ;
les clés d’API externes ne possèdent que les autorisations minimales ;
chaque webhook vérifie la signature ou le secret de la source ;
l’historique des exécutions est supprimé automatiquement ;
les erreurs des workflows critiques sont envoyées à l’administrateur.

Les Community nodes sont installés sous forme de paquets et peuvent accéder aux données des workflows ainsi qu’au serveur. N’ajoutez pas de nœuds inconnus sans les vérifier. Si vous n’en avez pas besoin, désactivez-les avec N8N_COMMUNITY_PACKAGES_ENABLED=false.

Lancez l’audit intégré :

docker compose exec n8n n8n audit

Il aide à repérer les webhooks non protégés, les nœuds risqués et les problèmes d’identifiants, mais ne remplace pas une vérification manuelle.

Historique des exécutions et données personnelles

n8n enregistre les données d’entrée et de sortie pour le débogage. Des e-mails, des numéros de téléphone, des documents et des réponses d’API peuvent ainsi rester dans la base de données.

Dans la configuration ci-dessus, les exécutions sont supprimées après sept jours et leur nombre est limité à 10 000. Pour les processus sensibles, choisissez la durée selon votre politique de conservation des données et supprimez les champs inutiles avant la fin du workflow.

Sauvegardes et mises à jour

Pour effectuer une restauration, il faut un dump PostgreSQL, le volume n8n_data, les fichiers de configuration et le fichier .env contenant N8N_ENCRYPTION_KEY. Avant la copie, arrêtez les processus de traitement tout en laissant PostgreSQL en fonctionnement. Cela provoquera une courte interruption des workflows :

cd /opt/n8n
mkdir -p backup
docker compose stop n8n n8n-runner

docker compose exec -T postgres sh -c \
  'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' \
  | gzip > "backup/n8n-db-$(date +%F).sql.gz"

docker run --rm \
  -v n8n_data:/source:ro \
  -v "$PWD/backup":/backup \
  alpine sh -c \
  'tar -czf /backup/n8n-data-$(date +%F).tar.gz -C /source .'

tar -czf "backup/n8n-config-$(date +%F).tar.gz" \
  .env compose.yaml Caddyfile

docker compose start n8n n8n-runner

L’archive contenant .env renferme des secrets : chiffrez-la et conservez-la en dehors du VPS. Vérifiez périodiquement la copie en effectuant une restauration de test.

Avant une mise à jour, réalisez une sauvegarde et consultez les notes de version :

cd /opt/n8n
docker compose pull
docker compose up -d
docker compose ps

Le task runner et le conteneur principal doivent utiliser le même tag de version.

Quand faut-il passer à l’échelle ?

Ne commencez pas avec Redis et plusieurs workers tant qu’il n’existe pas de charge réelle. Une seule instance avec PostgreSQL est plus simple à administrer et suffit généralement pour de petits processus internes.

Le queue mode devient nécessaire lorsque des tâches longues retardent les webhooks, que de nombreux workflows démarrent simultanément ou que le traitement de fichiers occupe régulièrement toute la mémoire. L’instance principale reçoit alors les événements, Redis distribue les tâches et les workers les exécutent en parallèle. Tous les composants doivent se connecter au même PostgreSQL et utiliser le même N8N_ENCRYPTION_KEY.

Quel VPS choisir pour n8n ?

Pour l’ensemble n8n, PostgreSQL, Caddy et task runner, il est raisonnable de commencer avec 2 vCPU, 4 Go de RAM et un disque NVMe. Sur tropic.host, cette configuration correspond à l’offre Light : 2 vCPU, 4 Go de RAM et 25 Go NVMe. Cela suffit pour les premiers workflows en production sans traitement lourd de fichiers.

Pour les documents, les grands volumes de données et de nombreux workflows d’IA parallèles, mieux vaut choisir 8 Go de RAM. La stabilité du réseau est également importante : les webhooks, les retours OAuth et les tâches planifiées doivent rester accessibles en permanence.

Conclusion

n8n transforme les opérations répétitives en schémas lisibles : les nœuds prêts à l’emploi accélèrent le lancement, HTTP Request connecte presque n’importe quelle API et un Code node permet d’ajouter votre propre logique.

La version self-hosted donne le contrôle sur le serveur et la base de données, mais exige HTTPS, des clés aux droits limités, le nettoyage de l’historique et des sauvegardes vérifiées. Conservez N8N_ENCRYPTION_KEY avec PostgreSQL : sans cette clé, les identifiants restaurés ne peuvent pas être déchiffrés.

FAQ

Peut-on utiliser n8n gratuitement ?

Oui. Community Edition peut être hébergée gratuitement sur votre propre serveur pour des processus personnels et internes. La revente d’une instance n8n hébergée comme SaaS indépendant est limitée par la licence fair-code.

Peut-on installer n8n sans nom de domaine ?

Oui, pour un test local. Pour les webhooks publics et OAuth, il est préférable d’utiliser un domaine et HTTPS.

De combien de mémoire vive n8n a-t-il besoin ?

Des workflows personnels simples fonctionnent souvent avec 2 Go de RAM. Pour n8n avec PostgreSQL, Caddy et un task runner, 4 Go sont plus raisonnables ; les fichiers et les exécutions parallèles peuvent nécessiter 8 Go ou davantage.

Toutes les données restent-elles dans le VPS ?

Uniquement celles que le workflow n’envoie pas à l’extérieur. La base de données et l’historique des exécutions se trouvent sur le VPS, mais les nœuds Telegram, CRM ou ceux d’un modèle d’IA externe transmettent les données sélectionnées au service concerné.

Que faut-il inclure dans une sauvegarde de n8n ?

Un dump PostgreSQL, le volume n8n_data, compose.yaml, Caddyfile et le fichier .env contenant N8N_ENCRYPTION_KEY. Conservez la copie chiffrée en dehors du VPS et vérifiez-la par une restauration.

Retour au blog