🛠️ Tutos · 12 min de lecture

Héberger n8n sur un VPS en 2026 : guide self-hosted complet (Docker, HTTPS, sauvegardes)

Guide technique 2026 pour self-host n8n sur VPS : Docker Compose, HTTPS, sécurisation et coûts. Comparez le cloud vs on-premise pour automatiser sans abonnement.

S Par Équipe Selfhostr · tests indépendants
ⓘ Cet article peut contenir des liens affiliés (sans surcoût pour toi, ça soutient nos tests). Voir la disclosure.

L’automatisation des flux de travail (workflow automation) est passée d’une niche technique à une colonne vertébrale opérationnelle pour les startups, les agences digitales et les développeurs indépendants. En 2026, n8n reste la référence open-source, privilégiant la flexibilité et la souveraineté des données face aux géants du SaaS propriétaires.

Héberger n8n sur son propre VPS n’est plus une option réservée aux seuls DevOps expérimentés. Grâce à la maturité de Docker et aux outils de reverse-proxy modernes, déployer une instance robuste, sécurisée et chiffrée prend moins d’une heure. Cependant, le passage du cloud à l’on-premise implique des responsabilités : maintenance, sauvegardes et monitoring.

Ce guide technique détaille l’architecture optimale pour 2026. Nous couvrons le dimensionnement matériel, l’installation via Docker Compose, la configuration TLS, la persistance des données et la stratégie de mise à jour. L’objectif est de vous donner les clés pour une infrastructure fiable, sans dépendre des limites de quota ni des augmentations tarifaires imprévisibles des plateformes cloud.

Dimensionnement et choix du VPS : les métriques qui comptent

Avant de toucher à une ligne de code, il faut choisir l’infrastructure. n8n est une application Node.js, ce qui signifie qu’elle est principalement CPU-bound lors de l’exécution des workflows complexes et I/O-bound pour la lecture/écriture en base de données.

Spécifications minimales vs Recommandées

Beaucoup de tutoriels obsolètes recommandent 1 vCPU et 512 Mo de RAM. En 2026, avec des workflows plus lourds intégrant du traitement d’images, de l’IA locale ou des requêtes SQL complexes, cette configuration est risquée pour une production.

Profil d’usageCPURAMStockageCoût mensuel estimé (2026)
Laboratoire / Tests1 vCPU1 Go20 Go SSD~4 €
SMB / Usage léger2 vCPU2 Go50 Go NVMe~10-15 €
Production / Intégrations IA2-4 vCPU4 Go+100 Go NVMe~25-40 €

Analyse technique :

Pourquoi un VPS dédié ?

Héberger sa solution demande un bon VPS. Les offres “shared” ou les containers partagés sur des PaaS gratuits imposent des limites de temps d’exécution et de mémoire qui brisent la logique des workflows n8n (qui peuvent prendre plusieurs minutes pour traiter des données batch). Un VPS (chez Hetzner, OVH, DigitalOcean, Vultr) vous donne le contrôle total sur le kernel, le firewall et les ressources, essentiel pour la stabilité à long terme.

Architecture et Installation via Docker Compose

Nous allons utiliser Docker Compose pour orchestrer deux services : n8n et postgres. Cette séparation est cruciale pour la performance et la capacité de sauvegarde.

Prérequis

Étape 1 : Structure des dossiers

Créons une arborescence propre pour faciliter la maintenance.

mkdir -p ~/n8n/data/postgres
mkdir -p ~/n8n/data/n8n
cd ~/n8n

Étape 2 : Le fichier docker-compose.yml

Ce fichier définit nos conteneurs. Notez l’utilisation de variables d’environnement pour la sécurité et la configuration.

version: '3.8'

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678" # Port interne pour debugging ou reverse-proxy direct si besoin
    environment:
      - N8N_HOST=n8n.mondomaine.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - WEBHOOK_URL=https://n8n.mondomaine.com/
      - GENERIC_TIMEZONE=Europe/Paris
      # Sécurité de base
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=VotreMotDePasseFortIci
    volumes:
      - ./data/n8n:/home/node/.n8n
    depends_on:
      - postgres
    networks:
      - n8n-net

  postgres:
    image: postgres:15-alpine
    restart: always
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=UnAutreMotDePasseEncorePlusFort
      - POSTGRES_DB=n8n
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    networks:
      - n8n-net

