Installer n8n sur un VPS Linux avec Docker : automatiser ses workflows en auto-hébergé

n8n : automatiser ses workflows en auto-hébergé

n8n est une plateforme d'automatisation de workflows open source, auto-hébergeable, qui connecte des centaines de services entre eux : API REST, bases de données, services de messagerie, outils de monitoring. C'est l'alternative que les administrateurs de serveurs choisissent quand ils veulent garder le contrôle total sur leurs données et leurs automatisations, sans dépendre d'un service tiers hébergé aux États-Unis.

Là où des plateformes SaaS comme Zapier ou Make facturent à l'exécution et imposent des limites sur le nombre de workflows, n8n auto-hébergé sur un VPS Linux n'a pas de plafond d'exécution. Les workflows tournent sur votre serveur, les données ne quittent pas votre infrastructure, et la configuration complète est stockée dans des fichiers que vous sauvegardez vous-même.

Ce guide couvre l'installation de n8n via Docker Compose sur un VPS Linux, la mise en place d'un reverse proxy HTTPS avec Caddy, la configuration SMTP pour les notifications, la sauvegarde de la base de données, et trois cas d'usage concrets pour les administrateurs de serveurs.

Prérequis

• Un VPS Linux sous Ubuntu 22.04/24.04 LTS ou Debian 12 avec au moins 2 Go de RAM et 20 Go de stockage ;
• Un accès SSH avec un utilisateur non-root disposant de sudo (sécuriser SSH sur VPS Linux) ;
• Docker et Docker Compose installés (guide d'installation Docker sur VPS) ;
• Un nom de domaine (ou sous-domaine) pointant vers l'adresse IP de votre VPS (enregistrement DNS de type A) ;
• Le port 443 ouvert dans le pare-feu du VPS (ouvrir des ports avec UFW).

Déployer n8n avec Docker Compose

Créez un répertoire de travail et le fichier docker-compose.yml :

mkdir -p ~/n8n && cd ~/n8n
nano docker-compose.yml

Contenu du fichier Docker Compose pour un déploiement avec la base SQLite intégrée :

services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.votre-domaine.fr
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://n8n.votre-domaine.fr/
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

Points importants de cette configuration :

• 127.0.0.1:5678:5678 : le port n8n n'est exposé que sur l'interface locale. Seul le reverse proxy peut y accéder, jamais l'extérieur directement ;
• N8N_WEBHOOK_URL : indique à n8n l'URL publique de vos webhooks derrière le reverse proxy ;
• n8n_data : volume Docker persistant qui contient la base SQLite, les clés de chiffrement des credentials, les logs et les fichiers de configuration.

Lancez le conteneur :

docker compose up -d

Vérifiez que n8n répond localement :

curl -s http://127.0.0.1:5678/healthz

Mettre n8n derrière un reverse proxy HTTPS

Exposer n8n directement sur le port 5678 sans chiffrement TLS n'est pas acceptable en production. Un reverse proxy HTTPS termine la connexion SSL/TLS, gère le certificat Let's Encrypt et transmet les requêtes au conteneur n8n sur le réseau interne.

Caddy est le choix le plus simple pour cette tâche : il obtient et renouvelle automatiquement les certificats Let's Encrypt, sans configuration supplémentaire. Si vous préférez Nginx, consultez notre guide publier un service sur un VPS Linux en HTTPS.

Option 1 : Caddy en conteneur Docker

Ajoutez le service Caddy au fichier docker-compose.yml et retirez le port exposé de n8n :

services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    environment:
      - N8N_HOST=n8n.votre-domaine.fr
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://n8n.votre-domaine.fr/
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
    volumes:
      - n8n_data:/home/node/.n8n

  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

volumes:
  n8n_data:
  caddy_data:
  caddy_config:

Créez le fichier Caddyfile dans le même répertoire :

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

Caddy transmet automatiquement les en-têtes X-Forwarded-For, X-Forwarded-Proto et X-Forwarded-Host dont n8n a besoin pour fonctionner derrière un reverse proxy. Redémarrez la stack :

docker compose down && docker compose up -d

Caddy obtient le certificat TLS automatiquement au premier démarrage. Accédez à n8n via https://n8n.votre-domaine.fr pour créer le compte administrateur.

Option 2 : Nginx installé sur le VPS

Si Nginx est déjà installé sur votre VPS, gardez le port n8n en écoute locale (127.0.0.1:5678:5678) et créez un bloc serveur Nginx :

server {
    server_name n8n.votre-domaine.fr;
    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        chunked_transfer_encoding off;
        proxy_buffering off;
        proxy_cache off;
    }
}

