Déployer N8N Self-Hosted en Production : Guide Complet 2026

N8N Cloud vs self-hosted : quel choix pour une PME ?

N8N propose deux modes d'utilisation : la version cloud gérée (n8n.cloud) et le self-hosting sur votre propre infrastructure. Ce choix n'est pas anodin — il impacte vos coûts, la conformité RGPD, et les possibilités de personnalisation.

Critère	N8N Cloud	N8N Self-hosted
Coût mensuel (usage modéré)	20€ à 50€/mois	5€ à 20€/mois (VPS)
Coût mensuel (usage intensif)	100€ à 500€/mois	20€ à 60€/mois (VPS plus puissant)
Maintenance requise	Aucune (géré par N8N)	Mises à jour, sauvegardes, monitoring
Conformité RGPD	Serveurs US (moins favorable)	Serveurs EU de votre choix (optimal)
Données sensibles	Transitent par les serveurs N8N	Restent sur votre infrastructure
Personnalisation	Limitée	Complète (nœuds custom, plugins)
Nombre d'exécutions	Limité par le plan	Illimité (selon ressources serveur)
Temps de mise en place	5 minutes	2 à 4 heures (ce guide)

Bon à savoir : Le self-hosting devient rentable dès que vous dépassez 20 à 30 exécutions quotidiennes ou que vous traitez des données clients. Pour une TPE avec peu de workflows simples, N8N Cloud peut être plus adapté malgré le coût supérieur.

Qui devrait self-héberger N8N ?

Entreprises traitant des données personnelles (secteur médical, juridique, RH) : le RGPD impose de contrôler la localisation des données
PME avec des volumes élevés : au-delà de quelques centaines d'exécutions par jour, le self-hosting est nettement moins coûteux
Entreprises avec des besoins de personnalisation : nœuds custom, plugins tiers, intégrations propriétaires
Équipes techniques capables de gérer un serveur Linux et Docker

Prérequis et configuration serveur

Un bon déploiement commence par un serveur correctement dimensionné et configuré. Bâcler cette étape génère des problèmes en production.

Configuration serveur recommandée

Usage	vCPU	RAM	Stockage	Coût estimé
Démarrage / test	2 vCPU	2 Go	20 Go SSD	~5€/mois
Production légère (<100 workflows)	2 vCPU	4 Go	40 Go SSD	~10€/mois
Production standard	4 vCPU	8 Go	80 Go SSD	~20€/mois
Production intensive (queue mode)	8 vCPU	16 Go	160 Go SSD	~50€/mois

OS recommandé : Ubuntu 24.04 LTS. C'est la distribution la mieux supportée par Docker et la plus documentée pour N8N. Évitez les distributions exotiques ou les versions trop récentes qui peuvent avoir des incompatibilités.

Configuration initiale du serveur

Après la création de votre VPS, exécutez ces commandes de base :

# Mise à jour du système

sudo apt update && sudo apt upgrade -y

# Configuration du pare-feu

sudo ufw allow 22/tcp

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw enable

# Créer un utilisateur dédié (ne pas tout faire en root)

sudo adduser n8nadmin

sudo usermod -aG sudo n8nadmin

Attention : Ne laissez jamais le port 5432 (PostgreSQL) ouvert sur internet. PostgreSQL doit être accessible uniquement en interne, entre les conteneurs Docker. Le seul port public doit être 443 (HTTPS).

Nom de domaine

Vous aurez besoin d'un sous-domaine pointant vers votre serveur. Créez un enregistrement DNS A de type :

n8n.votre-domaine.fr  →  A  →  [IP de votre VPS]

Attendez la propagation DNS (généralement 5 à 30 minutes) avant de passer à l'étape SSL.

Installation Docker en 15 minutes

Docker est le moyen le plus fiable de déployer N8N en production. Il isole l'application, facilite les mises à jour et garantit la cohérence entre les environnements.

Installer Docker Engine

# Installation Docker officielle

curl -fsSL https://get.docker.com -o get-docker.sh

