Task Runners : exécuter les nœuds Code en toute sécurité

Les Task Runners sont une fonctionnalité de n8n qui n'exécute plus le code JavaScript et Python du nœud Code dans le processus principal de n8n, mais dans un processus ou conteneur séparé et isolé. Cela protège le reste de l'instance n8n contre un code défectueux ou indésirable d'un workflow accédant aux variables d'environnement, au système de fichiers ou à d'autres workflows en cours d'exécution. Depuis la version 1.111.0, le mode externe, entièrement isolé, peut être utilisé en production ; le mode interne (exécution en tant que processus enfant avec les mêmes droits que n8n) n'est explicitement pas considéré comme adapté à la production selon la documentation n8n. État : juillet 2026.

Pourquoi exécuter du code directement dans le processus principal est un risque

Jusqu'à récemment, n8n exécutait le code du nœud Code directement dans le même processus que le reste du moteur de workflow. C'est simple à mettre en œuvre, mais risqué : un script ayant accès aux fonctions natives de Node.js peut théoriquement accéder aux variables d'environnement, au système de fichiers ou à d'autres ressources de l'instance n8n qui n'ont en réalité rien à voir avec le workflow concerné. Les Task Runners résolvent ce problème en externalisant l'exécution du code hors du processus principal. Selon la documentation n8n, le principe est un mécanisme générique permettant d'exécuter des tâches de manière sûre et performante, concrètement pour du code JavaScript et Python contrôlé par l'utilisateur dans le nœud Code. Trois composants travaillent ensemble : le Task Runner, qui exécute réellement le code, le Task Broker, qui fait partie de l'instance principale de n8n ou d'un worker et coordonne la communication, et le Task Requester, c'est-à-dire le nœud Code lui-même, qui demande une exécution. La communication passe par des connexions WebSocket : le runner récupère les tâches auprès du broker et renvoie les résultats.

Comparaison des modes interne et externe

n8n distingue deux modes de fonctionnement. En mode interne, réglage par défaut via N8N_RUNNERS_MODE=internal, n8n démarre le Task Runner en tant que processus enfant avec le même identifiant utilisateur et groupe que l'instance principale. Cela réduit quelque peu le risque par rapport à l'ancienne exécution en ligne, mais selon la documentation, cela n'offre pas de véritable isolation et n'est explicitement pas recommandé pour les environnements de production. En mode externe, une application de lancement séparée prend en charge les runners dans leurs propres conteneurs, généralement sous forme de conteneur sidecar avec l'image n8nio/runners à côté de l'instance n8n proprement dite. Chaque worker en mode file d'attente a besoin de son propre sidecar, tout comme les instances principales qui traitent elles-mêmes les exécutions manuelles. Important pour l'exploitation : la version de l'image n8nio/runners doit correspondre à la version de n8n, et les Task Runners externes nécessitent au moins n8n 1.111.0.

Durcissement avec des conteneurs isolés

Quiconque exploite le mode externe en production peut, selon la documentation de durcissement de n8n, mettre en place des mesures de protection supplémentaires. Cela inclut une image Docker distroless avec le suffixe de tag -distroless sans gestionnaire de paquets ni shell, l'exécution en tant qu'utilisateur non privilégié nobody avec un identifiant utilisateur et groupe 65532, un système de fichiers racine en lecture seule avec un volume emptyDir minimal pour /tmp, ainsi qu'un profil AppArmor qui bloque l'accès aux fichiers /proc tels que environ et mounts, empêchant ainsi le code du nœud de lire les variables d'environnement ou les informations de montage. Ces mesures combinées offrent, par rapport à l'ancienne exécution dans le processus principal, un bac à sable nettement plus restreint pour les nœuds Code.

Aperçu des variables d'environnement importantes

