Task Runners: ejecutar nodos Code de forma más segura

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.

Por qué ejecutar código directamente en el proceso principal es un riesgo

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.

Comparación entre el modo interno y el externo

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.

Endurecimiento con contenedores aislados

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.

Variables de entorno importantes de un vistazo

• N8N_RUNNERS_MODE: internal (predeterminado) o external, controla el modo de funcionamiento.
• N8N_RUNNERS_AUTH_TOKEN: secreto compartido que utiliza un Task Runner para autenticarse ante n8n.
• N8N_RUNNERS_BROKER_PORT: puerto del Task Broker, por defecto 5679.
• N8N_RUNNERS_BROKER_LISTEN_ADDRESS: dirección en la que escucha el broker, por defecto 127.0.0.1, para contenedores externos normalmente se establece en 0.0.0.0.
• N8N_RUNNERS_MAX_CONCURRENCY: número de tareas simultáneas por runner, por defecto 5.
• N8N_RUNNERS_TASK_TIMEOUT: duración máxima de una tarea en segundos, por defecto 300, tras lo cual el runner se reinicia.
• NODE_FUNCTION_ALLOW_BUILTIN y NODE_FUNCTION_ALLOW_EXTERNAL: lista blanca de módulos de Node.js permitidos en el nodo Code.
• N8N_RUNNERS_STDLIB_ALLOW y N8N_RUNNERS_EXTERNAL_ALLOW: listas blancas correspondientes para la biblioteca estándar de Python y módulos de terceros.
• N8N_BLOCK_RUNNER_ENV_ACCESS: bloquea de forma predeterminada (true) el acceso del código Python a las variables de entorno del runner.

Para quién merece la pena el cambio

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.

Preguntas frecuentes sobre los Task Runners en n8n

¿Cuál es la diferencia entre el modo Task Runner interno y externo?

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.

¿A partir de qué versión de n8n funcionan los Task Runners externos?

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.

¿Tengo que operar un contenedor Task Runner propio para cada worker?

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.

¿Bloquean los Task Runners automáticamente el acceso a las variables de entorno?

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.