sudo sh get-docker.sh

# Ajouter l'utilisateur au groupe docker

sudo usermod -aG docker $USER

newgrp docker

# Vérifier l'installation

docker --version

docker compose version

Le docker-compose.yml complet

Créez le dossier de travail et le fichier docker-compose :

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

Voici le docker-compose.yml complet, commenté ligne par ligne :

version: '3.8'

services:

 postgres:
 image: postgres:16-alpine
 restart: unless-stopped
 # Les données PostgreSQL survivent aux redémarrages
 volumes:
 - postgres_data:/var/lib/postgresql/data
 environment:
 - POSTGRES_DB=${DB_POSTGRESDB_DATABASE}
 - POSTGRES_USER=${DB_POSTGRESDB_USER}
 - POSTGRES_PASSWORD=${DB_POSTGRESDB_PASSWORD}
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U $${DB_POSTGRESDB_USER}"]
 interval: 10s
 timeout: 5s
 retries: 5

 n8n:
 image: n8nio/n8n:latest
 restart: unless-stopped
 ports:
 # Exposé en local uniquement — nginx fait le proxy
 - "127.0.0.1:5678:5678"
 volumes:
 - n8n_data:/home/node/.n8n
 env_file:
 - .env
 depends_on:
 postgres:
 condition: service_healthy

volumes:
 postgres_data:
 n8n_data:

Astuce AutomateIA : Notez le binding 127.0.0.1:5678:5678 — N8N n'est accessible que depuis localhost, jamais directement depuis internet. Nginx sera l'unique point d'entrée public, ce qui est bien plus sécurisé qu'exposer N8N directement.

Lancer les conteneurs

# Lancer en arrière-plan

docker compose up -d

# Vérifier l'état des conteneurs

docker compose ps

# Voir les logs en temps réel

docker compose logs -f n8n

Configuration nginx et SSL

Nginx joue le rôle de reverse proxy : il reçoit les requêtes HTTPS depuis internet et les transmet au conteneur N8N sur le port 5678. C'est aussi lui qui gère le certificat SSL.

Installer nginx et certbot

sudo apt install nginx certbot python3-certbot-nginx -y

Configuration nginx pour N8N

Créez le fichier /etc/nginx/sites-available/n8n :

server {
listen 80;
server_name n8n.votre-domaine.fr;

location / {
proxy_pass http://127.0.0.1:5678;
proxy_http_version 1.1;
 # Headers essentiels pour les WebSockets N8N
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
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;
 # Timeout élevé pour les longues exécutions
proxy_read_timeout 300s;
proxy_connect_timeout 75s;
}
}

# Activer le site et tester la config

sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/

sudo nginx -t

sudo systemctl reload nginx

# Obtenir le certificat SSL Let's Encrypt

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

Certbot modifie automatiquement la configuration nginx pour ajouter le HTTPS et configurer le renouvellement automatique. Vérifiez que le renouvellement fonctionne :

sudo certbot renew --dry-run

Variables d'environnement essentielles

Le fichier .env est le cœur de votre configuration. Une erreur ici peut rendre votre instance inutilisable ou vulnérable. Voici les variables indispensables et leur rôle :

# ============================================
# CONFIGURATION DE BASE N8N
# ============================================

# L'URL publique de votre instance (OBLIGATOIRE pour les webhooks)
WEBHOOK_URL=https://n8n.votre-domaine.fr/
N8N_HOST=n8n.votre-domaine.fr
N8N_PORT=5678
N8N_PROTOCOL=https

# Clé de chiffrement des credentials (générer une fois, ne JAMAIS changer)
# Générer avec : openssl rand -base64 32
N8N_ENCRYPTION_KEY=votre_cle_de_32_caracteres_aleatoires

# ============================================
# BASE DE DONNÉES POSTGRESQL
# ============================================
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8nuser
DB_POSTGRESDB_PASSWORD=mot_de_passe_fort_ici