• N8N_RUNNERS_MODE: internal (par défaut) ou external, contrôle le mode de fonctionnement.
• N8N_RUNNERS_AUTH_TOKEN: secret partagé qu'un Task Runner utilise pour s'authentifier auprès de n8n.
• N8N_RUNNERS_BROKER_PORT: port du Task Broker, par défaut 5679.
• N8N_RUNNERS_BROKER_LISTEN_ADDRESS: adresse sur laquelle le broker écoute, par défaut 127.0.0.1, généralement réglée sur 0.0.0.0 pour les conteneurs externes.
• N8N_RUNNERS_MAX_CONCURRENCY: nombre de tâches simultanées par runner, par défaut 5.
• N8N_RUNNERS_TASK_TIMEOUT: durée maximale d'exécution d'une tâche en secondes, par défaut 300, après quoi le runner redémarre.
• NODE_FUNCTION_ALLOW_BUILTIN et NODE_FUNCTION_ALLOW_EXTERNAL: liste blanche des modules Node.js autorisés dans le nœud Code.
• N8N_RUNNERS_STDLIB_ALLOW et N8N_RUNNERS_EXTERNAL_ALLOW: listes blanches correspondantes pour la bibliothèque standard Python et les modules tiers.
• N8N_BLOCK_RUNNER_ENV_ACCESS: bloque par défaut (true) l'accès du code Python aux variables d'environnement du runner.

Pour qui la migration en vaut la peine

Les Task Runners concernent avant tout les instances n8n autohébergées avec Docker ou Kubernetes, où des nœuds Code de différentes équipes ou avec des identifiants sensibles s'exécutent dans la même instance. Quiconque n'exploite que quelques workflows propres et fiables y gagne moins, mais devrait tout de même garder le mode externe à l'esprit, car n8n considère la variable N8N_RUNNERS_ENABLED comme obsolète à partir de la version 2.0 et l'ancien fonctionnement en ligne est appelé à disparaître. Honnêtement, le mode externe implique un effort d'exploitation supplémentaire : un conteneur de plus par worker, une version d'image adaptée et des listes blanches propres pour les modules. Quiconque veut éviter cet effort reste pour l'instant en mode interne, mais doit avoir conscience que celui-ci n'est, selon n8n lui-même, pas un standard de production. Pour les entreprises qui utilisent n8n comme plateforme d'automatisation centrale et qui accordent de l'importance à la souveraineté des données allemande et à une sécurité d'exploitation traçable, une décision délibérée en faveur du mode externe est intéressante. NordFlux accompagne la mise en place et le durcissement des instances n8n, voir conseil n8n.

Questions fréquentes sur les Task Runners dans n8n

Quelle est la différence entre le mode Task Runner interne et externe ?

En mode interne, le Task Runner s'exécute en tant que processus enfant de n8n avec les mêmes droits ; en mode externe, il s'exécute dans son propre conteneur et est, selon la documentation n8n, entièrement isolé du processus principal. Seul le mode externe est considéré comme adapté à la production.

À partir de quelle version de n8n les Task Runners externes fonctionnent-ils ?

Les Task Runners externes nécessitent, selon la documentation, au moins n8n 1.111.0 ; de plus, la version de l'image n8nio/runners doit correspondre à la version de n8n utilisée.

Dois-je exploiter un conteneur Task Runner distinct pour chaque worker ?

Oui, en mode file d'attente, chaque worker a besoin de son propre conteneur sidecar. Les instances principales qui traitent elles-mêmes les exécutions manuelles ont également besoin de leur propre runner selon la documentation, sauf si OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS est activé.

Les Task Runners bloquent-ils automatiquement l'accès aux variables d'environnement ?

Pour le code Python, l'accès aux variables d'environnement du runner via N8N_BLOCK_RUNNER_ENV_ACCESS est bloqué par défaut. Pour l'isolation au niveau du système d'exploitation, n8n recommande en outre des mesures telles qu'un profil AppArmor empêchant l'accès aux fichiers /proc.

Sources : Documentation n8n : Set up task runners et Documentation n8n : Harden task runners.