n8n queue mode con Redis: cuándo dejar el modo de instancia única
Guía práctica del modo queue de n8n con Redis: señales de que una instancia ya no da abasto, requisitos que añade y configuración clave.
Comprobado con las fuentes citadas el .
Las señales de que una instancia deja de dar abasto
Si alojas n8n por tu cuenta, la primera versión que ejecutas casi siempre es el modo regular: un proceso que dispara, ejecuta y sirve el editor. Funciona bien hasta que el tráfico de producción llega a ráfagas, y ahí suele aparecer por primera vez el modo queue de n8n con Redis. Según la documentación self-hosted de n8n, el modo regular no limita cuántas ejecuciones de producción se ejecutan a la vez, lo que puede saturar el event loop; se puede fijar un techo con N8N_CONCURRENCY_PRODUCTION_LIMIT.
Esa distinción importa cuando decides si el modo queue con Redis es la respuesta adecuada. Un límite de concurrencia es protección: mantiene la interfaz receptiva al negarse a ejecutarlo todo a la vez. El modo queue es rendimiento: añade máquinas que realmente hacen el trabajo. Si tu instancia solo se satura de vez en cuando, prueba primero el límite. Si el atasco es sostenido y la cola nunca se vacía, lo que necesitas es capacidad extra.
La documentación de n8n no indica un volumen de ejecuciones a partir del cual una sola instancia deja de dar abasto, así que trata los síntomas siguientes como observaciones y no como un umbral.
Sources: Control concurrency | Deploy | n8n Docs
Cómo funciona el modo queue y qué requiere
En el modo queue la instancia principal deja de ejecutar el trabajo por sí misma. Genera una ejecución y pasa el ID de ejecución a Redis, que la encola para el siguiente worker disponible, según la documentación de n8n. Los workers toman los trabajos, los ejecutan y escriben los resultados en la base de datos compartida. Nada cambia en tus flujos; solo dónde se ejecutan.
Recorrido de una ejecución en modo queue
- Disparo: La instancia principal recibe el trigger y crea una ejecución.
- Encolado: Pasa el ID de ejecución a Redis en lugar de ejecutar el flujo ella misma.
- Recogida: El siguiente worker disponible toma el trabajo de la cola.
- Ejecución: El worker ejecuta el flujo usando la clave de cifrado compartida para leer credenciales.
- Persistencia: Los resultados se escriben en la base de datos PostgreSQL compartida.
Esa separación crea requisitos reales de self-hosting. Una configuración distribuida en modo queue no está soportada sobre SQLite, así que antes hace falta una base de datos PostgreSQL compartida. La clave de cifrado de la instancia principal debe compartirse con cada worker y procesador de webhooks, o no podrán descifrar las credenciales almacenadas. Redis pasa a ser un componente que operas y monitorizas.
Conviene confirmar las restricciones de edición antes de planificar la arquitectura. La alta disponibilidad multi-main para el modo queue es una función Enterprise en self-hosted, y en n8n Cloud el modo queue se limita a planes Enterprise y debe activarlo n8n. Entre las opciones de hosting de n8n, eso hace del self-hosting el camino donde controlas tú mismo la topología.
Sources: Enable queue mode | Deploy | n8n Docs, Understand concurrency | Deploy | n8n Docs
Configuración básica del modo queue con Redis y dimensionado de workers
Cambiar de modo es sobre todo variables de entorno. EXECUTIONS_MODE debe estar en queue en la instancia principal y en todos los workers. Los ajustes de conexión a Redis siguen los valores por defecto documentados por n8n: QUEUE_BULL_REDIS_HOST usa localhost por defecto y el puerto 6379, con usuario, contraseña, índice de base de datos y TLS opcionales.
El dimensionado es donde los equipos se equivocan. n8n recomienda fijar la concurrencia del worker en 5 o más, y advierte de que muchos workers con concurrencia baja pueden agotar el pool de conexiones de la base de datos. Así que escala el número de workers en lugar de bajar la concurrencia. La documentación de n8n no da una fórmula que relacione número de workers y carga, así que empieza pequeño y observa.
| Componente | Función | Qué decidir |
|---|---|---|
| PostgreSQL | Estado compartido para todos los procesos | Migrar primero desde SQLite; SQLite no está soportado aquí |
| Redis | Encola los IDs de ejecución para los workers | Host, puerto, credenciales y si activar TLS |
| Instancia principal | Dispara y encola, sirve el editor | EXECUTIONS_MODE fijado en queue |
| Workers | Ejecutan los flujos encolados | Concurrencia de 5 o más, y luego añadir más workers |
| Clave de cifrado | Permite a los workers leer credenciales almacenadas | La misma clave distribuida a cada proceso |
Un tutorial de la comunidad de n8n de febrero de 2025 muestra lo modesto que puede ser un primer laboratorio de modo queue con Redis: una red Docker con Redis, Postgres, una instancia principal y contenedores worker compartiendo un único fichero env. Usa contraseñas en texto plano sin TLS, así que trátalo como ejercicio de laboratorio, no como referencia de producción.
Sources: Enable queue mode | Deploy | n8n Docs, Queue mode | Deploy | n8n Docs, Queue Mode guide [How to scale up n8n] - English 🇬🇧 - n8n Community
Webhooks, respuestas grandes y verificación
Como regla editorial, añade procesadores de webhooks dedicados solo cuando la recepción de webhooks sea el cuello de botella real. Decidas lo que decidas, cada procesador de webhooks necesita la misma clave de cifrado que la instancia principal y los workers, o no podrá leer las credenciales almacenadas.
Las respuestas grandes merecen atención porque en modo queue las respuestas de webhook viajan por Redis. n8n documenta un límite de tamaño de retransmisión con valor por defecto de 64 MiB y sugiere presupuestar en torno a 1,5 veces ese valor en memoria de Redis por respuesta en vuelo; es una estimación del proveedor sin método de medición declarado. La descarga de cuerpos sobredimensionados con N8N_WEBHOOK_RESPONSE_RELAY_OFFLOAD_ENABLED debe activarse en los workers solo después de que todas las instancias main y de webhooks ejecuten n8n 2.34.0 o posterior, y requiere un modo de datos binarios que almacene los datos.
La verificación es sencilla: ejecuta un flujo de prueba y confirma que aparece en los logs del worker y no en la instancia principal. Todo esto se apoya en documentación del proveedor más una publicación de la comunidad de un autor individual, y aquí no hay benchmarks independientes de rendimiento o latencia, así que mide tu propia carga antes de prometer capacidad.
- Migra la base de datos a PostgreSQL y confirma que la instancia funciona con normalidad sobre ella.
- Levanta Redis y alcánzalo desde el host de n8n.
- Fija EXECUTIONS_MODE en queue y distribuye la clave de cifrado compartida a cada proceso.
- Arranca dos workers con concurrencia 5 o más y ejecuta un flujo de prueba.
- Revisa los logs del worker para confirmar que la ejecución salió de la instancia principal.
- Como regla editorial, plantéate separar la recepción de webhooks solo cuando sea claramente el cuello de botella.
Sources: Enable queue mode | Deploy | n8n Docs, Queue mode | Deploy | n8n Docs
Una migración por etapas que sí puedes terminar
La conclusión es poco dramática. Si alojas n8n por tu cuenta, quédate en modo regular con un límite de concurrencia de producción mientras aguante, y muévete solo cuando un atasco sostenido indique que la capacidad extra es la necesidad real. Confirma los requisitos de edición antes de diseñar la topología, no después.
Entre las opciones de hosting de n8n, el modo queue con Redis es el punto en el que n8n deja de ser una app que instalaste y pasa a ser infraestructura que operas. Planifica la guardia y la monitorización de Redis junto con la configuración.
Sources: Control concurrency | Deploy | n8n Docs, Enable queue mode | Deploy | n8n Docs
