Guide complet de dépannage de n8n auto-hébergé 2025 : résoudre les problèmes de taille des données d’exécution et de webhooks avec Traefik

Dernière mise à jour : 15 octobre 2025

L’auto-hébergement de n8n offre des exécutions de flux de travail illimitées, un contrôle total des données et des économies significatives par rapport aux offres cloud. Mais en réalité, les instances auto-hébergées font face à des difficultés que les utilisateurs de n8n Cloud n’ont généralement pas à gérer — notamment autour de la gestion des gros volumes de données et de la configuration des webhooks avec les proxys inverses.

En juin 2025, nous avons publié deux guides de dépannage traitant ces problèmes séparément. Le problème est qu’aucun guide complet n’existe pour les déploiements n8n en production avec le proxy inverse Traefik qui aborde les deux problèmes courants ensemble.

Ce guide combine les deux correctifs originaux, fournit une configuration Traefik complète avec prise en charge de WebSocket, inclut les nouvelles exigences des exécuteurs de tâches de 2025 et livre des fichiers docker-compose prêts pour la production que vous pouvez déployer immédiatement.

Table des matières

Diagnostic rapide : quel problème avez-vous ?
Comprendre les deux problèmes principaux
Correctif n°1 : erreur de données d’exécution trop volumineuses
Correctif n°2 : problèmes d’URL de webhooks
Configuration de production complète avec Traefik
Exigence 2025 : Exécuteurs de tâches
Référence des variables d’environnement
Exemples Docker Compose
Tester votre configuration
Dépannage des problèmes courants

Diagnostic rapide : quel problème avez-vous ?

Symptôme : « Existing execution data is too large »

Vous voyez cette erreur quand :

Vous cliquez sur « Execute Node » pendant le développement d’un flux de travail
Vous testez des flux de travail avec de grands ensembles de données ou de nombreux éléments
Vous utilisez le mode d’exécution partielle (test de nœuds individuels)
Vous traitez des transformations complexes avec plusieurs branches

Il vous faut : Correctif n°1 : taille des données d’exécution

Symptôme : les webhooks affichent des URL incorrectes ou ne fonctionnent pas

Vous constatez cela quand :

Les URL des webhooks s’affichent avec des numéros de port (par exemple : :5678)
Les services externes (Slack, GitHub, Stripe) ne peuvent pas atteindre vos webhooks
Les webhooks fonctionnent en mode test mais échouent en production
Vous utilisez un proxy inverse (Nginx, Traefik, Caddy)

Il vous faut : Correctif n°2 : configuration des URL de webhooks

Symptôme : avertissements d’obsolescence concernant les exécuteurs de tâches

Vous voyez dans les journaux :

Running n8n without task runners is deprecated. Task runners will be
turned on by default in a future version.

Il vous faut : Configuration des exécuteurs de tâches

Symptôme : vous souhaitez une configuration complète prête pour la production

Il vous faut :

Les deux correctifs appliqués correctement
Le proxy inverse Traefik avec HTTPS automatique
Les bonnes pratiques de production et la sécurité
Les limites de ressources et une surveillance appropriée

Aller à : Configuration de production complète

Comprendre les deux problèmes principaux

Pourquoi les utilisateurs de n8n Cloud rencontrent rarement ces problèmes

Sur n8n Cloud, n8n gère pour vous la configuration du serveur, notamment les URL de webhooks, le stockage des données binaires et les mises à jour. Lorsque vous auto-hébergez, vous êtes responsable de ces configurations.

Les causes profondes

Problème n°1 : limite de taille des données d’exécution

La limite par défaut de 16 MiB pour les charges utiles des requêtes envoyées au backend, y compris les données d’exécution partielle déclenche des erreurs lors du travail avec de grands ensembles de données, de nombreuses branches de flux de travail ou des transformations complexes. Le problème est que le développement de flux de travail devient frustrant — vous ne pouvez pas tester les nœuds individuels pendant le développement. Le correctif est simple : la variable d’environnement N8N_PAYLOAD_SIZE_MAX.

Problème n°2 : génération des URL de webhooks

n8n tente de détecter automatiquement votre URL publique, mais cette détection automatique échoue derrière un proxy inverse. Les services externes reçoivent des URL de webhooks incorrectes avec des ports ou des noms d’hôtes internes — les intégrations échouent silencieusement. Le correctif : la variable d’environnement WEBHOOK_URL.

Correctif n°1 : erreur « Execution Data Too Large »

Le problème en détail

Lorsque vous exécutez seulement une partie d’un flux de travail (en cliquant sur « Execute Node » dans l’éditeur), n8n doit charger les données d’exécution précédentes pour fournir le contexte à ce nœud. Par défaut, n8n limite cette requête à 16 MiB (N8N_PAYLOAD_SIZE_MAX=16 ; la valeur est exprimée en MiB) pour prévenir les problèmes de mémoire sur les serveurs plus petits. Si la requête est plus volumineuse, n8n (ou un proxy inverse dont la limite de taille du corps est inférieure) répond avec HTTP 413, et l’éditeur affiche cette erreur.

Le message d’erreur

Selon la documentation officielle de n8n :

Please execute the whole workflow, rather than just the node.
(Existing execution data is too large.)

Cette erreur apparaît lors du traitement de milliers d’éléments dans un seul nœud, du travail avec de grandes réponses API en JSON, de la transformation de grands ensembles de données avec des nœuds Code ou de l’utilisation de flux de travail avec de nombreuses branches parallèles.

La solution : N8N_PAYLOAD_SIZE_MAX

Le correctif est simple mais nécessite de comprendre les ressources disponibles de votre serveur.

Paramètres recommandés selon la RAM du serveur

