n8n mejora el apagado de workers en modo cola

Reiniciar un worker no debería romper una ejecución a medias

Un worker de n8n puede estar procesando una tarea larga justo cuando toca actualizar una imagen Docker, reiniciar el host o desplegar cambios. En un homelab esto ocurre más de lo que parece: mantenimiento de Proxmox, actualizaciones del sistema, cambios en Docker Compose o simplemente una prueba que acaba llegando a producción. Si el proceso termina sin margen, una ejecución en curso puede quedarse a medias en el peor momento.

n8n 2.43.7 incorpora una mejora enfocada a ese problema en los workers que trabajan en modo cola. La nota de la versión indica que las ejecuciones de producción en curso pueden suspenderse durante el apagado del worker, en lugar de depender de un corte abrupto del proceso. Es una mejora especialmente relevante cuando n8n participa en tareas que no son instantáneas, como sincronizaciones, copias, llamadas HTTP encadenadas o automatizaciones conectadas con Laravel. (github.com)

Qué aporta el modo cola

En modo cola, la instancia principal de n8n recibe los triggers y deja las ejecuciones pendientes en Redis. Los workers recogen esos trabajos, consultan la información necesaria en la base de datos y ejecutan los flujos. Esto permite separar la interfaz y los webhooks del trabajo pesado, además de añadir o quitar workers según haga falta. (docs.n8n.io)

No hace falta tener una infraestructura enorme para que esta separación tenga sentido. Un único worker adicional ya permite reiniciar o sustituir otro contenedor con menos riesgo operativo, siempre que ambos compartan Redis, base de datos y la misma clave de cifrado. Para un servidor doméstico, esa arquitectura suele ser más útil por control que por necesidad de escalar.

La clave está en no tratar al worker como un proceso desechable que puede morir en cualquier momento. Si una automatización está subiendo un archivo, esperando una API lenta o terminando una cadena de jobs, conviene darle una ventana para llegar a un punto seguro. Ahí entra la configuración de apagado controlado que sí está documentada oficialmente.

El parámetro que conviene revisar

n8n documenta N8N_GRACEFUL_SHUTDOWN_TIMEOUT para definir cuánto tiempo espera un worker antes de terminar el proceso. Su valor por defecto es de 30 segundos y está pensado para que los workers puedan finalizar trabajos antes de apagarse. No conviene elegir el valor a ojo: debe tener relación con la duración normal de los nodos más lentos de tus flujos. (docs.n8n.io)

Este ejemplo muestra una configuración mínima de Docker Compose para un worker conectado a Redis. No incluye la instancia principal ni la base de datos, pero deja claros los valores que el worker necesita para entrar en modo cola y disponer de una ventana de apagado razonable.

services:
  redis:
    image: redis:7
 
  n8n-worker:
    image: n8nio/n8n:2.43.7
    command: worker --concurrency=5
    environment:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PORT: 6379
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_GRACEFUL_SHUTDOWN_TIMEOUT: 60
    depends_on:
      - redis

EXECUTIONS_MODE=queue debe estar presente tanto en la instancia principal como en los workers. Además, los workers deben usar la misma N8N_ENCRYPTION_KEY que la instancia principal para poder acceder a las credenciales guardadas. La documentación también indica que Redis y la base de datos deben ser accesibles para todos los procesos que forman parte de este despliegue. (docs.n8n.io)

El comando worker --concurrency=5 limita cada worker a cinco ejecuciones paralelas. n8n documenta una concurrencia predeterminada de 10 y recomienda no bajarla demasiado cuando hay muchos workers, porque se puede presionar innecesariamente el pool de conexiones de la base de datos. En un homelab, el número correcto depende más de la RAM, la CPU y los servicios externos que de una cifra genérica. (docs.n8n.io)

Cómo lo aplicaría en un homelab

Yo separaría al menos Redis y el worker del contenedor principal de n8n si ya tengo flujos que reciben webhooks o ejecutan tareas frecuentes. Laravel puede disparar un webhook a n8n después de un evento de negocio, y n8n puede responder con una copia, una notificación o una llamada a otro servicio. Esa cadena no necesita convertirse en una plataforma distribuida compleja, pero sí agradece que un reinicio no sea una ruleta.

Antes de actualizar, revisaría si hay ejecuciones activas y lanzaría un apagado normal del contenedor en lugar de forzarlo. El timeout debe ser menor que el tiempo máximo que Docker o el orquestador concede antes de matar el proceso, o la ventana configurada dentro de n8n no servirá de mucho. También probaría el comportamiento con un flujo lento y prescindible antes de aplicarlo a automatizaciones que muevan datos reales.

Si utilizas varios workers, todos deberían ejecutar la misma versión de n8n. La documentación lo exige expresamente para despliegues con varios procesos principales y es una precaución razonable también para un conjunto de workers que comparten cola, Redis y base de datos. Actualizar un contenedor cada vez puede parecer conservador, pero reduce diferencias difíciles de diagnosticar. (docs.n8n.io)

La letra pequeña

Un apagado controlado no convierte una ejecución en indestructible. Si el host pierde alimentación, Docker recibe una terminación forzada o el tiempo de gracia se agota mientras un nodo sigue bloqueado, el proceso seguirá sin poder completar ese trabajo de forma limpia. Esta mejora reduce un tipo concreto de fallo durante apagados ordenados; no sustituye copias de seguridad, monitorización ni flujos idempotentes.

Tampoco usaría el modo cola con almacenamiento binario en el sistema de archivos local. n8n indica que esa combinación no está soportada y recomienda almacenamiento externo, como S3, cuando los flujos necesitan persistir binarios. Compartir un volumen entre contenedores puede parecer suficiente en un laboratorio, pero añade dependencias y problemas que aparecen cuando se mueve un worker a otra máquina. (docs.n8n.io)

Hay otra consecuencia práctica para los webhooks: en modo cola, la petición HTTP la recibe el proceso principal o un procesador de webhooks, pero la ejecución real pasa al worker. Eso añade un salto adicional y, por tanto, algo de sobrecarga y latencia. Para tareas internas o asíncronas no suele ser relevante; para endpoints que deban responder muy rápido, conviene medirlo antes de rediseñar nada. (docs.n8n.io)

La mejora de 2.43.7 merece atención por un motivo sencillo: hace más razonable operar n8n como parte de la infraestructura del homelab. No es una función vistosa en la interfaz, pero sí una pieza útil para actualizar, reiniciar y mantener workers sin tratar cada despliegue como una interrupción inevitable de las automatizaciones.

Fuente: lanzamiento de n8n 2.43.7 · Documentación oficial sobre modo cola