n8n Queue Mode : monter en charge avec Redis et des workers

n8n Queue Mode est un mode d'exécution pour les installations n8n autohébergées dans lequel une instance principale n'exécute plus elle-même les workflows, mais répartit les tâches d'exécution vers des processus worker séparés via une file d'attente Redis. Le mode est activé avec la variable d'environnement EXECUTIONS_MODE=queue sur l'instance principale et les instances worker ; comme base de données, n8n recommande Postgres plutôt que SQLite. Queue Mode est utile en cas de forte charge de webhooks ou de nombreuses exécutions parallèles ; pour les petites installations avec peu d'exécutions quotidiennes, c'est en revanche généralement une charge d'infrastructure superflue. État : juillet 2026.

Comment fonctionne techniquement n8n Queue Mode ?

L'instance principale prend en charge les déclencheurs, les appels webhook et l'interface, mais en Queue Mode elle n'exécute plus elle-même les workflows ; elle génère un identifiant d'exécution et le dépose dans une file d'attente Redis. Un worker disponible récupère la tâche depuis cette file, charge les détails du workflow depuis la base de données à partir de l'identifiant d'exécution, exécute le workflow et écrit le résultat dans la base de données. Redis signale l'achèvement à l'instance principale. Les workers sont des processus Node.js indépendants qui s'exécutent en parallèle les uns des autres et sont démarrés individuellement, par exemple via la commande n8n worker. n8n décrit les détails de ce déroulement dans le guide Enable queue mode.

Quand Queue Mode est-il vraiment nécessaire ?

Queue Mode devient intéressant dès qu'une instance n8n unique atteint ses limites, par exemple parce que de très nombreux webhooks arrivent simultanément ou que plusieurs workflows doivent s'exécuter en parallèle sans se ralentir mutuellement. Dans la configuration par défaut sans Queue Mode, n8n ne limite pas de lui-même le nombre d'exécutions de production simultanées, ce qui, en cas de forte charge, peut entraîner une surcharge de la boucle d'événements et rendre l'instance lente à réagir. Avec Queue Mode, vous répartissez cette charge sur plusieurs workers et pouvez simplement ajouter d'autres workers en cas de besoin croissant, au lieu de faire évoluer verticalement une instance unique. Queue Mode est également indispensable pour la haute disponibilité avec plusieurs instances principales, cette configuration multi-main étant toutefois une fonctionnalité Enterprise.

Quand Queue Mode est-il excessif pour votre installation ?

Pour la plupart des petites et moyennes entreprises avec quelques dizaines d'automatisations et un nombre d'exécutions gérable par jour, une instance n8n unique sans Queue Mode suffit amplement. Plutôt que de mettre en place Redis, plusieurs conteneurs worker et une surveillance supplémentaire, une surcharge imminente peut souvent déjà être évitée avec la variable d'environnement N8N_CONCURRENCY_PRODUCTION_LIMIT, qui limite les exécutions de production parallèles sur une seule instance sans qu'une infrastructure de file d'attente séparée soit nécessaire. Chaque composant supplémentaire tel que Redis ou des processus worker additionnels est aussi un élément de plus qui doit être surveillé, mis à jour et réparé en cas de panne. Quiconque ne fait que traiter occasionnellement des données de formulaire, envoyer des rapports quotidiens ou synchroniser un CRM ne tire aucun avantage perceptible de Queue Mode, mais beaucoup plus de charge d'exploitation.

Que devez-vous prendre en compte techniquement lors de la mise en place ?

Pour un fonctionnement productif en Queue Mode, il faut selon n8n impérativement une instance Redis partagée comme message broker ainsi que Postgres comme base de données ; SQLite n'est pas recommandé pour ce fonctionnement distribué. La clé de chiffrement N8N_ENCRYPTION_KEY doit être définie de manière identique sur l'instance principale et toutes les instances worker, sinon les workers ne peuvent pas déchiffrer les identifiants enregistrés. Chaque worker traite par défaut jusqu'à dix tâches en parallèle, réglable via le flag --concurrency, n8n recommandant de ne pas fixer cette valeur trop bas, car sinon, avec de nombreux workers, le pool de connexions de la base de données peut s'épuiser. Il est également important de noter que Queue Mode ne peut pas stocker les données binaires dans le système de fichiers local du worker concerné ; un stockage externe tel que S3 est prévu à cet effet. n8n publie la liste complète des variables d'environnement sous Queue mode environment variables.

Quiconque n'est pas sûr que sa propre installation n8n a réellement besoin de Queue Mode ou peut se contenter d'une instance unique correctement configurée a intérêt à le faire vérifier dans le cadre d'un état des lieux technique, par exemple dans le cadre du conseil n8n de NordFlux.

Questions fréquentes sur n8n Queue Mode

Ai-je absolument besoin de Redis pour n8n Queue Mode ?

Oui, Redis fait partie intégrante de l'architecture en Queue Mode et gère la file d'attente à partir de laquelle les workers récupèrent leurs tâches. Sans instance Redis en cours d'exécution, l'instance principale et les workers ne peuvent pas communiquer entre eux, Queue Mode ne peut donc pas fonctionner sans Redis.

Puis-je utiliser Queue Mode avec SQLite comme base de données ?

Non, pour Queue Mode, n8n recommande Postgres à partir de la version 13, SQLite n'étant pas recommandé pour ce fonctionnement distribué. Comme plusieurs workers accèdent simultanément en lecture et en écriture à la même base de données, une base de données serveur conçue pour cela, comme Postgres, est le choix le plus judicieux.

Combien de workers dois-je prévoir ?

Il n'existe pas de valeur de référence générale ; chaque worker traite par défaut jusqu'à dix tâches simultanément, configurable via le flag --concurrency. Plutôt que de démarrer d'emblée avec de nombreux workers, il est plus judicieux de commencer avec un ou deux workers et d'en ajouter d'autres de manière ciblée à mesure que la charge augmente.

Que se passe-t-il avec les fichiers et pièces jointes en Queue Mode ?

Les données binaires telles que les fichiers téléchargés ne peuvent pas être stockées en Queue Mode dans le système de fichiers local d'un worker, car l'étape de traitement suivante peut s'exécuter sur un autre worker. À la place, un stockage externe tel que S3 doit être intégré afin que tous les workers puissent accéder aux mêmes données binaires.