n8n en mode queue avec Redis : passer à l'échelle ses workflows IA

Un pack qui tourne sans accroc en test — dix emails triés, cinquante pages de PDF ingérées — peut se comporter très différemment le jour où un client importe 3 000 emails d'un coup ou où toute une équipe interroge le chatbot RAG en même temps. Sur une instance n8n self-hosted classique, l'éditeur, l'API et l'exécution des workflows partagent le même processus : un pic de charge peut ralentir l'interface pendant que les exécutions s'accumulent. Le mode queue, qui répartit le travail entre une instance principale et des workers via Redis, résout exactement ce problème — à condition de savoir quand et comment l'activer.

Ce que fait n8n par défaut, et où ça coince

En configuration standard (EXECUTIONS_MODE=regular, la valeur par défaut), une seule instance n8n fait tout : elle sert l'interface, reçoit les webhooks, déclenche les crons et exécute chaque workflow. Cela fonctionne très bien jusqu'à un certain volume, mais présente deux limites concrètes pour des workflows IA :

• Contention CPU : un Code node qui traite un gros lot, ou plusieurs exécutions IA lancées en parallèle (voir notre article sur les erreurs 429 et le cadencement des appels IA), consomment les mêmes ressources que l'interface. Résultat : l'éditeur devient lent au moment précis où vous auriez besoin de surveiller une exécution.
• Panne de service unique : si le processus n8n plante ou redémarre, toutes les exécutions en cours sont perdues, y compris les webhooks qui attendaient une réponse.

Pour la grande majorité des indépendants et petites équipes, ce n'est pas un problème : les packs FlowKit tournent très bien en mode standard. Le mode queue devient pertinent à partir du moment où le volume réel dépasse ce qu'une seule instance absorbe confortablement — typiquement, une ingestion documentaire volumineuse (voir notre guide RAG avec Supabase pgvector) ou une boîte mail à fort trafic partagée par plusieurs services.

L'architecture du mode queue

Basculer EXECUTIONS_MODE sur queue change fondamentalement la répartition du travail :

1. L'instance principale continue de servir l'éditeur et l'API, reçoit les webhooks et déclenche les crons — mais au lieu d'exécuter le workflow elle-même, elle dépose un job dans une file d'attente Redis.
2. Redis stocke les jobs en attente. C'est le seul nouveau composant d'infrastructure à ajouter par rapport à une instance classique (elle-même connectée à PostgreSQL).
3. Un ou plusieurs workers — des processus n8n lancés avec la commande n8n worker — surveillent Redis, récupèrent les jobs disponibles et exécutent réellement les workflows, chacun en lisant les données nécessaires dans la même base PostgreSQL partagée.

Ce découplage change tout en cas de pic : l'instance principale reste réactive (elle ne fait plus qu'empiler des jobs, une opération légère), et le débit d'exécution dépend directement du nombre de workers actifs — vous scalez en ajoutant des processus, pas en changeant de serveur plus puissant.

Configuration pas à pas

Les variables d'environnement clés à définir sur l'instance principale et sur chaque worker :

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
# Optionnel selon votre déploiement Redis :
# QUEUE_BULL_REDIS_PASSWORD=...
# QUEUE_BULL_REDIS_DB=0

Sur un déploiement Docker Compose typique, cela donne un service redis (l'image officielle redis:7-alpine suffit dans la grande majorité des cas, sans configuration particulière), un service n8n pour l'instance principale, et un service n8n-worker qui lance la même image avec la commande n8n worker --concurrency=10 — le paramètre --concurrency fixe le nombre d'exécutions qu'un même worker traite en parallèle. Pour ajouter de la capacité, deux leviers indépendants :

• Scaler horizontalement : docker compose up --scale n8n-worker=3 lance trois processus worker qui se partagent la même file Redis, sans configuration supplémentaire.
• Augmenter la concurrence : monter --concurrency sur un worker existant, tant que le CPU et la mémoire du serveur suivent.

Pour des volumes de webhooks élevés (au-delà de 10 000 exécutions par jour), n8n permet aussi de lancer un processus dédié uniquement à la réception des webhooks (n8n webhook), pour que l'instance principale se concentre sur l'interface et le scheduling des crons.

Ce qui ne change pas — et ce qu'il faut vérifier avant de basculer

Le mode queue ne modifie ni la logique des workflows, ni les credentials, ni la structure des données : un pack importé continue de fonctionner à l'identique une fois basculé. Deux points méritent toutefois une vérification avant la mise en production :

• Les Error Workflows restent essentiels : avec plusieurs workers, une exécution qui échoue définitivement doit toujours être capturée par un Error Workflow dédié plutôt que de disparaître silencieusement dans les logs d'un worker parmi d'autres.
• Les credentials et variables d'environnement doivent être identiques sur l'instance principale et sur tous les workers — un worker qui démarre sans la bonne clé API OpenAI ou Anthropic échouera sur toute exécution qui l'atteint, de façon difficile à diagnostiquer si un seul worker sur trois est mal configuré.

Si vos workflows découpent déjà la logique en sub-workflows, le mode queue s'intègre sans changement : chaque appel à un sub-workflow reste une exécution normale, simplement distribuée sur le worker disponible.

Redis : la seule vraie nouvelle dépendance à surveiller

Redis devient, en mode queue, un composant critique au même titre que PostgreSQL : s'il devient indisponible, l'instance principale ne peut plus distribuer de nouveaux jobs, même si les workers eux-mêmes tournent normalement. Pour une instance self-hosted en production, cela justifie les mêmes précautions que pour la base de données :

• Un Redis managé (la plupart des hébergeurs cloud en proposent un) plutôt qu'un conteneur isolé sans sauvegarde, pour éviter un point de défaillance unique non surveillé.
• Une supervision basique (alerte si Redis ne répond plus) — le sujet rejoint directement les réflexes couverts dans notre guide self-hosted vs cloud : le self-hosting apporte du contrôle, à condition d'accepter la responsabilité opérationnelle qui va avec.

Les jobs stockés dans Redis sont éphémères (l'identifiant de l'exécution et son statut, pas les données métier elles-mêmes, qui restent en PostgreSQL) : une perte de Redis ne corrompt pas l'historique des exécutions déjà terminées, mais interrompt le flux des nouvelles.

Quand ne PAS basculer en mode queue

Le mode queue ajoute un composant d'infrastructure (Redis) et de la complexité opérationnelle (plusieurs processus à superviser au lieu d'un seul). Il ne se justifie pas :

• pour un usage inférieur à environ 1 000 exécutions par jour, où une instance standard absorbe le volume sans effort ;
• si vous êtes sur n8n Cloud, où la montée en charge est gérée par n8n sans intervention de votre part ;
• en phase de test ou de mise en place initiale d'un pack — mieux vaut valider le workflow en mode standard, puis basculer une fois le volume réel de production connu.

Pour aller plus loin

Le mode queue est une brique d'infrastructure, pas un remplacement du cadencement des appels IA : combiné au Loop Over Items et à la gestion des rate limits, il permet d'absorber un vrai pic de volume sans jamais dépasser les quotas OpenAI ou Anthropic. Les workflows du Pack Assistant RAG (119 €) et du Pack Inbox IA (79 €) sont conçus pour tourner aussi bien en mode standard qu'en mode queue, sans modification : c'est un choix d'infrastructure côté hébergement, pas une contrainte imposée par les workflows eux-mêmes.