networks:
  n8n-net:
    driver: bridge

Points d’attention techniques :

  1. Volumes : Les données n8n (workflows, credentials) sont dans ./data/n8n. Les données PostgreSQL sont dans ./data/postgres. Si vous supprimez ces dossiers, vous perdez tout.
  2. Variables d’environnement : N8N_HOST et WEBHOOK_URL doivent correspondre à votre domaine public. N8N_PROTOCOL=https force n8n à générer des liens HTTPS.
  3. Authentification basique : N8N_BASIC_AUTH est activé ici comme couche de sécurité supplémentaire, mais en production, nous utiliserons un reverse-proxy qui gérera l’authentification ou protégera l’accès par IP.

Étape 3 : Démarrage

docker compose up -d

Vérifiez les logs pour confirmer l’absence d’erreurs :

docker compose logs -f n8n

Si vous voyez n8n ready on port 5678, le service est fonctionnel. Accédez à http://localhost:5678 en SSH tunneling ou via l’IP publique (non recommandé sans proxy) pour finaliser l’installation via l’assistant web.

Configuration HTTPS et Reverse Proxy

Exposer n8n directement sur Internet est une mauvaise pratique. Il faut un reverse-proxy pour gérer le chiffrement TLS, le buffering des requêtes et la sécurité. En 2026, Caddy et Traefik sont les leaders. Caddy est privilégié ici pour sa simplicité (auto-HTTPS via Let’s Encrypt) et sa configuration minimaliste.

Installation de Caddy

# Sur Debian/Ubuntu
sudo apt update
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Configuration de Caddyfile

Éditez /etc/caddy/Caddyfile. Nous allons configurer un proxy inverse qui écoute le port 80/443 et redirige vers le conteneur n8n.

n8n.mondomaine.com {
    # Compression pour optimiser la bande passante
    encode gzip zstd

    # Proxy vers le conteneur Docker
    reverse_proxy localhost:5678 {
        # Headers importants pour la sécurité
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
        
        # Limitation de taille pour les webhooks lourds (images, fichiers)
        # Par défaut, Caddy peut bloquer les payloads > 100MB
        request_body {
            max_size 200MB
        }
    }

    # Sécurité HTTP de base (optionnel si vous gérez l'auth ailleurs)
    # basic_auth {
    #     admin $2a$14$... # Hash bcrypt du mot de passe
    # }
}

Note sur la sécurité : Caddy génère automatiquement les certificats SSL/TLS via Let’s Encrypt. Assurez-vous que le port 80 (HTTP) est ouvert dans le firewall du VPS pour la validation ACME, puis tout le trafic passera en HTTPS.

Redémarrez Caddy :

sudo systemctl restart caddy
sudo systemctl enable caddy

Testez votre domaine https://n8n.mondomaine.com. Vous devriez voir l’interface n8n avec le cadenas de sécurité.

Sécurisation et Hardening

Avoir HTTPS ne suffit pas. n8n manipule souvent des secrets (API keys, mots de passe). Voici les couches de défense indispensables.

1. Gestion des Secrets

Ne jamais stocker les clés API en clair dans les workflows. n8n intègre un gestionnaire de credentials chiffré.

2. Firewall (UFW)

Fermes tous les ports sauf ceux nécessaires : SSH (22) et HTTP/HTTPS (80/443).

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full' # Ou Caddy si détecté, sinon 80,443
sudo ufw allow 5678/tcp # Uniquement si vous avez besoin d'accès local direct
sudo ufw enable

Conseil : Désactivez l’accès direct au port 5678 depuis l’extérieur. Le reverse-proxy Caddy doit être le seul point d’entrée.

3. Sécurisation de l’accès n8n

4. Monitoring des logs

Activez le journalisation détaillée dans n8n pour détecter les tentatives d’intrusion ou les erreurs de workflow.

Sauvegardes : La règle des 3-2-1

