n8n Queue Mode: escalar con Redis y workers

n8n Queue Mode es un modo de ejecución para instalaciones n8n autoalojadas en el que una instancia principal ya no ejecuta los workflows por sí misma, sino que distribuye las tareas de ejecución a procesos worker separados a través de una cola de Redis. El modo se activa con la variable de entorno EXECUTIONS_MODE=queue en la instancia principal y en las instancias worker; como base de datos, n8n recomienda Postgres en lugar de SQLite. Queue Mode tiene sentido con una alta carga de webhooks o muchas ejecuciones paralelas; para instalaciones pequeñas con pocas ejecuciones diarias, en cambio, suele ser un esfuerzo de infraestructura innecesario. Estado: julio de 2026.

¿Cómo funciona técnicamente n8n Queue Mode?

La instancia principal se encarga de los triggers, las llamadas webhook y la interfaz, pero en Queue Mode ya no ejecuta ella misma los workflows, sino que genera un ID de ejecución y lo coloca en una cola de Redis. Un worker disponible recoge la tarea de esta cola, carga los detalles del workflow desde la base de datos a partir del ID de ejecución, ejecuta el workflow y escribe el resultado de nuevo en la base de datos. Redis notifica la finalización a la instancia principal. Los workers son procesos Node.js independientes que se ejecutan en paralelo entre sí y se inician individualmente, por ejemplo mediante el comando n8n worker. n8n describe los detalles de este proceso en la guía Enable queue mode.

¿Cuándo es realmente necesario Queue Mode?

Queue Mode merece la pena en cuanto una única instancia n8n alcanza sus límites, por ejemplo porque llegan muchísimos webhooks al mismo tiempo o porque varios workflows deben ejecutarse en paralelo sin ralentizarse mutuamente. En la configuración predeterminada sin Queue Mode, n8n no limita por sí mismo el número de ejecuciones de producción simultáneas, lo que en caso de alta carga puede provocar que el event loop se sobrecargue y la instancia responda con lentitud. Con Queue Mode se distribuye esta carga entre varios workers y se pueden simplemente añadir más workers a medida que crece la demanda, en lugar de escalar verticalmente una única instancia. Queue Mode también es un requisito para la alta disponibilidad con varias instancias principales, aunque esta configuración multi-main es una función Enterprise.

¿Cuándo es excesivo Queue Mode para su instalación?

Para la mayoría de las pequeñas y medianas empresas con unas pocas docenas de automatizaciones y un número manejable de ejecuciones al día, una única instancia n8n sin Queue Mode es totalmente suficiente. En lugar de configurar Redis, varios contenedores worker y monitorización adicional, a menudo ya se puede evitar una sobrecarga inminente con la variable de entorno N8N_CONCURRENCY_PRODUCTION_LIMIT, que limita las ejecuciones de producción paralelas en una única instancia sin que sea necesaria una infraestructura de cola separada. Cada componente adicional, como Redis o procesos worker adicionales, es también un elemento más que hay que supervisar, actualizar y reparar en caso de fallo. Quien solo procesa ocasionalmente datos de formularios, envía informes diarios o sincroniza un CRM no obtiene ninguna ventaja notable de Queue Mode, pero sí bastante más esfuerzo operativo.

¿Qué debe tener en cuenta técnicamente al configurarlo?

Para un funcionamiento productivo de Queue Mode se necesita, según n8n, obligatoriamente una instancia de Redis compartida como message broker, así como Postgres como base de datos; SQLite no se recomienda para este funcionamiento distribuido. La clave de cifrado N8N_ENCRYPTION_KEY debe configurarse de forma idéntica en la instancia principal y en todas las instancias worker, ya que de lo contrario los workers no podrán descifrar las credenciales almacenadas. Cada worker procesa por defecto hasta diez trabajos en paralelo, configurable mediante el flag --concurrency, y n8n recomienda no fijar este valor demasiado bajo, ya que en caso contrario, con muchos workers, el pool de conexiones de la base de datos puede agotarse. Además, es importante que Queue Mode no puede almacenar datos binarios en el sistema de archivos local del worker correspondiente; para ello está previsto un almacenamiento externo como S3. n8n publica la lista completa de variables de entorno en Queue mode environment variables.

Quien no esté seguro de si su propia instalación n8n realmente necesita Queue Mode o si le basta con una única instancia correctamente configurada, hace bien en comprobarlo en el marco de un diagnóstico técnico, por ejemplo en la consultoría n8n de NordFlux.

Preguntas frecuentes sobre n8n Queue Mode

¿Necesito obligatoriamente Redis para n8n Queue Mode?

Sí, Redis es una parte fija de la arquitectura en Queue Mode y gestiona la cola de la que los workers recogen sus tareas. Sin una instancia de Redis en funcionamiento, la instancia principal y los workers no pueden comunicarse entre sí, por lo que Queue Mode no puede funcionar sin Redis.

¿Puedo usar Queue Mode con SQLite como base de datos?

No, para Queue Mode n8n recomienda Postgres a partir de la versión 13, ya que SQLite no se recomienda para este funcionamiento distribuido. Como varios workers acceden simultáneamente en lectura y escritura a la misma base de datos, una base de datos de servidor diseñada para ello, como Postgres, es la opción más sensata.

¿Cuántos workers debería prever?

No existe un valor orientativo general; cada worker procesa por defecto hasta diez trabajos simultáneamente, configurable mediante el flag --concurrency. Más sensato que iniciar desde el principio con muchos workers es empezar con uno o dos workers e ir añadiendo más de forma específica a medida que aumenta la carga.

¿Qué ocurre con los archivos y adjuntos en Queue Mode?

Los datos binarios, como los archivos subidos, no se pueden almacenar en Queue Mode en el sistema de archivos local de un worker, porque el siguiente paso de procesamiento puede ejecutarse en otro worker. En su lugar, hay que integrar un almacenamiento externo como S3 para que todos los workers puedan acceder a los mismos datos binarios.