Les directives Upgrade et Connection sont nécessaires pour les WebSockets utilisés par l'éditeur n8n. Activez HTTPS avec Certbot :

sudo certbot --nginx -d n8n.votre-domaine.fr

Sécuriser la clé de chiffrement

n8n chiffre les credentials (tokens API, mots de passe des intégrations) stockés dans la base de données. Au premier lancement, il génère automatiquement une clé de chiffrement dans le répertoire .n8n. Si vous perdez cette clé, tous les credentials deviennent illisibles.

Pour fixer explicitement la clé et pouvoir la restaurer en cas de migration, ajoutez la variable N8N_ENCRYPTION_KEY au bloc environment du fichier Docker Compose :

environment:
  - N8N_ENCRYPTION_KEY=votre-cle-secrete-de-32-caracteres-minimum

Générez une clé aléatoire depuis le terminal :

openssl rand -hex 32

Conservez cette clé dans un gestionnaire de mots de passe ou un fichier chiffré hors du serveur. Elle est indispensable pour restaurer une sauvegarde sur un autre VPS.

Configurer les notifications SMTP

n8n envoie des e-mails pour les invitations d'utilisateurs, les réinitialisations de mot de passe et les alertes de workflows. Sans configuration SMTP, ces fonctions ne sont pas disponibles.

Ajoutez les variables SMTP au bloc environment du service n8n dans le fichier docker-compose.yml :

environment:
  - N8N_EMAIL_MODE=smtp
  - N8N_SMTP_HOST=smtp.votre-fournisseur.fr
  - N8N_SMTP_PORT=587
  - N8N_SMTP_USER=votre-utilisateur-smtp
  - N8N_SMTP_PASS=votre-mot-de-passe-smtp
  - N8N_SMTP_SENDER=n8n@votre-domaine.fr
  - N8N_SMTP_SSL=false

Avec N8N_SMTP_PORT=587 et N8N_SMTP_SSL=false, n8n utilise STARTTLS (chiffrement opportuniste). Pour un serveur SMTP sur le port 465, passez N8N_SMTP_SSL à true. Redémarrez le conteneur pour appliquer :

docker compose down && docker compose up -d

Passer de SQLite à PostgreSQL

SQLite convient à un usage individuel avec quelques dizaines de workflows. Quand le volume d'exécutions augmente (plusieurs milliers par jour) ou que plusieurs utilisateurs partagent l'instance, PostgreSQL offre de meilleures performances en lecture/écriture concurrente et simplifie les sauvegardes avec pg_dump.

Modifiez le fichier docker-compose.yml pour ajouter un service PostgreSQL :

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=un-mot-de-passe-fort
      - POSTGRES_DB=n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data

  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      - postgres
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=un-mot-de-passe-fort
      - N8N_HOST=n8n.votre-domaine.fr
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://n8n.votre-domaine.fr/
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
      - N8N_ENCRYPTION_KEY=votre-cle-secrete
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:
  postgres_data:

Le volume n8n_data reste nécessaire même avec PostgreSQL : il contient les clés de chiffrement, les logs de l'instance et les fichiers du système de versioning de workflows.

Sauvegarder les données n8n