L’automatisation n’a d’intérêt que si les données sont préservées. Une sauvegarde manuelle est une sauvegarde ratée. Nous allons automatiser la sauvegarde de la base PostgreSQL et des fichiers de configuration n8n.

Script de sauvegarde

Créez un script backup.sh dans le dossier ~/n8n/.

#!/bin/bash
DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR="/mnt/backups/n8n" # Pointez vers un disque externe ou un autre serveur S3
N8N_DIR="$HOME/n8n/data/n8n"
PG_DIR="$HOME/n8n/data/postgres"

# Création du dossier de date
mkdir -p "$BACKUP_DIR/$DATE"

# 1. Sauvegarde PostgreSQL (via docker exec pour éviter d'installer pg_dump localement)
docker compose exec -T postgres pg_dumpall -U n8n > "$BACKUP_DIR/$DATE/n8n_db_dump.sql"

# 2. Archivage des fichiers n8n (workflows, credentials)
tar -czf "$BACKUP_DIR/$DATE/n8n_files.tar.gz" -C "$HOME/n8n/data" n8n

# 3. Nettoyage des sauvegardes de plus de 30 jours
find "$BACKUP_DIR" -type d -mtime +30 -exec rm -rf {} \;

echo "Backup terminé : $DATE"

Automatisation avec Cron

Rendez le script exécutable et ajoutez-le au cron de l’utilisateur root ou dédié.

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

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

0 3 * * * /home/votreuser/n8n/backup.sh >> /var/log/n8n-backup.log 2>&1

Recommandation pro : Pour une vraie résilience, envoyez ces archives vers un stockage objet externe (AWS S3, Backblaze B2, MinIO) après la création. Vous pouvez ajouter une commande aws s3 sync ou rclone à la fin du script.

Mises à jour et Maintenance

n8n sort des mises à jour fréquentes. En auto-hébergement, vous êtes responsable de la compatibilité.

Stratégie de mise à jour

  1. Ne pas mettre à jour automatiquement sans test : Les changements majeurs de version peuvent casser des workflows existants.
  2. Procédure manuelle sécurisée : 
    cd ~/n8n
docker compose down
docker compose pull # Récupère la dernière image
docker compose up -d
  3. Vérification : Consultez le changelog de n8n avant de mettre à jour. Les versions majeures (ex: v1.0 à v2.0) ont souvent des breaking changes sur la structure des workflows ou des nœuds.

Monitoring de l’état du système

Installez un outil léger comme uptime-kuma ou prometheus + grafana pour surveiller :

Une alerte sur la consommation disque est cruciale : les logs PostgreSQL et les fichiers temporaires peuvent remplir le disque en quelques jours si un workflow tourne en boucle d’erreur.

Comparaison Coût : Self-Hosted vs n8n Cloud

Pour prendre une décision éclairée, comparons les coûts réels.

CritèreSelf-Hosted (VPS)n8n Cloud (Starter)
Coût mensuel~10-15 € (VPS basique)~20-25 € (à partir de ~2026 pricing)
ExécutionsIllimitées (limité par CPU/RAM)Limitées (ex: 1000/mois)
Temps d’exécution maxDépend du VPS (pas de hard limit strict)Limité (ex: 30 sec par workflow)
MaintenanceVotre responsabilité (Mise à jour, Sauvegarde)Nulle (Managed)
SouverainetéTotale (données sur votre serveur)Chez n8n (EU/US)
ScalabilitéHorizontale (ajout de workers)Automatique mais coûteuse

Analyse : Pour un usage personnel ou une petite entreprise (<50 workflows légers), le cloud peut être plus économique en temps. Cependant, dès que vous avez besoin de workflows longs (traitement de données, IA), d’exécutions parallèles massives ou que vous voulez éviter les frais par exécution, le VPS devient immédiatement plus rentable. De plus, le VPS vous permet de multiplier les instances (dev, staging, prod) pour le prix d’une seule.

Quel choix selon ton profil ?

Le Maker / Développeur Solo

Choix : Self-Hosted sur VPS 2 vCPU / 2 Go RAM. Vous avez les compétences techniques pour gérer Docker et les sauvegardes. Vous voulez contrôler vos données et éviter les quotas. Un VPS chez Hetzner ou OVH est parfait. Investissez du temps dans l’automatisation des sauvegardes dès le jour 1.

