Votre instance n8n fait tourner de plus en plus de workflows. Un matin, des webhooks répondent lentement, des exécutions s'empilent, et l'interface elle-même devient poussive. La tentation est d'ajouter de la mémoire au serveur. C'est parfois la bonne réponse, parfois un simple répit : n8n propose une autre architecture, le mode queue, qui sépare la réception des déclencheurs de l'exécution des workflows.
Cet article explique ce que fait ce mode, quand il devient pertinent pour une PME, ce qu'il impose en infrastructure et les pièges à éviter. Les faits sur n8n viennent de sa documentation officielle, citée en fin d'article ; les recommandations sont notre analyse, à adapter à votre contexte.
Ce que fait le mode queue
Par défaut, une instance n8n reçoit les déclencheurs et exécute elle-même les workflows. En mode queue, les rôles sont séparés. D'après la documentation :
- l'instance principale gère les déclencheurs et les appels de webhooks, crée les exécutions et transmet leurs identifiants à Redis, qui les met en file d'attente ;
- les workers récupèrent les tâches dans Redis, chargent les données du workflow depuis la base, exécutent, enregistrent le résultat, puis signalent la fin à l'instance principale par Redis.
L'intérêt est de pouvoir ajouter ou retirer des workers selon la charge. La documentation de mise à l'échelle indique que le mode queue offre la meilleure scalabilité.
| Rôle | Ce qu'il fait |
|---|---|
| Instance principale | Reçoit les déclencheurs et webhooks, crée les exécutions, alimente la file |
| Redis | Sert de file d'attente entre l'instance principale et les workers |
| Worker | Exécute les workflows, un ou plusieurs en parallèle |
| Base de données | Partagée : stocke workflows, identifiants et résultats |
Avant de passer en mode queue : ce qu'on peut faire d'abord
Le mode queue ajoute des composants à exploiter. Avant d'y venir, vérifiez les leviers plus simples, que la documentation de mise à l'échelle recense : limiter le nombre d'exécutions simultanées, configurer l'enregistrement et la purge des données d'exécution, traiter correctement les fichiers volumineux, surveiller la mémoire.
Limiter la concurrence. En mode normal (dit « regular »), n8n ne plafonne pas le nombre d'exécutions de production simultanées. La variable N8N_CONCURRENCY_PRODUCTION_LIMIT permet de fixer un plafond : les exécutions au-delà attendent dans une file premier arrivé, premier servi. Cette limite est désactivée par défaut et ne s'applique qu'aux exécutions de production lancées par un webhook ou un déclencheur ; les exécutions manuelles, les sous-workflows et les exécutions d'erreur n'en font pas partie. Elle ne concerne que les instances auto-hébergées.
Alléger la base. Un historique d'exécutions qui grossit ralentit tout. Notre article sur la purge des anciennes exécutions détaille les réglages.
Si, une fois ces points traités, une seule machine ne suffit plus, ou si vous voulez isoler les traitements lourds pour que l'interface et les webhooks restent réactifs, le mode queue devient une option sérieuse.
Les prérequis à connaître
La documentation de n8n est explicite sur les conditions :
- Redis est indispensable : c'est le courtier de messages. Il peut tourner sur une autre machine, tant que toutes les instances n8n peuvent l'atteindre.
- Une base compatible. Une installation distribuée sur SQLite n'est pas prise en charge : utilisez une base comme PostgreSQL.
- Pas de stockage de fichiers binaires sur le système de fichiers. Ce mode n'est pas pris en charge en queue ; pour conserver des données binaires, la documentation indique d'utiliser un stockage externe de type S3.
- La même clé de chiffrement partout. Les workers (et les processeurs de webhooks) doivent connaître la clé de l'instance principale pour lire les identifiants stockés. Il faut définir
N8N_ENCRYPTION_KEYsur chacun avec la valeur de l'instance principale. Sans elle, ils ne peuvent pas accéder aux identifiants.
C'est ce dernier point qui surprend le plus souvent : un worker qui démarre mais échoue sur chaque workflow utilisant un identifiant est généralement un worker sans la bonne clé.
Mettre en place instance principale et workers
La configuration repose sur quelques variables d'environnement :
EXECUTIONS_MODE=queue, à définir sur l'instance principale et sur chaque worker ;QUEUE_BULL_REDIS_HOSTetQUEUE_BULL_REDIS_PORTpour indiquer où se trouve Redis (par défautlocalhostet6379, sans mot de passe : à durcir pour la production) ;N8N_ENCRYPTION_KEY, identique sur toutes les instances, comme vu plus haut.
Un worker se lance avec la commande n8n worker, ou avec l'image Docker en lui passant la commande worker. Vous pouvez en démarrer autant que nécessaire, à condition que chacun atteigne Redis et la base de données.
La concurrence par worker. Par défaut, chaque worker exécute jusqu'à 10 tâches en parallèle. On l'ajuste avec n8n worker --concurrency=<nombre>. La documentation recommande de ne pas descendre sous 5 : avec beaucoup de workers et une concurrence faible, on risque d'épuiser le pool de connexions à la base de données. Le dimensionnement se pense donc en deux dimensions, nombre de workers et concurrence de chacun, avec la base comme goulot commun.
Les processeurs de webhooks, en option
Pour les instances qui reçoivent beaucoup de webhooks, n8n permet de les traiter à part, avec des processeurs de webhooks (n8n webhook), derrière un répartiteur de charge. Le routage décrit par la documentation est précis :
/webhook/*et/webhook-waiting/*vont vers le groupe de processeurs de webhooks ;- tout le reste va vers l'instance principale, y compris
/webhook-test/*, utilisé pour les tests manuels depuis l'éditeur ; N8N_DISABLE_PRODUCTION_MAIN_PROCESS=trueempêche l'instance principale de traiter les webhooks de production.
C'est une optimisation de seconde étape : n'y venez qu'après avoir constaté que la réception des webhooks est le point de saturation. Pour sécuriser ces points d'entrée, voyez notre article sur l'authentification et la signature HMAC des webhooks.
Ce qui dépend de la licence
La page de documentation sur le mode queue ne conditionne pas le mode lui-même à une licence particulière, mais deux fonctions voisines sont réservées à des offres :
- la vue des workers en cours (Réglages > Workers) est disponible en auto-hébergé Enterprise ; sur n8n Cloud Enterprise, il faut contacter n8n pour l'activer ;
- le mode multi-main, qui met plusieurs instances principales en haute disponibilité, est disponible en auto-hébergé Enterprise et n'existe pas sur n8n Cloud. Il suppose Redis, PostgreSQL, la même version de n8n partout et un répartiteur de charge à sessions persistantes.
Si vous êtes sur n8n Cloud, la question ne se pose pas dans les mêmes termes : le mode queue concerne l'hébergement que vous gérez. Pour le choix entre Cloud et auto-hébergé, voir n8n Cloud ou auto-hébergé : que change le RGPD en PME ?.
Notre recommandation pour une PME
Ces règles sont notre point de départ, pas une norme :
- Mesurer avant de changer. Notez ce qui sature : processeur, mémoire, base de données, réception des webhooks. Le mode queue répond surtout à la saturation de l'exécution.
- Épuiser d'abord les leviers simples : plafond de concurrence, purge des exécutions, gestion des fichiers volumineux.
- Commencer petit : une instance principale, un worker, un Redis. Ajoutez des workers quand la file s'allonge, pas avant.
- Passer à PostgreSQL si ce n'est pas déjà le cas, avant toute migration.
- Sauvegarder la base et la clé de chiffrement avant de toucher à l'architecture : notre article sur la sauvegarde et le versionnement des workflows liste ce qu'il faut protéger.
- Brancher des alertes sur les échecs, car une architecture distribuée multiplie les endroits où une erreur peut se cacher : voir la gestion des erreurs avec l'Error Trigger.
Les erreurs fréquentes
- Passer en mode queue « par principe », alors qu'une seule machine suffit : on ajoute Redis et des workers à exploiter sans gain.
- Oublier
EXECUTIONS_MODE=queuesur les workers : ils ne se comportent pas comme prévu. - Une clé de chiffrement différente sur un worker : les workflows qui utilisent des identifiants échouent.
- Laisser Redis sans protection avec la configuration par défaut, ouverte sans mot de passe.
- Garder les fichiers binaires sur le disque local, non pris en charge en mode queue.
- Augmenter les workers sans regarder la base : le pool de connexions devient le nouveau goulot.
Besoin d'un cadre pour vos automatisations ?
Votre instance n8n ralentit et vous hésitez entre plus de ressources et une autre architecture ? Décrivez-nous votre situation : nous identifions ce qui sature, proposons la trajectoire la plus simple et mettons en place la surveillance. Nos offres détaillent les formats d'accompagnement, notre approche explique comment nous avançons, et vous pouvez nous contacter directement.
Questions fréquentes
Le mode queue accélère-t-il chaque workflow ?
Non. Il permet d'exécuter plusieurs workflows en parallèle sur plusieurs workers et de garder l'instance principale disponible. La durée d'un workflow donné dépend toujours de ses nœuds et des services appelés.
Peut-on utiliser le mode queue avec SQLite ?
Non. La documentation indique qu'une installation distribuée sur SQLite n'est pas prise en charge. Utilisez une base prise en charge, comme PostgreSQL.
Combien de workers faut-il prévoir ?
La documentation ne donne pas de règle générale : cela dépend de la charge et de la base. Commencez avec un worker, observez la file, puis ajoutez-en. Gardez la concurrence de chaque worker à 5 ou plus, comme elle le recommande.
Les exécutions manuelles passent-elles aussi par les workers ?
Ce point dépend de votre version et de votre configuration. Vérifiez-le dans la documentation de votre version avant de dimensionner : la page consultée ne le précise pas.
Sources
- n8n, Queue mode, documentation consultée le 20 octobre 2026.
- n8n, Scaling overview, documentation consultée le 20 octobre 2026.
- n8n, Concurrency control, documentation consultée le 20 octobre 2026.