RAM du serveur	N8N_PAYLOAD_SIZE_MAX	Valeur à définir (MiB)	Pourcentage de la RAM
2 Go ou moins	64 Mo	`64`	~3 %
4 Go	128 Mo	`128`	~3 %
8 Go	256 Mo	`256`	~3 %
16 Go+	512 Mo	`512`	~3 %

Règle générale : utilisez moins de 20 % de votre RAM disponible pour maintenir le système stable sous charge.

Mise en œuvre Docker Compose

version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_PORT=5678

      # Payload size fix (256MB for 8GB+ RAM servers; value in MiB)
      - N8N_PAYLOAD_SIZE_MAX=256

      # Binary data optimization (highly recommended)
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
      - N8N_BINARY_DATA_TTL=1440  # 24 hours

    volumes:
      - n8n_data:/home/node/.n8n

    # Resource limits (adjust based on your server)
    deploy:
      resources:
        limits:
          memory: 2G
        reservations:
          memory: 1G

volumes:
  n8n_data:

Comprendre le mode de données binaires

Par défaut : stockage en mémoire (non recommandé)

# This is the default - DON'T use in production
N8N_DEFAULT_BINARY_DATA_MODE=default

Problèmes : stocke les fichiers (images, PDF, etc.) en RAM, gaspille de la mémoire précieuse, inadapté aux charges de production, limite le nombre de fichiers que vous pouvez traiter.

D’après nos tests, le mode par défaut utilisait ~315 Mo de RAM au repos, contre 211 Mo avec le mode système de fichiers, soit ~100 Mo de mémoire en moins au repos.

Recommandé : stockage sur le système de fichiers

N8N_DEFAULT_BINARY_DATA_MODE=filesystem
N8N_BINARY_DATA_TTL=1440  # Clean up after 24 hours (value in minutes)

Avantages : stocke les fichiers sur disque plutôt qu’en RAM, performances nettement meilleures avec les gros fichiers, prêt pour la production et recommandé par n8n. N8N_BINARY_DATA_TTL n’a plus d’effet depuis n8n 1.9.0 : n8n supprime les données binaires lors de la purge des exécutions. Les paramètres de purge des exécutions contrôlent donc l’utilisation du disque.

Important : Si vous utilisez le mode file d’attente (exécution distribuée basée sur Redis), sachez que n8n n’y prend pas en charge le mode système de fichiers. En octobre 2026, la documentation de n8n recommande le mode database pour le mode file d’attente.

Impact réel

D’après nos tests Docker en octobre 2025 avec la version n8n 1.115.2 :

Configuration	Utilisation de la mémoire	Différence
Par défaut (sans correctifs)	315 Mo	Référence
Avec correctif de charge utile + stockage sur le système de fichiers	211 Mo	-104 Mo

Constat clé : Dans nos mesures au repos, la configuration avec le correctif de charge utile et le mode binaire sur système de fichiers utilisait moins de mémoire que la configuration par défaut. Nous n’avons pas mesuré la mémoire sous charge avec de grosses requêtes ; son utilisation dépend alors de vos flux de travail.

Correctif n°2 : problèmes d’URL de webhooks

Le problème en détail

Lorsque n8n génère des URL de webhooks pour les afficher dans l’éditeur et les enregistrer auprès des services externes, il tente de détecter automatiquement votre URL publique. Derrière un proxy inverse, cette détection automatique échoue de manière spectaculaire.

Ce que vous verrez (les mauvaises URL)

http://n8n.yourdomain.com:5678/webhook/abc123

Problèmes avec cette URL :

Numéro de port inclus (:5678) — les services externes ne peuvent généralement pas atteindre les ports non standard
Mauvais protocole (http au lieu de https) — de nombreux services exigent HTTPS
Nom d’hôte interne — peut être le nom du conteneur Docker au lieu du domaine public

Pourquoi les services externes échouent

Des services comme GitHub, Slack, Stripe, Zoom, Google Sheets et des centaines d’autres tentent d’envoyer des webhooks à ces URL incorrectes et échouent silencieusement. Vous configurez l’intégration, elle semble correcte dans l’interface, mais les notifications n’arrivent jamais.

La solution : variable d’environnement WEBHOOK_URL

Selon la documentation officielle de n8n :

« La variable d’environnement WEBHOOK_URL est utilisée pour définir manuellement l’URL du webhook afin que n8n puisse l’afficher dans l’interface de l’éditeur et enregistrer les URL de webhooks correctes auprès des services externes. Lors de l’exécution de n8n derrière un proxy inverse, il est important de définir cette variable. »

Configuration de base

environment:
  - WEBHOOK_URL=https://n8n.yourdomain.com
  - N8N_EDITOR_BASE_URL=https://n8n.yourdomain.com
  - N8N_PROTOCOL=https
  - N8N_HOST=n8n.yourdomain.com
  - N8N_TRUST_PROXY_HEADER=true
  - N8N_PROXY_HOPS=1

Rôle de chaque variable

WEBHOOK_URL (LA PLUS IMPORTANTE)

L’URL publique pour tous les points de terminaison des webhooks
Utilisée lors de l’enregistrement des webhooks auprès des services externes
Doit correspondre exactement à votre configuration Traefik/proxy inverse
Note de version : renommée depuis WEBHOOK_TUNNEL_URL dans la v0.227.0, l’ancien nom a été supprimé dans n8n 1.0

N8N_EDITOR_BASE_URL

L’URL d’accès à l’interface web de n8n
Généralement identique à WEBHOOK_URL
S’affiche dans la barre d’adresse du navigateur et dans les invitations par e-mail

N8N_PROTOCOL

Régler sur https pour la production (avec SSL/TLS)
Régler sur http uniquement pour les tests locaux
Doit correspondre à la terminaison de votre proxy inverse