# ============================================
# AUTHENTIFICATION ET SÉCURITÉ
# ============================================
N8N_BASIC_AUTH_ACTIVE=false
# Activer la gestion multi-utilisateurs (recommandé)
N8N_USER_MANAGEMENT_DISABLED=false

# ============================================
# COMPORTEMENT DES EXÉCUTIONS
# ============================================
# Nombre de jours de rétention des logs d'exécution
EXECUTIONS_DATA_MAX_AGE=30
# Sauvegarder toutes les exécutions (pas seulement les erreurs)
EXECUTIONS_DATA_SAVE_ON_SUCCESS=all
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true

# Timezone (important pour les triggers cron)
GENERIC_TIMEZONE=Europe/Paris

Attention critique : La valeur de N8N_ENCRYPTION_KEY chiffre tous vos credentials (mots de passe API, tokens). Si vous la changez ou la perdez, tous vos credentials deviennent illisibles et vous devrez les re-saisir un par un. Générez-la une seule fois et sauvegardez-la dans un gestionnaire de mots de passe.

Configurer PostgreSQL pour la production

SQLite est utilisé par défaut dans N8N et convient pour le développement. Pour la production, PostgreSQL est non négociable : il gère la concurrence, supporte les sauvegardes à chaud et résiste aux pannes.

Pourquoi PostgreSQL est obligatoire en production

Concurrence : SQLite verrouille toute la base lors d'une écriture. Avec 10 workflows actifs simultanément, vous aurez des timeouts et des erreurs
Intégrité des données : PostgreSQL est ACID-compliant et résiste aux crashs serveur. SQLite peut se corrompre si le serveur s'éteint brutalement
Sauvegardes : pg_dump permet des sauvegardes cohérentes à chaud sans arrêter N8N
Performance : Au-delà de quelques milliers d'exécutions, PostgreSQL est nettement plus rapide pour les requêtes complexes

Optimisations PostgreSQL recommandées

Pour les configurations de production, ajoutez ces paramètres à votre service PostgreSQL dans docker-compose.yml :

 postgres:
 command: postgres
 -c max_connections=200
 -c shared_buffers=256MB
 -c effective_cache_size=768MB
 -c maintenance_work_mem=64MB
 -c wal_buffers=16MB

Astuce AutomateIA : Activez le pruning automatique des anciennes exécutions avec la variable EXECUTIONS_DATA_MAX_AGE=30 (30 jours de rétention). Sans cela, la base PostgreSQL grossit indéfiniment et ralentit progressivement N8N.

Vérifier la connexion PostgreSQL

# Se connecter au conteneur PostgreSQL

docker compose exec postgres psql -U n8nuser -d n8n

# Vérifier les tables créées par N8N

\dt

# Quitter

\q

Sauvegardes automatiques des workflows

Une instance N8N sans sauvegarde est une bombe à retardement. Vos workflows représentent des heures de travail et une valeur business réelle. La stratégie de sauvegarde doit être mise en place avant la mise en production, pas après le premier incident.

Stratégie de sauvegarde recommandée

Combinez deux méthodes complémentaires :

Dump PostgreSQL quotidien : sauvegarde complète de toutes les données (workflows, exécutions, credentials chiffrés)
Export JSON des workflows via API : sauvegarde lisible et versionnable des définitions de workflows uniquement

Script de sauvegarde automatisé

Créez le fichier /opt/n8n/backup.sh :

#!/bin/bash

BACKUP_DIR="/opt/n8n/backups"

DATE=$(date +%Y%m%d_%H%M%S)

RETENTION_DAYS=30

# Créer le dossier si nécessaire

mkdir -p $BACKUP_DIR

# Dump PostgreSQL

docker compose -f /opt/n8n/docker-compose.yml exec -T postgres \

  pg_dump -U n8nuser n8n | gzip > "$BACKUP_DIR/n8n_db_$DATE.sql.gz"

# Sauvegarder le fichier .env (SANS le commit dans git !)