Une instance n8n contient deux types de données à sauvegarder : la base de données (workflows, credentials chiffrés, historique d'exécutions) et le répertoire .n8n (clé de chiffrement, configuration).

Sauvegarde SQLite

La base SQLite se trouve dans le volume Docker n8n_data. Copiez le fichier de base pendant que le conteneur est en cours d'exécution (SQLite supporte les lectures concurrentes) :

docker compose exec n8n sqlite3 /home/node/.n8n/database.sqlite ".backup '/home/node/.n8n/backup.sqlite'"
docker cp $(docker compose ps -q n8n):/home/node/.n8n/backup.sqlite ~/n8n/backups/n8n-$(date +%Y%m%d).sqlite

Sauvegarde PostgreSQL

Avec PostgreSQL, utilisez pg_dump depuis le conteneur :

docker compose exec postgres pg_dump -U n8n n8n > ~/n8n/backups/n8n-$(date +%Y%m%d).sql

Automatiser avec cron

Planifiez une sauvegarde quotidienne avec une tâche cron. Créez un script ~/n8n/backup.sh :

#!/bin/bash
BACKUP_DIR=~/n8n/backups
mkdir -p "$BACKUP_DIR"
docker compose -f ~/n8n/docker-compose.yml exec -T postgres pg_dump -U n8n n8n > "$BACKUP_DIR/n8n-$(date +%Y%m%d).sql"
find "$BACKUP_DIR" -name "*.sql" -mtime +30 -delete

chmod +x ~/n8n/backup.sh
crontab -e

Ajoutez la ligne suivante pour une sauvegarde quotidienne à 3 h du matin :

0 3 * * * /home/votre-utilisateur/n8n/backup.sh

Pour envoyer les sauvegardes hors du serveur (vers un NAS, un stockage objet ou un second VPS), consultez le guide chiffrer et externaliser les sauvegardes serveur.

Mettre à jour n8n

La mise à jour de n8n avec Docker Compose se fait en trois commandes :

cd ~/n8n
docker compose pull
docker compose down && docker compose up -d

Docker télécharge la dernière image n8nio/n8n:latest, arrête l'ancien conteneur et en crée un nouveau avec les mêmes volumes. Les workflows, credentials et l'historique d'exécutions sont conservés dans les volumes persistants.

Avant de mettre à jour en production, consultez les notes de version officielles pour vérifier les changements non rétrocompatibles. Pour fixer une version précise au lieu de latest, remplacez le tag dans le fichier Docker Compose :

image: n8nio/n8n:2.45.7

Cas d'usage pour administrateurs de serveurs

n8n prend tout son sens quand il est branché sur l'infrastructure que vous administrez. Voici trois workflows concrets pour un admin de VPS ou de serveur dédié.

Webhook Discord sur alerte monitoring

Créez un workflow déclenché par un webhook HTTP. Quand votre outil de monitoring (Uptime Kuma, Grafana, Prometheus Alertmanager) détecte un incident, il envoie un POST vers le webhook n8n. Le workflow parse le payload JSON, formate un message avec le nom du service, le type d'alerte et le timestamp, puis l'envoie dans un salon Discord via le node Discord.

Ce workflow remplace un bot Discord dédié par une configuration visuelle de quelques nodes, sans code à maintenir.

Pipeline de déploiement git-pull automatique

Un webhook GitHub ou Gitea déclenche un workflow n8n à chaque push sur la branche main. Le workflow exécute un node SSH qui se connecte au serveur cible, lance un git pull, redémarre le service concerné via systemctl, puis envoie une notification de confirmation. C'est un pipeline CI/CD minimal qui ne nécessite ni GitHub Actions ni GitLab Runner.

Collecte de métriques système

Un workflow planifié (Schedule Trigger) s'exécute toutes les 5 minutes, interroge vos VPS via SSH pour collecter la charge CPU, la mémoire utilisée et l'espace disque (uptime, free -m, df -h), puis enregistre les valeurs dans une base InfluxDB ou un fichier CSV. Un second workflow analyse les tendances et envoie une alerte quand un seuil est dépassé.

Questions fréquentes

Combien de RAM faut-il pour faire tourner n8n sur un VPS ?

n8n consomme environ 200 Mo de RAM au repos. Avec une vingtaine de workflows actifs et une base SQLite, comptez 512 Mo à 1 Go. Au-delà de 50 workflows avec des exécutions fréquentes, prévoyez 2 Go de RAM minimum, surtout si vous utilisez PostgreSQL en parallèle sur le même VPS.

n8n fonctionne-t-il sur un VPS avec 1 vCPU ?

Oui. Un seul vCPU suffit pour un usage personnel ou une petite équipe. n8n est monothread pour le traitement des workflows (Node.js), donc un vCPU performant est plus utile que plusieurs vCPU lents. Les webhook-heavy workloads (des centaines de webhooks par minute) bénéficient de 2 vCPU.

Peut-on utiliser n8n sans Docker ?

Oui, n8n peut être installé directement avec npm (npm install -g n8n). Mais Docker simplifie les mises à jour, l'isolation du processus et les sauvegardes. La documentation officielle de n8n recommande l'installation Docker pour la production.

Les données sont-elles chiffrées dans la base n8n ?

Les credentials (tokens API, mots de passe des intégrations) sont chiffrés avec la clé N8N_ENCRYPTION_KEY avant d'être stockés en base. Les workflows et l'historique d'exécutions ne sont pas chiffrés. Pour protéger l'ensemble de la base au repos, utilisez le chiffrement du volume de stockage du VPS (LUKS ou le chiffrement fourni par l'hébergeur).

Comment migrer n8n vers un autre VPS ?

Exportez le volume Docker n8n_data (ou la base PostgreSQL avec pg_dump), copiez le fichier docker-compose.yml et les fichiers de configuration sur le nouveau VPS, et relancez docker compose up -d. La clé N8N_ENCRYPTION_KEY doit être identique sur le nouveau serveur pour que les credentials restent lisibles.