Task Runners: Code-Nodes sicherer ausführen

Task Runners sind ein n8n-Feature, das JavaScript- und Python-Code aus dem Code-Node nicht mehr im Hauptprozess von n8n ausführt, sondern in einem separaten, isolierten Prozess oder Container. Das schützt die restliche n8n-Instanz davor, dass fehlerhafter oder unerwünschter Code aus einem Workflow auf Umgebungsvariablen, das Dateisystem oder andere laufende Workflows zugreift. Seit Version 1.111.0 lässt sich der externe, vollständig isolierte Modus produktiv einsetzen, der interne Modus (Ausführung als Kindprozess mit denselben Rechten wie n8n) gilt laut n8n-Dokumentation ausdrücklich nicht als produktionstauglich. Stand: Juli 2026.

Warum Code direkt im Hauptprozess ein Risiko ist

Bis vor kurzem führte n8n den Code aus dem Code-Node direkt im selben Prozess aus, in dem auch der Rest der Workflow-Engine läuft. Das ist einfach umgesetzt, aber riskant: Ein Skript mit Zugriff auf Node.js-Bordmittel kann theoretisch auf Umgebungsvariablen, das Dateisystem oder andere Ressourcen der n8n-Instanz zugreifen, die eigentlich nichts mit dem einzelnen Workflow zu tun haben. Task Runners lösen dieses Problem, indem sie die Codeausführung aus dem Hauptprozess auslagern. Laut n8n-Dokumentation ist das Prinzip ein generischer Mechanismus, um Aufgaben in sicherer und performanter Weise auszuführen, konkret für nutzergesteuerten JavaScript- und Python-Code im Code-Node. Drei Komponenten arbeiten zusammen: der Task Runner, der den Code tatsächlich ausführt, der Task Broker, der Teil der n8n-Hauptinstanz oder eines Workers ist und die Kommunikation koordiniert, und der Task Requester, also der Code-Node selbst, der eine Ausführung anfordert. Die Kommunikation läuft über WebSocket-Verbindungen: Der Runner holt sich Aufgaben vom Broker ab und liefert die Ergebnisse zurück.

Interner und externer Modus im Vergleich

n8n unterscheidet zwei Betriebsarten. Im internen Modus, Standardeinstellung über N8N_RUNNERS_MODE=internal, startet n8n den Task Runner als Kindprozess mit derselben Benutzer- und Gruppen-ID wie die Hauptinstanz. Das reduziert das Risiko gegenüber der alten Inline-Ausführung etwas, bietet aber laut Dokumentation keine echte Isolation und wird für Produktivumgebungen ausdrücklich nicht empfohlen. Im externen Modus übernimmt eine separate Launcher-Anwendung die Runner in eigenen Containern, üblicherweise als Sidecar-Container mit dem Image n8nio/runners neben der eigentlichen n8n-Instanz. Jeder Worker im Queue-Modus benötigt dabei einen eigenen Sidecar, ebenso Hauptinstanzen, die manuelle Ausführungen selbst verarbeiten. Wichtig für den Betrieb: Die Version des n8nio/runners-Image muss zur n8n-Version passen, und externe Task Runners setzen mindestens n8n 1.111.0 voraus.

Absicherung mit isolierten Containern

Wer den externen Modus produktiv betreibt, kann laut n8n-Hardening-Dokumentation zusätzliche Schutzmaßnahmen setzen. Dazu zählen ein distroless Docker-Image mit dem Tag-Suffix -distroless ohne Paketmanager und Shell, die Ausführung als unprivilegierter nobody-Nutzer mit User- und Group-ID 65532, ein schreibgeschütztes Root-Dateisystem mit einem minimalen emptyDir-Volume für /tmp sowie ein AppArmor-Profil, das den Zugriff auf /proc-Dateien wie environ und mounts blockiert und damit verhindert, dass Code aus dem Node Umgebungsvariablen oder Mount-Informationen ausliest. Diese Maßnahmen zusammen ergeben eine im Vergleich zur alten Ausführung im Hauptprozess deutlich engere Sandbox für Code-Nodes.

Wichtige Umgebungsvariablen im Überblick