cp /opt/n8n/.env "$BACKUP_DIR/env_$DATE.bak"

# Nettoyage des sauvegardes trop anciennes

find $BACKUP_DIR -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete

find $BACKUP_DIR -name "*.bak" -mtime +$RETENTION_DAYS -delete

echo "Sauvegarde terminée : $DATE"

# Rendre le script exécutable

chmod +x /opt/n8n/backup.sh

# Programmer via cron : tous les jours à 3h du matin

crontab -e
# Ajouter cette ligne :

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

Bon à savoir : Stockez les sauvegardes sur un serveur distinct. Une sauvegarde sur le même serveur que la production ne protège pas contre la panne matérielle ou le crash disque. OVH Object Storage et Scaleway Object Storage offrent des solutions économiques dès 0,01€/Go/mois.

Tester la restauration

Une sauvegarde non testée n'est pas une sauvegarde. Testez la restauration au moins une fois par mois :

# Restaurer depuis un dump PostgreSQL

gunzip -c /opt/n8n/backups/n8n_db_20260522_030000.sql.gz | \

  docker compose exec -T postgres psql -U n8nuser n8n

Mise à jour N8N sans downtime

N8N sort des mises à jour fréquentes (environ 2 à 4 par mois). Une procédure de mise à jour rigoureuse évite les interruptions de service et les régressions.

Procédure de mise à jour recommandée

Consultez les release notes sur github.com/n8n-io/n8n/releases. Repérez les "breaking changes" qui peuvent nécessiter des ajustements dans vos workflows.
Faites une sauvegarde avant toute mise à jour : /opt/n8n/backup.sh
Mettez en pause les workflows critiques depuis l'interface N8N (bouton toggle sur chaque workflow actif)
Mettez à jour l'image dans docker-compose.yml si vous utilisez un tag de version fixe, ou lancez directement le pull :

cd /opt/n8n

# Télécharger la nouvelle image

docker compose pull

# Redémarrer le service (interruption ~30 secondes)

docker compose up -d n8n

# Vérifier que tout fonctionne

docker compose ps

docker compose logs --tail=50 n8n

Astuce AutomateIA : Plutôt que d'utiliser n8nio/n8n:latest, épinglez une version spécifique dans docker-compose.yml (n8nio/n8n:1.82.0 par exemple). Cela évite les mises à jour automatiques non voulues et vous donne le contrôle total du moment de la mise à jour.

En cas de problème après mise à jour

Si la mise à jour cause des problèmes, revenez à la version précédente :

# Modifier docker-compose.yml : image: n8nio/n8n:1.79.0

docker compose up -d n8n

# Si la base de données a été migrée, restaurer depuis backup
# (c'est pour ça qu'on sauvegarde avant chaque mise à jour)

Sécurité : hardening de votre instance

N8N expose une interface web avec accès à des credentials sensibles et la capacité d'exécuter des requêtes HTTP vers n'importe quelle API. La sécurisation est non négociable.

Authentification et gestion des utilisateurs

Depuis N8N 0.198, le système multi-utilisateurs est intégré. Configurez les rôles correctement :

Owner : accès complet, peut inviter des utilisateurs, voir tous les workflows
Admin : accès complet aux workflows, peut gérer les credentials
Member : accès aux workflows partagés uniquement

Lors du premier accès à votre instance, N8N vous demandera de créer le compte Owner. Utilisez un mot de passe fort (24 caractères minimum) et activez immédiatement le 2FA.

Variables d'environnement de sécurité

# Activer le 2FA pour tous les utilisateurs
N8N_MFA_ENABLED=true

# Désactiver les diagnostics envoyés à N8N (RGPD)
N8N_DIAGNOSTICS_ENABLED=false

# Désactiver le rapport de version public
N8N_VERSION_NOTIFICATIONS_ENABLED=false

# Limiter les templates téléchargeables (optionnel)
N8N_TEMPLATES_ENABLED=false

# Timeout des sessions (en secondes)
N8N_USER_MANAGEMENT_JWT_DURATION_HOURS=8