L’Agence / PME (Usage Critique)

Choix : Self-Hosted sur VPS haute dispo + Monitoring. L’automatisation est vitale. Vous devez héberger sur un VPS robuste (4 vCPU, 8 Go RAM) avec un reverse-proxy configuré pour la haute disponibilité. Prévoyez une sauvegarde externe (S3) et un plan de reprise d’activité. Le coût initial est plus élevé, mais le ROI sur les exécutions illimitées est immédiat.

L’Entreprise Enterprise

Choix : Kubernetes ou Cloud Managed. Si vous avez une équipe DevOps, déployez n8n sur Kubernetes pour une scalabilité horizontale automatique. Sinon, utilisez n8n Cloud Enterprise pour bénéficier du SLA et du support dédié. L’auto-hébergement sur un simple VPS n’est pas recommandé pour les charges critiques sans expertise infrastructure.

FAQ

Puis-je héberger n8n sur un NAS (Synology/QNAP) ?

Oui, techniquement possible via Docker. Cependant, les NAS ont des limitations I/O et CPU qui peuvent ralentir les workflows complexes. De plus, la gestion des mises à jour et des sauvegardes est plus manuelle. Pour un usage léger (notifications, sync simples), c’est viable. Pour la production, un VPS est plus fiable.

Comment migrer de n8n Cloud vers mon VPS ?

n8n propose un outil d’export/import.

  1. Sur n8n Cloud, exportez vos workflows (JSON).
  2. Exportez vos credentials (si possible, ou ré-entrez-les).
  3. Importez les workflows JSON dans votre instance self-hosted.
  4. Recréez les credentials dans l’interface locale. Note : Les webhooks URLs changeront, vous devrez mettre à jour les endpoints externes (Stripe, Slack, etc.) pour pointer vers votre nouveau domaine.

Quel est le risque de sécurité d’exposer n8n ?

Le risque principal n’est pas n8n lui-même, mais la configuration. Exposer n8n sans HTTPS, sans authentification forte ou avec des secrets en clair est dangereux. Avec un reverse-proxy (Caddy/Traefik), HTTPS obligatoire, firewall restrictif et mise à jour régulière, le risque est comparable à tout autre service web bien maintenu. La clé est la discipline de maintenance.

Puis-je utiliser n8n pour de l’IA locale ?

Oui. n8n supporte l’intégration de modèles LLM. Si vous hébergez un modèle local (via Ollama par exemple) sur le même VPS, vous pouvez l’appeler depuis n8n. Assurez-vous d’avoir suffisamment de RAM (16 Go+) et un GPU si possible pour une expérience fluide. L’architecture Docker facilite le déploiement d’Ollama à côté de n8n.

Disclaimer : Ce guide est fourni à titre informatif. La gestion d’infrastructure comporte des risques. Testez toujours vos sauvegardes et vos procédures de restauration dans un environnement de staging avant de les appliquer en production.

Tags : n8ndockervpsdevopsautomatisation

Sur le même sujet

🛠️ Tutos

Héberger Nextcloud sur un VPS en 2026 : guide complet (Docker, HTTPS, performances, sauvegardes)

Guide technique 2026 pour déployer Nextcloud sur VPS via Docker. Dimensionnement, optimisation PostgreSQL/Redis, HTTPS et stratégie de backup fiable.

Lire →
🛠️ Tutos

Héberger son site web soi-même en 2026 : guide complet (VPS, Docker, HTTPS)

Guide technique 2026 pour héberger son site sur VPS : choix d'offre, config Docker, HTTPS Let's Encrypt, sécurité et coûts réels. Comparez auto-hébergement et cloud.

Lire →
🛠️ Tutos

Héberger un bot Discord 24/7 sur un VPS en 2026 : guide complet (Node/Python, systemd, Docker)

Guide technique 2026 pour héberger un bot Discord en continu sur VPS. Comparatif Node vs Python, systemd vs Docker, dimensionnement, coûts et sécurisation du token pour développeurs.

Lire →