• N8N_RUNNERS_MODE: internal (Standard) oder external, steuert die Betriebsart.
• N8N_RUNNERS_AUTH_TOKEN: gemeinsames Geheimnis, mit dem sich ein Task Runner bei n8n authentifiziert.
• N8N_RUNNERS_BROKER_PORT: Port des Task Brokers, Standard 5679.
• N8N_RUNNERS_BROKER_LISTEN_ADDRESS: Adresse, auf der der Broker lauscht, Standard 127.0.0.1, für externe Container üblicherweise auf 0.0.0.0 gesetzt.
• N8N_RUNNERS_MAX_CONCURRENCY: Anzahl gleichzeitiger Aufgaben pro Runner, Standard 5.
• N8N_RUNNERS_TASK_TIMEOUT: maximale Laufzeit einer Aufgabe in Sekunden, Standard 300, danach Neustart des Runners.
• NODE_FUNCTION_ALLOW_BUILTIN und NODE_FUNCTION_ALLOW_EXTERNAL: Allowlist für erlaubte Node.js-Module im Code-Node.
• N8N_RUNNERS_STDLIB_ALLOW und N8N_RUNNERS_EXTERNAL_ALLOW: entsprechende Allowlists für Python-Standardbibliothek und Drittanbieter-Module.
• N8N_BLOCK_RUNNER_ENV_ACCESS: blockiert im Standard (true) den Zugriff von Python-Code auf Umgebungsvariablen des Runners.

Für wen sich der Umstieg lohnt

Task Runners betreffen in erster Linie selbst gehostete n8n-Instanzen mit Docker oder Kubernetes, in denen Code-Nodes von unterschiedlichen Teams oder mit sensiblen Zugangsdaten in derselben Instanz laufen. Wer nur wenige eigene, vertrauenswürdige Workflows betreibt, gewinnt weniger, sollte den externen Modus aber trotzdem im Blick behalten, weil n8n die Variable N8N_RUNNERS_ENABLED ab Version 2.0 als veraltet einstuft und der alte Inline-Betrieb absehbar verschwindet. Ehrlich betrachtet bedeutet der externe Modus zusätzlichen Betriebsaufwand: ein weiterer Container pro Worker, eine passende Image-Version und eigene Allowlists für Module. Wer diesen Aufwand scheut, bleibt vorerst im internen Modus, sollte sich aber bewusst sein, dass dieser laut n8n selbst kein Produktionsstandard ist. Für Unternehmen, die n8n als zentrale Automatisierungsplattform einsetzen und dabei auf deutsche Datenhoheit und nachvollziehbare Betriebssicherheit achten, lohnt sich eine bewusste Entscheidung für den externen Modus. NordFlux unterstützt bei der Einrichtung und Absicherung von n8n-Instanzen, siehe n8n-Beratung.

Häufige Fragen zu Task Runners in n8n

Was ist der Unterschied zwischen internem und externem Task-Runner-Modus?

Im internen Modus läuft der Task Runner als Kindprozess von n8n mit denselben Rechten, im externen Modus läuft er in einem eigenen Container und ist laut n8n-Dokumentation vollständig vom Hauptprozess isoliert. Nur der externe Modus gilt als produktionstauglich.

Ab welcher n8n-Version funktionieren externe Task Runners?

Externe Task Runners setzen laut Dokumentation mindestens n8n 1.111.0 voraus, zusätzlich muss die Version des n8nio/runners-Image zur eingesetzten n8n-Version passen.

Muss ich für jeden Worker einen eigenen Task-Runner-Container betreiben?

Ja, im Queue-Modus benötigt jeder Worker einen eigenen Sidecar-Container. Hauptinstanzen, die manuelle Ausführungen selbst verarbeiten, brauchen laut Dokumentation ebenfalls einen eigenen Runner, sofern OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS nicht aktiviert ist.

Blockieren Task Runners automatisch den Zugriff auf Umgebungsvariablen?

Für Python-Code ist der Zugriff auf Umgebungsvariablen des Runners über N8N_BLOCK_RUNNER_ENV_ACCESS standardmäßig blockiert. Für Isolation auf Betriebssystemebene empfiehlt n8n zusätzlich Maßnahmen wie ein AppArmor-Profil, das Zugriffe auf /proc-Dateien verhindert.

Quellen: n8n-Dokumentation: Set up task runners und n8n-Dokumentation: Harden task runners.