Restriction d'accès par IP

Si seules des IPs connues doivent accéder à l'interface N8N (équipe interne, VPN), ajoutez dans nginx :

# Dans le bloc location / de nginx

allow 92.168.1.0/24;  # IP de votre bureau

allow 185.66.12.45;  # IP du VPN

deny all;

# Mais toujours autoriser les webhooks depuis n'importe où
# Créez un sous-bloc location /webhook/ sans restriction

Attention : Si vous restreignez l'accès par IP à l'interface N8N, veillez à laisser les chemins /webhook/ et /webhook-test/ accessibles sans restriction — sinon vos webhooks depuis des services tiers (Stripe, GitHub, etc.) seront bloqués.

Monitoring et alertes

Une instance N8N non monitorée peut silencieusement tomber en panne pendant des heures. Le monitoring proactif vous alerte avant que les utilisateurs ne se plaignent.

Health check N8N

N8N expose un endpoint de santé sur /healthz. Configurez une vérification externe toutes les 5 minutes :

# Test manuel du health check

curl https://n8n.votre-domaine.fr/healthz
# Réponse attendue : {"status":"ok"}

Utilisez des services de monitoring externes gratuits comme UptimeRobot ou Better Uptime pour surveiller cet endpoint.

Logs Docker

# Logs en temps réel

docker compose logs -f n8n

# 100 dernières lignes avec timestamps

docker compose logs --tail=100 --timestamps n8n

# Activer les logs détaillés dans .env
N8N_LOG_LEVEL=info # options: error, warn, info, debug
N8N_LOG_OUTPUT=console,file
N8N_LOG_FILE_LOCATION=/home/node/.n8n/logs/n8n.log

Workflow d'alerte interne

Créez un workflow N8N de monitoring qui s'exécute toutes les heures et vous alerte si des workflows ont échoué. Consultez notre guide sur la gestion des erreurs N8N pour implémenter les alertes email et Slack.

Besoin d'aide pour configurer votre instance N8N ?

Notre équipe déploie et configure des instances N8N self-hosted en production pour des PME françaises. Audit de votre architecture, mise en place du monitoring, formation de vos équipes.

Obtenir mon audit gratuit

Scalabilité : queue mode et workers

Pour les entreprises avec des volumes importants de workflows, N8N propose un mode "queue" qui distribue les exécutions sur plusieurs processus workers. Ce mode nécessite Redis en plus de PostgreSQL.

Quand passer en queue mode ?

Plus de 50 workflows actifs simultanément
Des workflows avec des exécutions longues (>5 minutes)
Des pics de charge prévisibles (ex. envoi de emails en batch)
Besoin de haute disponibilité avec plusieurs instances N8N

Architecture queue mode

1 Main + N Workers

Architecture queue mode N8N

Dans cette architecture :

Le processus Main : gère l'interface web, les webhooks et met les tâches en file d'attente Redis
Les Workers : récupèrent les tâches depuis Redis et les exécutent. Vous pouvez en lancer autant que nécessaire

Configuration docker-compose pour le queue mode

Ajoutez Redis et un service worker à votre docker-compose.yml :

 redis:
 image: redis:7-alpine
 restart: unless-stopped
 volumes:
 - redis_data:/data

 n8n-worker:
 image: n8nio/n8n:latest
 restart: unless-stopped
 command: n8n worker
 env_file:
 - .env
 depends_on:
 - n8n
 - redis
 - postgres

Ajoutez aussi les variables Redis dans votre .env :

 EXECUTIONS_MODE=queue
 QUEUE_BULL_REDIS_HOST=redis
 QUEUE_BULL_REDIS_PORT=6379
 QUEUE_HEALTH_CHECK_ACTIVE=true

Pour scaler horizontalement, lancez plusieurs workers : docker compose up -d --scale n8n-worker=3. Chaque worker ajoute de la capacité d'exécution parallèle.