N8N_HOST

Votre nom de domaine public uniquement
Ne pas inclure le protocole (https://) ni le port
Exemple : n8n.yourdomain.com et non https://n8n.yourdomain.com:443

N8N_TRUST_PROXY_HEADER

Ce n’est pas une variable documentée de n8n : elle ne figure pas dans la référence des variables d’environnement de n8n ; la définir n’a donc aucun effet documenté
La confiance accordée aux en-têtes du proxy (pour les adresses IP réelles des clients) est contrôlée par N8N_PROXY_HOPS
Vous pouvez l’omettre dans les exemples de ce guide

N8N_PROXY_HOPS

Régler sur 1 derrière un seul proxy inverse
Régler sur 2 derrière deux proxies (rare)
Indique à n8n à combien de couches de proxy faire confiance

Tester les URL de webhooks

Avant le correctif

Dans l’interface n8n, créez un nœud Webhook et vérifiez l’URL affichée :

http://n8n.example.com:5678/webhook/abc123  ❌ Wrong

Après le correctif

Le même nœud webhook affiche maintenant :

https://n8n.example.com/webhook/abc123  ✅ Correct

Différence critique : les services externes peuvent maintenant atteindre cette URL car elle utilise le port HTTPS standard 443 (géré par votre proxy inverse) au lieu du port interne 5678.

Configuration de production complète avec Traefik

Pourquoi Traefik ?

Traefik est un proxy inverse moderne parfaitement adapté aux déploiements Docker — HTTPS automatique via Let's Encrypt sans gestion manuelle des certificats, découverte de services détectant automatiquement les conteneurs via les labels Docker, prise en charge native de WebSocket pour la connexion en direct de l’éditeur n8n, configuration facile avec de simples labels Docker au lieu de fichiers de configuration complexes, et un tableau de bord intégré pour surveiller le routage et les certificats en temps réel.

Vue d’ensemble de l’architecture

Internet
  ↓
[Traefik Reverse Proxy]
  ↓ HTTPS (Let's Encrypt)
  ↓ WebSocket Support
[Conteneur n8n]
  ↓ Réseau interne
[Base de données PostgreSQL]

Prise en charge de WebSocket

Traefik relaie nativement les connexions WebSocket, dont la connexion en direct de l’éditeur n8n ; aucun middleware supplémentaire n’est donc nécessaire. Les webhooks sont des requêtes HTTPS ordinaires et ne dépendent pas de WebSocket. L’exemple de production ci-dessous inclut des labels d’en-têtes WebSocket facultatifs ; vous pouvez les omettre.

Docker Compose de production complet

Cette configuration combine les deux correctifs, inclut Traefik avec une prise en charge appropriée de WebSocket et suit les bonnes pratiques de production :

version: '3.8'

networks:
  traefik-net:
    external: true
  n8n-internal:
    internal: true

services:
  # PostgreSQL Database
  postgres:
    image: postgres:16-alpine
    container_name: n8n-postgres
    restart: unless-stopped
    networks:
      - n8n-internal
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${DB_PASSWORD}
      - POSTGRES_DB=n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s
      timeout: 5s
      retries: 5
    deploy:
      resources:
        limits:
          memory: 512M

  # n8n Application
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - traefik-net
      - n8n-internal

    # Traefik Configuration Labels
    labels:
      # Enable Traefik for this container
      - "traefik.enable=true"
      - "traefik.docker.network=traefik-net"

      # Router configuration
      - "traefik.http.routers.n8n.rule=Host(`${N8N_DOMAIN}`)"
      - "traefik.http.routers.n8n.entrypoints=websecure"
      - "traefik.http.routers.n8n.tls.certresolver=letsencrypt"

      # Service configuration
      - "traefik.http.services.n8n.loadbalancer.server.port=5678"

      # Middleware: Request size limit in bytes (256MB, matches N8N_PAYLOAD_SIZE_MAX)
      - "traefik.http.middlewares.n8n-buffering.buffering.maxRequestBodyBytes=268435456"

      # Middleware: WebSocket headers (optional; Traefik proxies WebSockets natively)
      - "traefik.http.middlewares.n8n-websocket.headers.customrequestheaders.Upgrade=websocket"
      - "traefik.http.middlewares.n8n-websocket.headers.customrequestheaders.Connection=Upgrade"

      # Middleware: Security headers
      - "traefik.http.middlewares.n8n-security.headers.customResponseHeaders.X-Robots-Tag=noindex,nofollow"
      - "traefik.http.middlewares.n8n-security.headers.sslProxyHeaders.X-Forwarded-Proto=https"

      # Apply ALL middlewares
      - "traefik.http.routers.n8n.middlewares=n8n-buffering,n8n-websocket,n8n-security"

    environment:
      # Database Configuration
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${DB_PASSWORD}

      # FIX #2: Webhook URL Configuration
      - WEBHOOK_URL=https://${N8N_DOMAIN}
      - N8N_EDITOR_BASE_URL=https://${N8N_DOMAIN}
      - N8N_PROTOCOL=https
      - N8N_HOST=${N8N_DOMAIN}
      - N8N_PORT=5678
      - N8N_TRUST_PROXY_HEADER=true
      - N8N_PROXY_HOPS=1

      # FIX #1: Payload Size Configuration
      - N8N_PAYLOAD_SIZE_MAX=256  # 256 MiB

      # Binary Data Management
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
      - N8N_BINARY_DATA_TTL=1440  # 24 hours

      # 2025 Requirement: Task Runners
      - N8N_RUNNERS_ENABLED=true
      - N8N_RUNNERS_MODE=internal
      - N8N_RUNNERS_MAX_CONCURRENCY=5

      # Production Optimizations
      - NODE_ENV=production
      - EXECUTIONS_DATA_MAX_AGE=168  # 7 days
      - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
      - N8N_LOG_LEVEL=info
      - N8N_LOG_OUTPUT=console

      # Timezone (adjust to your location)
      - GENERIC_TIMEZONE=America/New_York
      - TZ=America/New_York

      # Security
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}

    volumes:
      - n8n_data:/home/node/.n8n

    # Resource Limits (8GB+ RAM server)
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: '2.0'
        reservations:
          memory: 1G
          cpus: '1.0'

    # Health Check
    healthcheck:
      test: ["CMD", "wget", "--quiet", "--tries=1", "--spider", "http://localhost:5678/healthz"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

volumes:
  n8n_data:
  postgres_data:

Configuration de Traefik

Si vous n’avez pas encore Traefik en fonctionnement, voici la configuration complète :

Étape 1 : créer le réseau Traefik

docker network create traefik-net

Étape 2 : créer la configuration Traefik

Créez traefik/traefik.yml :

api:
  dashboard: true

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
  websecure:
    address: ":443"

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false
    network: traefik-net

certificatesResolvers:
  letsencrypt:
    acme:
      email: [email protected]  # CHANGE THIS
      storage: /letsencrypt/acme.json
      httpChallenge:
        entryPoint: web

log:
  level: INFO

accessLog: {}

Étape 3 : créer le Docker Compose de Traefik

Créez traefik/docker-compose.yml :

version: '3.8'

networks:
  traefik-net:
    external: true

services:
  traefik:
    image: traefik:v2.10
    container_name: traefik
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    networks:
      - traefik-net
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"  # Dashboard (secure this in production!)
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./traefik.yml:/traefik.yml:ro
      - ./letsencrypt:/letsencrypt
    labels:
      - "traefik.enable=true"

Étape 4 : créer le fichier d’environnement

Créez .env dans votre répertoire n8n :

# Domain Configuration
N8N_DOMAIN=n8n.yourdomain.com

# Database Password (generate secure password)
DB_PASSWORD=your_secure_db_password_here

# n8n Encryption Key (generate random string)
N8N_ENCRYPTION_KEY=your_encryption_key_here

Générer des valeurs sécurisées :

# For DB_PASSWORD
openssl rand -base64 32

# For N8N_ENCRYPTION_KEY
openssl rand -hex 32

Étape 5 : tout lancer

# Start Traefik first
cd traefik
docker compose up -d

# Wait a few seconds, then start n8n
cd ../n8n
docker compose up -d

# Watch logs to verify startup
docker compose logs -f n8n

Vérifier votre configuration

Vérifier le tableau de bord Traefik

Visitez http://your-server-ip:8080. Cela fonctionne uniquement si vous définissez aussi api.insecure: true dans traefik.yml (pour les tests uniquement) ; sinon, configurez un routeur pour le tableau de bord (api@internal) sur son propre domaine.

Doit afficher :

Routeur n8n actif avec statut vert
Certificat obtenu de Let's Encrypt
Service marqué comme sain

Vérifier l’accès à n8n

Visitez https://n8n.yourdomain.com

Doit afficher :

HTTPS fonctionnel avec un certificat Let's Encrypt valide
Aucun avertissement de sécurité du navigateur
La page de connexion/configuration de n8n s’affiche correctement

Vérifier les URL des webhooks

Connectez-vous à n8n
Créez un nouveau flux de travail
Ajoutez un nœud Webhook
Vérifiez l’« URL de production » affichée

Attendu :

https://n8n.yourdomain.com/webhook/abc123

PAS ceci (la configuration est incorrecte) :

http://n8n.yourdomain.com:5678/webhook/abc123  ❌

Exigence 2025 : exécuteurs de tâches

Que sont les exécuteurs de tâches ?

Les exécuteurs de tâches exécutent le code défini dans les nœuds Code au sein de processus isolés plutôt que dans le processus principal de n8n. Cela offre une meilleure sécurité grâce à des environnements en bac à sable, une stabilité améliorée où les erreurs de code ne font pas planter le processus principal, et une compatibilité future car ils seront requis dans les prochaines versions de n8n.

Pourquoi c’est important maintenant

D’après la documentation officielle de n8n :

« L’exécution de n8n sans exécuteurs de tâches est désormais déconseillée. Les exécuteurs de tâches seront activés par défaut dans une future version. Il est conseillé aux utilisateurs de définir N8N_RUNNERS_ENABLED=true dès maintenant pour éviter d’éventuels problèmes à l’avenir. »

D’après nos journaux de test (octobre 2025) :

There are deprecations related to your environment variables:
 - N8N_RUNNERS_ENABLED -> Running n8n without task runners is deprecated.

Configuration

Mode interne (recommandé pour un serveur unique)

environment:
  - N8N_RUNNERS_ENABLED=true
  - N8N_RUNNERS_MODE=internal
  - N8N_RUNNERS_MAX_CONCURRENCY=5

n8n lance l’exécuteur de tâches comme processus enfant — configuration la plus simple, aucune infrastructure supplémentaire nécessaire, adapté à la plupart des déploiements auto-hébergés, faible surcharge d’exécution. En octobre 2026, la documentation de n8n décrit le mode interne comme non sécurisé par conception et le déclare obsolète à partir de n8n 3.0.

Mode externe (pour les configurations distribuées)

environment:
  - N8N_RUNNERS_ENABLED=true
  - N8N_RUNNERS_MODE=external
  - N8N_RUNNERS_AUTH_TOKEN=your_secure_token

Des conteneurs d’exécuteurs de tâches séparés offrent une meilleure isolation des ressources pour les flux de travail à haut volume, permettent une mise à l’échelle horizontale sur plusieurs serveurs, et s’exécutent dans un conteneur sidecar issu de l’image n8nio/runners, dont la version doit correspondre à celle de votre image n8n. Une configuration Docker Compose suffit ; Docker Swarm et Kubernetes ne sont pas nécessaires.

Vérifier les exécuteurs de tâches

Vérifier la liste des processus

docker exec n8n ps aux

Sans exécuteurs de tâches (3 processus) :

PID   USER     TIME  COMMAND
    1 node      0:00 tini -- /docker-entrypoint.sh
    7 node      0:12 node /usr/local/bin/n8n

Avec exécuteurs de tâches (4 processus) :

PID   USER     TIME  COMMAND
    1 node      0:00 tini -- /docker-entrypoint.sh
    7 node      0:16 node /usr/local/bin/n8n
   18 node      0:10 node [...]/task-runner/dist/start.js

Preuve : processus de l’exécuteur de tâches visible avec le PID 18.

Vérifier les journaux

docker logs n8n | grep -i runner

Vous devriez voir :

n8n Task Broker ready on 127.0.0.1, port 5679
Registered runner "JS Task Runner" (zCWpF0Eb_LJsqWYvLm5t1)

Impact sur l’utilisation des ressources

D’après nos tests Docker (octobre 2025, version n8n 1.115.2) :

Configuration	Mémoire	CPU	Processus
Sans exécuteurs de tâches	214 Mo	0,14 %	3
Avec exécuteurs de tâches	289 Mo	0,29 %	4
Différence	+75 Mo	+0,15 %	+1

Faible surcharge. Les avantages — sécurité, stabilité, pérennité — l’emportent largement sur le faible coût en ressources.

Référence des variables d’environnement

Liste complète des variables

Variable	Type	Valeur par défaut	Fonction	Priorité
Variables critiques
`WEBHOOK_URL`	Chaîne de caractères	—	URL publique des webhooks	REQUIS avec proxy inverse
`N8N_PAYLOAD_SIZE_MAX`	Nombre	`16` (MiB)	Taille maximale de la charge utile des requêtes en MiB, y compris les données d’exécution partielle	REQUIS pour les gros volumes
`N8N_RUNNERS_ENABLED`	Booléen	`false`	Activer les exécuteurs de tâches	Recommandé sur 1.x (inutile à partir de n8n 2.0)
`N8N_TRUST_PROXY_HEADER`	–	–	Ne figure pas parmi les variables documentées de n8n	Inutile ; utilisez `N8N_PROXY_HOPS`
Configuration des webhooks
`N8N_EDITOR_BASE_URL`	Chaîne de caractères	—	URL de l’interface éditeur	Recommandé
`N8N_PROTOCOL`	Chaîne de caractères	`http`	Protocole (http/https)	Production
`N8N_HOST`	Chaîne de caractères	`localhost`	Nom d’hôte public	Production
`N8N_PORT`	Nombre	`5678`	Port interne	Optionnel
`N8N_PROXY_HOPS`	Nombre	`0`	Nombre de proxys inverses	Régler sur 1 avec proxy
Performance
`N8N_DEFAULT_BINARY_DATA_MODE`	Chaîne de caractères	`default`	Mode de stockage binaire	Recommandé
`N8N_BINARY_DATA_TTL`	–	–	Sans effet depuis n8n 1.9.0 (les données binaires sont purgées avec les exécutions)	Peut être supprimé
Exécuteurs de tâches
`N8N_RUNNERS_MODE`	Chaîne de caractères	`internal`	Mode de l’exécuteur de tâches	Si les exécuteurs sont activés
`N8N_RUNNERS_MAX_CONCURRENCY`	Nombre	`10`	Nombre maximal de tâches simultanées par exécuteur	Optionnel

Préréglages de configuration par scénario

Scénario A : développement (machine locale)

environment:
  - N8N_PORT=5678

À utiliser quand : tests en local, sans proxy inverse, sans exigences de production

Scénario B : derrière un proxy inverse (sans gros volumes de données)

environment:
  - N8N_PORT=5678
  - WEBHOOK_URL=https://n8n.yourdomain.com
  - N8N_EDITOR_BASE_URL=https://n8n.yourdomain.com
  - N8N_PROTOCOL=https
  - N8N_HOST=n8n.yourdomain.com
  - N8N_TRUST_PROXY_HEADER=true
  - N8N_PROXY_HOPS=1
  - N8N_RUNNERS_ENABLED=true

À utiliser quand : instance n8n publique, webhooks nécessaires, flux de travail de petite taille

Scénario C : configuration de production complète

environment:
  # Database
  - DB_TYPE=postgresdb
  - DB_POSTGRESDB_HOST=postgres
  - DB_POSTGRESDB_PORT=5432
  - DB_POSTGRESDB_DATABASE=n8n
  - DB_POSTGRESDB_USER=n8n
  - DB_POSTGRESDB_PASSWORD=${DB_PASSWORD}

  # Webhooks
  - WEBHOOK_URL=https://n8n.yourdomain.com
  - N8N_EDITOR_BASE_URL=https://n8n.yourdomain.com
  - N8N_PROTOCOL=https
  - N8N_HOST=n8n.yourdomain.com
  - N8N_PORT=5678
  - N8N_TRUST_PROXY_HEADER=true
  - N8N_PROXY_HOPS=1

  # Performance
  - N8N_PAYLOAD_SIZE_MAX=256  # 256 MiB
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
  - N8N_BINARY_DATA_TTL=1440

  # Task Runners
  - N8N_RUNNERS_ENABLED=true
  - N8N_RUNNERS_MODE=internal
  - N8N_RUNNERS_MAX_CONCURRENCY=5

  # Production
  - NODE_ENV=production
  - EXECUTIONS_DATA_MAX_AGE=168  # 7 days
  - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
  - N8N_LOG_LEVEL=info

  # Security
  - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}

À utiliser quand : déploiement de production avec toutes les fonctionnalités, gros flux de travail, accès public

Exemples Docker Compose

Les quatre scénarios de notre environnement de test sont disponibles. Ces configurations ont été validées avec la version n8n 1.115.2 en octobre 2025. Les exemples utilisent le tag d’image latest ; fixez n8nio/n8n:1.115.2 pour reproduire la version testée.

Comparaison de l’utilisation des ressources (d’après nos tests)

Scénario	Mémoire	CPU	Processus	Description
Par défaut	315 Mo	0,00 %	3	Sans correctifs, référence
Correctif de charge utile	211 Mo	0,00 %	3	Charge utile + stockage sur le système de fichiers
Correctif de webhook	215 Mo	0,14 %	3	Configuration webhook uniquement
Production	289 Mo	0,29 %	4	Tous les correctifs + exécuteurs de tâches

Constat clé : Au repos, la configuration de production avec tous les correctifs utilisait moins de mémoire que la configuration par défaut dans nos tests. Il s’agit de mesures au repos, et non de résultats sous charge avec de grosses requêtes.

Tester votre configuration

Liste de vérification avant déploiement

1. Configuration DNS

# Verify DNS points to your server
nslookup n8n.yourdomain.com

# Should return your server's public IP

2. Disponibilité des ports

# Check if required ports are free
sudo netstat -tlnp | grep -E '(80|443|5678)'

# Should show nothing or only Traefik on 80/443

3. Installation de Docker

# Verify Docker
docker --version

# Verify Docker Compose
docker compose version

4. Variables d’environnement

# Verify .env file exists
cat .env

# Should show N8N_DOMAIN, DB_PASSWORD, N8N_ENCRYPTION_KEY

Étapes de déploiement

# Step 1: Create Traefik network
docker network create traefik-net

# Step 2: Start Traefik
cd traefik
docker compose up -d

# Step 3: Wait for Traefik to be ready
sleep 10

# Step 4: Start n8n
cd ../n8n
docker compose up -d

# Step 5: Watch logs for any errors
docker compose logs -f n8n

Tests post-déploiement

Test 1 : accès HTTPS

curl -I https://n8n.yourdomain.com

Attendu : HTTP/2 200 (ou HTTP/1.1 200)

Test 2 : redirection HTTP vers HTTPS

curl -I http://n8n.yourdomain.com

Attendu : HTTP/1.1 308 Permanent Redirect avec Location: https://n8n.yourdomain.com

Test 3 : santé des conteneurs

docker ps

Attendu : n8n et n8n-postgres affichant le statut (healthy)

Test 4 : format des URL de webhooks

Connectez-vous à l’interface web de n8n
Créez un nouveau flux de travail
Ajoutez un nœud Webhook
Vérifiez l’URL de production affichée

Format attendu :

https://n8n.yourdomain.com/webhook/abc123

PAS attendu (erreur de configuration) :

http://n8n.yourdomain.com:5678/webhook/abc123  ❌

Test 5 : exécuteurs de tâches actifs

docker logs n8n | grep -i runner

Sortie attendue :

Registered runner "JS Task Runner"

Test 6 : variables d’environnement appliquées

docker exec n8n env | grep N8N_PAYLOAD_SIZE_MAX

Attendu : N8N_PAYLOAD_SIZE_MAX=256

Dépannage des problèmes courants

Problème : HTTPS ne fonctionne pas

Symptômes : le navigateur affiche l’avertissement « Non sécurisé », messages d’erreur de certificat, impossible d’accéder via HTTPS

Diagnostic :

# Check Traefik logs for errors
docker logs traefik | grep -i error

# Check certificate file exists
ls -la traefik/letsencrypt/acme.json

# Verify DNS resolution
nslookup n8n.yourdomain.com

Solutions :

DNS ne pointe pas vers le serveur : mettez à jour votre enregistrement DNS A pour pointer vers l’IP publique du serveur, attendez la propagation DNS (jusqu’à 24 heures, généralement beaucoup plus rapide), testez depuis un autre réseau : dig n8n.yourdomain.com +short
Port 80 bloqué : Let's Encrypt a besoin du port 80 pour le défi HTTP. Vérifiez le pare-feu : sudo ufw status. Autorisez si bloqué : sudo ufw allow 80/tcp && sudo ufw allow 443/tcp
E-mail invalide dans la configuration Traefik : éditez traefik/traefik.yml, mettez à jour certificatesResolvers.letsencrypt.acme.email avec une adresse valide, redémarrez Traefik : docker compose restart

Problème : les webhooks renvoient 404

Symptômes : les services externes signalent des échecs de webhooks, les URL de webhooks semblent correctes mais ne fonctionnent pas, le mode test fonctionne mais le mode production échoue

Diagnostic :

# Test webhook directly
curl -v https://n8n.yourdomain.com/webhook/test

# Check Traefik routing logs
docker logs traefik | grep webhook

# Verify n8n sees requests
docker logs n8n | grep webhook

Solutions :

WEBHOOK_URL mal configurée : vérifiez la variable d’environnement : docker exec n8n env | grep WEBHOOK_URL. Doit correspondre exactement à votre domaine : WEBHOOK_URL=https://n8n.yourdomain.com
Mauvaise configuration réseau : vérifiez que n8n est sur traefik-net : docker inspect n8n | grep -A 5 Networks. Doit afficher « traefik-net » dans la sortie

Problème : « Execution Data Too Large » persiste

Symptômes : l’erreur persiste après avoir défini N8N_PAYLOAD_SIZE_MAX, les gros flux de travail échouent à « Execute Node »

Diagnostic :

# Verify variable is set
docker exec n8n env | grep PAYLOAD

# Should show N8N_PAYLOAD_SIZE_MAX=256

Solutions :

Variable non appliquée (conteneur non recréé) : recréez le conteneur pour appliquer les modifications : docker compose up -d n8n (docker compose restart n’applique pas les valeurs d’environnement modifiées). Vérifiez ensuite : docker exec n8n env | grep PAYLOAD
Limite trop basse pour votre flux de travail : pour les serveurs avec 16 Go+ de RAM, augmentez à 512 Mo : N8N_PAYLOAD_SIZE_MAX=512
Taille de requête Traefik trop petite : augmentez également la limite Traefik (en octets) pour correspondre : "traefik.http.middlewares.n8n-buffering.buffering.maxRequestBodyBytes=536870912"

Problème : utilisation élevée de la mémoire

Symptômes : le conteneur utilise plus de 1,5 Go de RAM au repos, l’utilisation de la mémoire augmente avec le temps, erreurs de mémoire insuffisante

Diagnostic :

# Monitor memory
docker stats n8n

# Check binary data mode
docker exec n8n env | grep BINARY_DATA_MODE

Solutions :

Mode système de fichiers non utilisé : ajoutez à l’environnement : N8N_DEFAULT_BINARY_DATA_MODE=filesystem. Impact : ~100 Mo de mémoire en moins au repos dans nos tests
Anciennes exécutions accumulées : réduisez la période de rétention : EXECUTIONS_DATA_MAX_AGE=168 (7 jours au lieu de 14) et EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
Limite du conteneur trop basse : augmentez si le serveur a la capacité. Changez la limite mémoire de 2G à 4G dans la section deploy resources

Conclusion

Ce que nous avons résolu

Ce guide complet aborde les deux problèmes les plus courants de n8n auto-hébergé :

Erreur « Execution Data Too Large » — corrigée avec N8N_PAYLOAD_SIZE_MAX et le mode de stockage binaire sur le système de fichiers
Problèmes d’URL de webhooks — corrigés avec WEBHOOK_URL et une configuration appropriée du proxy inverse

Plus ces ajouts essentiels :

Configuration complète de Traefik — configuration prête pour la production avec prise en charge de WebSocket
Configuration des exécuteurs de tâches — exigence 2025 pour la compatibilité future
Bonnes pratiques de production — limites de ressources, contrôles de santé, en-têtes de sécurité, surveillance
Configurations validées — tous les fichiers docker-compose testés avec n8n 1.115.2 en octobre 2025

Points clés à retenir

Pour des correctifs rapides :

Définir N8N_PAYLOAD_SIZE_MAX=256 pour les problèmes de données d’exécution (256 Mo pour 8 Go+ de RAM)
Définir WEBHOOK_URL=https://your-domain.com pour les problèmes de webhooks
Définir N8N_RUNNERS_ENABLED=true pour éliminer les avertissements d’obsolescence
Utilisez N8N_DEFAULT_BINARY_DATA_MODE=filesystem (environ 100 Mo de mémoire en moins au repos dans nos tests)

Pour le déploiement en production :

Utilisez notre docker-compose.yml complet avec la configuration Traefik
Aucun middleware WebSocket nécessaire — Traefik relaie nativement WebSocket et les webhooks sont de simples requêtes HTTPS
Incluez PostgreSQL pour de meilleures performances sous charge
Définissez des limites de ressources appropriées en fonction de la capacité de votre serveur
Mettez en place des contrôles de santé pour que la surveillance et les services dépendants détectent les pannes (Docker seul marque le conteneur comme défaillant, mais ne le redémarre pas)

Pour les utilisateurs de Traefik (CRITIQUE) :

Traefik gère WebSocket sans middleware supplémentaire ; les webhooks nécessitent un routeur correct et WEBHOOK_URL
Définissez la limite de taille du corps de requête égale ou supérieure à la taille de la charge utile
Configurez les en-têtes de sécurité (X-Robots-Tag, X-Forwarded-Proto)
Assurez-vous que le DNS pointe vers votre serveur avant de démarrer Traefik (exigence Let's Encrypt)

Nouveautés par rapport aux articles de juin 2025

Fonctionnalité	Articles de juin 2025	Ce guide
Correctif données d’exécution	Détaillé	Inclus + mesures de ressources
Correctif webhook	Détaillé	Inclus + intégration Traefik
Configuration Traefik	Non traité	Configuration complète
Prise en charge de WebSocket	Non traité	Mis en avant
Exécuteurs de tâches	Non traité	Exigence 2025
Docker-compose combiné	Séparés	Prêt pour la production
Mesures de ressources	Théoriques	Données de tests réels
Variables d’environnement	Couvertes	Référence complète

Tests et validation

Notre environnement de test (octobre 2025) :

n8n version 1.115.2
Conteneurs Docker en fonctionnement depuis plus de 2 heures
Toutes les variables d’environnement vérifiées dans les conteneurs en cours d’exécution
Utilisation des ressources mesurée avec docker stats
Processus de l’exécuteur de tâches confirmé dans la liste des processus
Points de terminaison HTTP testés et accessibles
Configurations validées comme fonctionnelles

Prochaines étapes

Choisissez votre scénario :
- Développement : configuration minimale
- Derrière un proxy inverse : correctif webhook + exécuteurs de tâches
- Production : configuration complète avec Traefik (recommandé)
Déployez :
- Copiez le docker-compose.yml approprié
- Créez le fichier .env avec votre domaine et des mots de passe sécurisés
- Démarrez Traefik en premier, puis n8n
- Exécutez les tests post-déploiement
Validez :
- Vérifiez que HTTPS fonctionne avec un certificat valide
- Vérifiez que les URL de webhooks affichent le bon format
- Testez avec un grand ensemble de données (si nécessaire)
- Confirmez que les exécuteurs de tâches sont enregistrés
Surveillez :
- Observez l’utilisation des ressources avec docker stats
- Mettez en place des alertes de contrôle de santé (surveillance externe)
- Mettez en place la rotation des journaux pour éviter de remplir le disque
- Planifiez des sauvegardes régulières des volumes de données

Ressources associées

De juin 2025 :

Résoudre l’erreur n8n « Existing execution data is too large » — Guide de dépannage approfondi
Corriger les problèmes de webhooks n8n — Guide complet de débogage des webhooks

Documentation officielle de n8n :

Questions ou problèmes ?

Si vous rencontrez des problèmes non couverts par ce guide :

Consultez nos articles détaillés de dépannage de juin 2025 pour des conseils supplémentaires
Consultez la documentation officielle de n8n pour les dernières fonctionnalités
Recherchez sur les forums de la communauté n8n des problèmes similaires
Consultez la section Dépannage ci-dessus pour les problèmes courants
Contactez tva pour un accompagnement professionnel à la mise en œuvre

Tests reproductibles

Toutes les configurations de ce guide peuvent être reproduites dans votre propre environnement — les fichiers Docker Compose sont prêts pour la production, les variables d’environnement sont documentées et vérifiées, les commandes de test sont fournies pour la validation et les sorties attendues sont clairement spécifiées. Vous pouvez valider chaque affirmation de ce guide en déployant les configurations vous-même et en exécutant les tests fournis.

Besoin d’aide pour la mise en œuvre ?

Si vous souhaitez que tva gère votre déploiement n8n ou si vous avez besoin d’assistance pour la mise en production, contactez-nous. Nous mettons en œuvre ces configurations pour les organisations recherchant une infrastructure n8n fiable et prête pour la production.

Publié : 15 octobre 2025
Testé avec : n8n v1.115.2, Docker Compose v3.8, Traefik v2.10
Configuration serveur requise : 4 Go+ de RAM, 2+ cœurs CPU recommandés pour la production
Basé sur : la documentation officielle de n8n, des tests Docker validés et les bonnes pratiques de la communauté

Table des matières

Diagnostic rapide : quel problème avez-vous ?

Symptôme : « Existing execution data is too large »

Symptôme : les webhooks affichent des URL incorrectes ou ne fonctionnent pas

Symptôme : avertissements d’obsolescence concernant les exécuteurs de tâches

Symptôme : vous souhaitez une configuration complète prête pour la production

Comprendre les deux problèmes principaux

Pourquoi les utilisateurs de n8n Cloud rencontrent rarement ces problèmes

Les causes profondes

Correctif n°1 : erreur « Execution Data Too Large »

Le problème en détail

Le message d’erreur

La solution : N8N_PAYLOAD_SIZE_MAX

Paramètres recommandés selon la RAM du serveur

Mise en œuvre Docker Compose

Comprendre le mode de données binaires

Par défaut : stockage en mémoire (non recommandé)

Recommandé : stockage sur le système de fichiers

Impact réel

Correctif n°2 : problèmes d’URL de webhooks

Le problème en détail

Ce que vous verrez (les mauvaises URL)

Pourquoi les services externes échouent

La solution : variable d’environnement WEBHOOK_URL

Configuration de base

Rôle de chaque variable

Tester les URL de webhooks

Avant le correctif

Après le correctif

Configuration de production complète avec Traefik

Pourquoi Traefik ?

Vue d’ensemble de l’architecture

Prise en charge de WebSocket

Docker Compose de production complet

Configuration de Traefik

Étape 1 : créer le réseau Traefik

Étape 2 : créer la configuration Traefik

Étape 3 : créer le Docker Compose de Traefik

Étape 4 : créer le fichier d’environnement

Étape 5 : tout lancer

Vérifier votre configuration

Vérifier le tableau de bord Traefik

Vérifier l’accès à n8n

Vérifier les URL des webhooks

Exigence 2025 : exécuteurs de tâches

Que sont les exécuteurs de tâches ?

Pourquoi c’est important maintenant

Configuration

Mode interne (recommandé pour un serveur unique)

Mode externe (pour les configurations distribuées)

Vérifier les exécuteurs de tâches

Vérifier la liste des processus

Vérifier les journaux

Impact sur l’utilisation des ressources

Référence des variables d’environnement

Liste complète des variables

Préréglages de configuration par scénario

Scénario A : développement (machine locale)

Scénario B : derrière un proxy inverse (sans gros volumes de données)

Scénario C : configuration de production complète

Exemples Docker Compose

Comparaison de l’utilisation des ressources (d’après nos tests)

Tester votre configuration

Liste de vérification avant déploiement

1. Configuration DNS

2. Disponibilité des ports

3. Installation de Docker

4. Variables d’environnement

Étapes de déploiement

Tests post-déploiement

Test 1 : accès HTTPS

Test 2 : redirection HTTP vers HTTPS

Test 3 : santé des conteneurs

Test 4 : format des URL de webhooks

Test 5 : exécuteurs de tâches actifs

Test 6 : variables d’environnement appliquées

Dépannage des problèmes courants

Problème : HTTPS ne fonctionne pas

Problème : les webhooks renvoient 404

Problème : « Execution Data Too Large » persiste

Diagnostic rapide : quel problème avez-vous ?

Pourquoi Traefik ?

Que sont les exécuteurs de tâches ?

Questions ou problèmes ?

Besoin d’aide pour la mise en œuvre ?