Los Task Runners de n8n ejecutan los nodos Code de forma aislada en lugar de en el proceso principal. Así funcionan el modo interno y externo.
Los Task Runners son una función de n8n que ya no ejecuta el código JavaScript y Python del nodo Code en el proceso principal de n8n, sino en un proceso o contenedor separado y aislado. Esto protege al resto de la instancia n8n de que código defectuoso o no deseado de un workflow acceda a variables de entorno, al sistema de archivos o a otros workflows en ejecución. Desde la versión 1.111.0, el modo externo, totalmente aislado, puede utilizarse en producción; el modo interno (ejecución como proceso hijo con los mismos permisos que n8n) no se considera explícitamente apto para producción según la documentación de n8n. Actualizado: julio de 2026.
Hasta hace poco, n8n ejecutaba el código del nodo Code directamente en el mismo proceso en el que también se ejecuta el resto del motor de workflows. Esto es sencillo de implementar, pero arriesgado: un script con acceso a las funciones nativas de Node.js puede acceder en teoría a variables de entorno, al sistema de archivos o a otros recursos de la instancia n8n que en realidad no tienen nada que ver con el workflow individual. Los Task Runners resuelven este problema sacando la ejecución del código fuera del proceso principal. Según la documentación de n8n, el principio es un mecanismo genérico para ejecutar tareas de forma segura y eficiente, concretamente para código JavaScript y Python controlado por el usuario en el nodo Code. Tres componentes trabajan juntos: el Task Runner, que ejecuta realmente el código, el Task Broker, que forma parte de la instancia principal de n8n o de un worker y coordina la comunicación, y el Task Requester, es decir, el propio nodo Code, que solicita una ejecución. La comunicación se realiza mediante conexiones WebSocket: el runner recoge tareas del broker y devuelve los resultados.
n8n distingue dos modos de funcionamiento. En el modo interno, ajuste predeterminado mediante N8N_RUNNERS_MODE=internal, n8n inicia el Task Runner como un proceso hijo con el mismo ID de usuario y grupo que la instancia principal. Esto reduce algo el riesgo frente a la antigua ejecución en línea, pero según la documentación no ofrece un aislamiento real y no se recomienda explícitamente para entornos de producción. En el modo externo, una aplicación de lanzamiento independiente se encarga de los runners en sus propios contenedores, normalmente como contenedor sidecar con la imagen n8nio/runners junto a la instancia n8n propiamente dicha. Cada worker en modo cola necesita su propio sidecar, al igual que las instancias principales que procesan ellas mismas las ejecuciones manuales. Importante para la operación: la versión de la imagen n8nio/runners debe coincidir con la versión de n8n, y los Task Runners externos requieren al menos n8n 1.111.0.
Quien utilice el modo externo en producción puede, según la documentación de hardening de n8n, aplicar medidas de protección adicionales. Entre ellas se incluyen una imagen Docker distroless con el sufijo de etiqueta -distroless sin gestor de paquetes ni shell, la ejecución como usuario no privilegiado nobody con ID de usuario y grupo 65532, un sistema de archivos raíz de solo lectura con un volumen emptyDir mínimo para /tmp, así como un perfil AppArmor que bloquea el acceso a archivos /proc como environ y mounts, impidiendo así que el código del nodo lea variables de entorno o información de montaje. Estas medidas en conjunto dan como resultado, en comparación con la antigua ejecución en el proceso principal, un sandbox mucho más restringido para los nodos Code.
Los Task Runners afectan principalmente a instancias n8n autoalojadas con Docker o Kubernetes, en las que nodos Code de diferentes equipos o con credenciales sensibles se ejecutan en la misma instancia. Quien solo opere unos pocos workflows propios y de confianza gana menos, pero debería tener igualmente en cuenta el modo externo, porque n8n marca la variable N8N_RUNNERS_ENABLED como obsoleta a partir de la versión 2.0 y el antiguo funcionamiento en línea desaparecerá previsiblemente. Sinceramente, el modo externo supone un esfuerzo operativo adicional: un contenedor más por worker, una versión de imagen adecuada y listas blancas propias para módulos. Quien quiera evitar este esfuerzo permanece por ahora en el modo interno, pero debe ser consciente de que, según el propio n8n, este no es un estándar de producción. Para las empresas que utilizan n8n como plataforma de automatización central y que cuidan la soberanía de datos alemana y una seguridad operativa trazable, merece la pena una decisión consciente a favor del modo externo. NordFlux ayuda con la configuración y el endurecimiento de instancias n8n, ver consultoría n8n.
En el modo interno, el Task Runner se ejecuta como proceso hijo de n8n con los mismos permisos; en el modo externo se ejecuta en su propio contenedor y, según la documentación de n8n, está totalmente aislado del proceso principal. Solo el modo externo se considera apto para producción.
Los Task Runners externos requieren, según la documentación, al menos n8n 1.111.0; además, la versión de la imagen n8nio/runners debe coincidir con la versión de n8n utilizada.
Sí, en modo cola cada worker necesita su propio contenedor sidecar. Las instancias principales que procesan ellas mismas las ejecuciones manuales también necesitan su propio runner según la documentación, salvo que OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS esté activado.
Para código Python, el acceso a las variables de entorno del runner mediante N8N_BLOCK_RUNNER_ENV_ACCESS está bloqueado por defecto. Para el aislamiento a nivel de sistema operativo, n8n recomienda además medidas como un perfil AppArmor que impida el acceso a archivos /proc.
Fuentes: Documentación de n8n: Set up task runners y Documentación de n8n: Harden task runners.
NordFlux crea empleados digitales para las organizaciones: automatizaciones y agentes KI que asumen el trabajo repetitivo. Usted mantiene el control.
El mayor obstáculo de aprendizaje de n8n explicado: qué significan items, $json y $node y cómo mapear valores mediante arrastrar y soltar sin código.
Cómo endurecer n8n: activar la 2FA, configurar la protección SSRF, bloquear nodes de riesgo con NODES_EXCLUDE y desactivar la Public API cuando no se utiliza.
Los task runners son solo una pieza: un n8n operado con seguridad necesita además hardening, un concepto de permisos y actualizaciones limpias. NordFlux opera instancias de n8n con el modo de task runner externo, monitorización y configuración documentada. Así, incluso los workflows con mucho código funcionan en producción sin que un solo nodo ponga en riesgo toda la instancia.