Pour aller plus loin avec N8N et maîtriser la gestion des erreurs dans vos workflows, consultez notre guide complet sur le débogage et la gestion des erreurs N8N. Pour comprendre comment intégrer N8N dans votre stratégie d'automatisation globale, notre page dédiée N8N présente tous les cas d'usage pour les PME françaises. Vous pouvez aussi consulter le guide débutant automatisation IA pour cadrer votre stratégie globale avant de déployer votre infrastructure.

Questions fréquentes

Quelle est la configuration serveur minimale pour N8N en production ?

Pour une instance N8N en production avec une utilisation raisonnable (moins de 100 workflows, quelques centaines d'exécutions par jour), comptez au minimum 2 vCPU, 4 Go de RAM et 40 Go de SSD. Pour une charge plus importante, passez à 4 vCPU et 8 Go de RAM. Le coût d'un VPS de ce type est de l'ordre de 10 à 20€/mois chez des hébergeurs comme Hetzner, OVH ou Scaleway.

Peut-on utiliser SQLite en production avec N8N ?

Techniquement oui, mais ce n'est pas recommandé pour un usage professionnel. SQLite ne gère pas correctement la concurrence et peut corrompre ses données en cas de crash serveur. Pour la production, PostgreSQL est obligatoire : il supporte la haute disponibilité, les sauvegardes propres et gère des milliers d'exécutions simultanées sans problème.

Comment gérer les mises à jour N8N sans interrompre les workflows en cours ?

La procédure recommandée est : 1) Mettre en pause les workflows actifs depuis l'interface N8N. 2) Faire une sauvegarde PostgreSQL. 3) Changer le tag d'image dans docker-compose.yml vers la nouvelle version. 4) Lancer docker compose pull puis docker compose up -d. L'interruption est généralement inférieure à 30 secondes. Pour zéro downtime, configurez le mode queue avec plusieurs workers.

N8N self-hosted est-il conforme au RGPD ?

Oui, et c'est précisément l'un des principaux avantages. En self-hostant N8N sur un serveur en Europe (ou chez vous), vos données de workflow et d'exécution ne quittent jamais votre infrastructure. Contrairement à N8N Cloud (hébergé aux États-Unis), vous gardez la maîtrise complète de la localisation et du traitement des données personnelles.

Comment sauvegarder les workflows N8N automatiquement ?

La méthode la plus fiable est un dump PostgreSQL quotidien automatisé via cron : pg_dump -U n8n n8n | gzip > /backups/n8n_$(date +%Y%m%d).sql.gz. Combinez cela avec l'export JSON des workflows via l'API N8N pour une double redondance. Stockez les sauvegardes sur un serveur distant ou un service de stockage objet (S3, OVH Object Storage).

Quelle est la différence entre N8N en mode standard et en mode queue ?

En mode standard, N8N exécute tous les workflows sur un seul processus. En mode queue, il utilise une architecture avec un processus principal et des workers séparés pour exécuter les workflows. Le mode queue est nécessaire dès que vous avez plus de 50 workflows actifs simultanément ou des workflows avec des exécutions longues. Il nécessite Redis en plus de PostgreSQL.

Comment configurer le 2FA sur une instance N8N self-hosted ?

N8N intègre le 2FA (TOTP) nativement depuis la version 0.227. Chaque utilisateur peut l'activer dans les paramètres de son compte. Pour le forcer pour tous les utilisateurs, définissez N8N_MFA_ENABLED=true dans vos variables d'environnement. Utilisez une application comme Google Authenticator ou Bitwarden pour scanner le QR code.

Mon instance N8N est-elle accessible depuis internet ? Est-ce sécurisé ?

Oui, pour que les webhooks fonctionnent, N8N doit être accessible via HTTPS depuis internet. La sécurité passe par : HTTPS obligatoire (Let's Encrypt), authentification activée, restriction des IPs admin si possible, mise à jour régulière, et monitoring des tentatives d'accès. N8N ne doit jamais être exposé en HTTP non chiffré.