Una sola instancia de n8n funcionó perfectamente durante aproximadamente seis meses. Luego alcanzamos más de 200 ejecuciones de flujos de trabajo al día y todo empezó a ralentizarse significativamente: webhooks que agotaban el tiempo de espera, la interfaz con retardo cuando intentaba abrir el editor y nuevos flujos que tardaban 30 segundos en arrancar porque alguna tarea de procesamiento de CSV acaparaba el único hilo disponible. n8n simplemente no escalaba.
El modo cola de n8n soluciona esto al dividir responsabilidades en tu configuración de Docker de n8n. Un proceso de n8n gestiona la interfaz web y escucha los desencadenadores entrantes como webhooks, horarios y ejecuciones manuales. Procesos workers independientes —pueden ser tres, pueden ser diez— se quedan extrayendo trabajos de una cola de Redis y ejecutando realmente los flujos de trabajo. Así que ahora diez flujos de trabajo pueden ejecutarse simultáneamente en lugar de esperar en cola. Eso es una verdadera automatización de flujos de trabajo.
Configurarás esto con Docker Compose, Redis para la cola de trabajos y PostgreSQL porque SQLite no gestiona bien múltiples procesos (de hecho, los gestiona terriblemente). Las variables de entorno deben coincidir exactamente entre todos los contenedores o nada funcionará. Necesitarás acceso a VPS y conocimientos de Docker. Prepárate para la resolución de problemas. Pero terminarás con una configuración que puede gestionar cientos de ejecuciones simultáneas de flujo de trabajo sin atascarse.
¿Listo para comenzar?
Cómo funciona el modo cola de n8n
El n8n estándar agrupa todo en un solo proceso. La interfaz web funciona allí. Los oyentes de webhook se ejecutan allí. Las ejecuciones de flujo de trabajo se ejecutan allí. Todos compiten por CPU y memoria. Inicia un flujo de trabajo que procesa un archivo de 50 MB y todo lo demás espera. Tu colega intenta abrir un flujo de trabajo en el editor: el indicador de carga gira durante 15 segundos sin respuesta. Un webhook de Stripe llega a tu endpoint y se produce un timeout porque el proceso está ocupado.
El modo cola separa responsabilidades en la arquitectura del modo cola de n8n. El proceso principal sirve la interfaz web y escucha los disparadores. Cuando un flujo de trabajo necesita ejecutarse, el proceso principal no lo ejecuta. Simplemente envía una descripción de trabajo a Redis con detalles como ID de flujo de trabajo, datos de disparadores y qué credenciales usar. Luego continúa con la siguiente tarea.
Los workers monitorizan constantemente el broker de mensajes Redis. Están ejecutando un ciclo ajustado: verificar la cola, extraer un trabajo si existe, ejecutarlo, escribir resultados en PostgreSQL, verificar la cola nuevamente. Redis (usando Bull internamente) mantiene estas colas donde los trabajos esperan hasta que un worker está disponible. Si se activan diez flujos de trabajo simultáneamente y tienes diez workers en ejecución, los diez se ejecutan a la vez.
Todo se conecta a la misma base de datos de PostgreSQL. Las credenciales residen allí, junto con definiciones de flujo de trabajo e historial de ejecuciones. Este estado compartido significa que cualquier worker puede ejecutar cualquier flujo de trabajo, no es necesario vincular trabajos específicos a máquinas específicas, lo que complicaría enormemente la orquestación de flujos de trabajo. La base de datos registra el estado de ejecución en tiempo real, por lo que el proceso principal te muestra actualizaciones de progreso en la UI a pesar de que la ejecución esté ocurriendo en un contenedor completamente diferente en alguna parte.
La ejecución paralela es por qué querrías lidiar con toda esta complejidad. Un flujo de trabajo que procesa 10.000 filas de una hoja de cálculo no bloquea a otro que solo necesita enviar un mensaje a Slack. Por lo general, conviene ejecutar operaciones con archivos de gran tamaño en workers dedicados con más RAM, mientras que los flujos de trabajo solo de API se ejecutan en workers más pequeños, aunque esto depende de la carga de trabajo específica.
Requisitos previos
Necesitas un VPS de n8n o un Dedicated Server con un mínimo de 2 núcleos de CPU y 4 GB de RAM. Querrás 4 o más núcleos y 8 GB o más para entornos de producción que manejen un volumen real de automatización de flujos de trabajo; un Cloud VPS 10 de Contabo es un buen punto de partida. Redis y PostgreSQL juntos consumen alrededor de 1 GB. Cada proceso worker consume entre 200 MB y 500 MB, dependiendo de lo que hagan sus flujos de trabajo. Los flujos de trabajo complejos con muchas transformaciones de datos necesitan más.
Docker y Docker Compose deben estar instalados y funcionando. Esta guía asume Docker 24+ y Compose v2. Si todavía estás usando «docker-compose» (con guion) en lugar de «docker compose» (con espacio), estás en la versión antigua y deberías actualizar. La sintaxis de docker compose de n8n cambió recientemente.
Deberías saber ya lo básico de n8n autoalojado. Esto no es «tu primera instalación de n8n»; necesitas entender flujos de trabajo, cómo funcionan las credenciales y los conceptos generales de n8n alrededor de las variables de entorno. El modo cola añade capas de complejidad sobre esa base. Empieza de forma sencilla si eres nuevo: busca «n8n» en nuestro blog para ver muchos artículos útiles que te ayudarán a empezar.
El conocimiento de PostgreSQL ayuda, pero realmente no es necesario. Tendrás un entorno Docker de PostgreSQL en funcionamiento, pero las operaciones reales de la base de datos ocurren automáticamente una vez que tienes los parámetros de conexión correctos. SQLite no funciona con el modo cola en absoluto. Múltiples procesos tratando de acceder al mismo archivo SQLite crean corrupción. PostgreSQL es obligatorio, no una sugerencia.
La comodidad con la línea de comandos es esencial. Editarás archivos docker-compose.yml, definirás variables de entorno (muchas) y ejecutarás comandos de Docker para escalar workers hacia arriba y hacia abajo. También necesitarás revisar los registros cuando los contenedores no inicien. Si navegar por directorios en una terminal y leer mensajes de error te resulta intimidante, familiarízate con eso primero.
Configurando el modo cola de n8n
La configuración de n8n para el modo cola sigue un orden específico. Configurarás Docker Compose de n8n de forma sistemática: Redis primero porque los workers intentan conectarse inmediatamente cuando comienzan, luego las variables de entorno de n8n que deben coincidir entre todos los contenedores, luego PostgreSQL, luego el proceso principal de n8n y finalmente los workers. Si omites pasos, tendrás fallos de dependencias: los contenedores fallarán porque intentarán conectarse a servicios que aún no existen. Más tarde, cuando necesites añadir capacidad, usarás comandos de escalado de Docker Compose para iniciar workers adicionales, pero la configuración inicial debe hacerse en esta secuencia exacta.
Prepara un contenedor Redis
Redis es el componente base para la distribución de trabajos de n8n. Los workers extraen trabajos de la cola de Redis. El proceso principal envía nuevas ejecuciones a esas colas. Sin Redis en funcionamiento, el modo cola no funciona en absoluto.
Crea un directorio para tu configuración y añade Redis a la configuración de Docker Compose. Aquí está la definición básica del servicio:
redis:
image: redis:7-alpine
container_name: n8n_redis
ports:
- "6379:6379"
volumes:
- redis_data:/data
command: redis-server --appendonly yes
restart: unless-stopped
Esa opción –appendonly yes activa la persistencia de Redis. Sin ella, reiniciar el contenedor de Redis significa perder todos los trabajos en cola. El montaje de volumen almacena estos datos persistentes en el disco.
Para la conexión de Redis en n8n, los workers y el proceso principal se conectarán usando redis como nombre de host, ya que todos están en la misma red de Docker. El puerto 6379 es el predeterminado de Redis. Puedes añadir autenticación por contraseña con –requirepass yourpassword en el comando, aunque para contenedores en una red Docker privada es opcional.
Inicia solo Redis: docker compose up -d redis. Revisa los registros de inmediato: docker logs n8n_redis. Deberías ver «Listo para aceptar conexiones» sin errores. Prueba desde tu host usando redis-cli ping antes de avanzar. Conviene detectar problemas de conexión ahora, antes de configurar los demás contenedores.
Configura las variables de entorno
Las variables de entorno controlan cómo opera n8n en modo cola. Si la configuración de n8n no es correcta, los procesos no se comunicarán, los workers no arrancarán, o peor aún, funcionarán parcialmente pero corromperán datos porque la clave de cifrado no coincide.
Estas son las variables de entorno críticas de n8n para la configuración de n8n:
EXECUTIONS_MODE=queue cambia n8n de modo predeterminado a modo cola. Configúralo en el proceso principal y en todos los workers. Sin esto, n8n solo funciona en modo estándar de un solo proceso e ignora Redis por completo.
N8N_ENCRYPTION_KEY debe ser idéntico en el proceso principal y en cada worker. Esto cifra las credenciales en la base de datos. Los workers con una clave diferente no pueden descifrar credenciales, así que los flujos de trabajo se ejecutan pero fallan cuando intentan acceder a APIs o bases de datos. Los fallos silenciosos son los más difíciles de depurar. Genera una cadena aleatoria larga una vez, reutilízala en todos los contenedores y no la modifiques después del despliegue a menos que quieras migrar manualmente todos los datos cifrados.
QUEUE_BULL_REDIS_HOST y QUEUE_BULL_REDIS_PORT apuntan a Redis. Usa el nombre del servicio de Docker como el host ya que los contenedores se comunican a través de la red interna de Docker. El puerto es 6379 a menos que lo hayas cambiado.
DB_TYPE=postgresdb cambia de SQLite a PostgreSQL. Luego añade: DB_POSTGRESDB_HOST, DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_USER y DB_POSTGRESDB_PASSWORD. Todos los procesos se conectan a la misma base de datos con las credenciales idénticas.
Pon estos en un .env o directamente en docker-compose.yml bajo secciones de entorno. La configuración se mantiene consistente a través de los procesos principales y de workers excepto por algunos ajustes específicos de workers.
Despliega el proceso principal de n8n
El proceso principal de n8n gestiona la interfaz web, sirve la API y pone en cola las ejecuciones de flujos de trabajo, pero no las ejecuta. Los usuarios interactúan con esto en el puerto 5678. Este es el núcleo de tu despliegue de n8n.
Aquí está la definición del servicio de docker de n8n en docker-compose.yml para la instalación de n8n:
n8n:
image: n8nio/n8n:latest
container_name: n8n_main
ports:
- "5678:5678"
environment:
- EXECUTIONS_MODE=queue
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
- QUEUE_BULL_REDIS_HOST=redis
- QUEUE_BULL_REDIS_PORT=6379
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_DATABASE=n8ndb
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
volumes:
- n8n_data:/home/node/.n8n
depends_on:
- postgres
- redis
restart: unless-stopped
El depends_on asegura que PostgreSQL y Redis se inicien antes de que n8n intente conectarse. Los montajes de volumen persisten los archivos de flujo de trabajo y los nodos personalizados fuera del contenedor.
Inícialo: docker compose up -d n8n. Revisa los registros de inmediato: docker logs -f n8n_main. Deberías ver mensajes de conexión exitosa a la base de datos y «El editor ahora es accesible a través de» sin errores. Los fallos de conexión de Redis o los errores de base de datos indican que debes detenerte y resolverlos antes de tocar los workers. Si el proceso principal no puede conectarse a las dependencias, nada funcionará correctamente.
Accede a la interfaz web en http://your-vps-ip:5678. Crea un flujo de trabajo de prueba pero no lo ejecutes aún: los workers no están en ejecución, así que las ejecuciones se quedarán en cola para siempre.
Despliega la base de datos PostgreSQL
PostgreSQL almacena flujos de trabajo, credenciales, historial de ejecución y estado de la cola. El modo cola necesita PostgreSQL porque múltiples procesos acceden a la base de datos de n8n simultáneamente. SQLite no puede gestionar esto de forma segura; en realidad no puede hacerlo en absoluto sin corromper datos.
Agrega el servicio PostgreSQL de n8n a docker-compose.yml:
postgres:
image: postgres:15-alpine
container_name: n8n_postgres
environment:
- POSTGRES_USER=n8n
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
- POSTGRES_DB=n8ndb
volumes:
- postgres_data:/var/lib/postgresql/data
restart: unless-stopped
Las credenciales de la base de datos aquí coinciden con las que colocaste en la configuración principal de n8n. El contenedor de PostgreSQL persiste los datos en un volumen de Docker para que los contenidos sobrevivan a los reinicios.
Para la configuración de Docker de PostgreSQL, la base de datos se inicializa automáticamente la primera vez que se inicia. No es necesario ejecutar scripts SQL manualmente; n8n gestiona la creación del esquema cuando se conecta por primera vez. Inicia PostgreSQL: docker compose up -d postgres. Revisa los registros: docker logs n8n_postgres. Busca «el sistema de base de datos está listo para aceptar conexiones».
Si ya comenzaste el proceso principal de n8n, se conectará a PostgreSQL e inicializará las tablas automáticamente. Revisa los registros de n8n de nuevo para verificar mensajes de migración de base de datos exitosa.
Inicia procesos n8n Worker
Los workers son instancias de n8n ejecutándose en modo worker. Sin interfaz web. Sin puertos expuestos. Extraen trabajos de Redis, ejecutan flujos de trabajo y escriben resultados en PostgreSQL. Nada más.
Aquí está la definición del servicio de trabajador de n8n, similar al principal pero con diferencias clave:
n8n-worker:
image: n8nio/n8n:latest
command: worker
environment:
- EXECUTIONS_MODE=queue
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
- QUEUE_BULL_REDIS_HOST=redis
- QUEUE_BULL_REDIS_PORT=6379
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_DATABASE=n8ndb
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
depends_on:
- postgres
- redis
- n8n
restart: unless-stopped
El command: worker le dice a n8n que ejecute en modo worker en lugar de servir la interfaz web. La clave de cifrado de n8n debe coincidir exactamente con el proceso principal. Los workers descifran credenciales de la base de datos utilizando esta clave. Un desajuste significa que los flujos de trabajo se ejecutan pero no pueden acceder a las credenciales, lo que genera fallos silenciosos difíciles de depurar.
Inicia un worker inicialmente: docker compose up -d n8n-worker. Revisa los registros: docker logs n8n-worker. Deberías ver «el worker de n8n ahora está listo» y mensajes de conexión para Redis y PostgreSQL. Los workers de n8n registran cuando extraen trabajos, así que inicialmente solo verás mensajes de inicialización.
Escala los workers usando docker compose scale: docker compose up -d –scale n8n-worker=3. Esto crea tres contenedores de workers a partir de la misma definición de servicio. Cada uno se conecta a la misma cola de Redis y base de datos PostgreSQL, extrayendo trabajos de manera independiente.
Cuántos workers necesitas depende de tu carga de trabajo real, no de la teoría. Comienza con uno o dos. Monitoriza la profundidad de la cola y los tiempos de ejecución bajo carga real. Escala si los trabajos se acumulan. Cada worker consume 200-500 MB de RAM. Ejecutar diez workers en un VPS de 4 GB causará kills por OOM.
Prueba la configuración de la cola n8n
Crea un flujo de trabajo con un nodo de Espera configurado a 10 segundos. Añade nodos de Solicitud HTTP simples antes y después para que puedas observar el flujo de ejecución. Guarda y activa.
Inicia el flujo de trabajo manualmente tres veces seguidas desde la interfaz web de configuración de n8n. El modo estándar ejecutaría estos secuencialmente, más de 30 segundos en total. Con los workers en ejecución, se ejecutan en paralelo.
Consulta la lista de ejecución en la interfaz web de n8n. Los tres deberían mostrar el estado «Ejecutándose» simultáneamente si los workers están procesando en paralelo. Observa los registros de los workers docker logs n8n-worker: muestra qué worker extrajo qué ejecución. Verás mensajes como «Trabajo recogido» con identificadores de ejecución.
La monitorización de automatización de n8n en la interfaz web muestra los tiempos de ejecución. Compara con el modo estándar. El modo cola suele tener tiempos por ejecución ligeramente superiores debido a la sobrecarga de la cola, pero el rendimiento total aumenta drásticamente porque los flujos de trabajo se ejecutan concurrentemente.
Monitoriza y escala los workers de n8n
Monitoriza los tiempos de ejecución y la profundidad de la cola durante el uso real. Si la cola de Redis crece constantemente durante las horas pico, los flujos de trabajo están llegando más rápido de lo que los workers pueden procesarlos. Aumenta la capacidad.
Añade workers sobre la marcha: docker compose up -d –scale n8n-worker=5. Los nuevos workers arrancan de inmediato y comienzan a extraer trabajos de la cola de Redis. Sin interrupciones en el flujo de trabajo. Sin cambios en la configuración. Solo más capacidad. Aquí es donde la escalabilidad de n8n realmente se muestra.
Reduce la escala durante períodos tranquilos: docker compose up -d –scale n8n-worker=2. Docker detiene los workers sobrantes de forma ordenada: terminan los trabajos en curso antes de apagarse, sin interrupciones a mitad de proceso.
Monitoriza el uso de recursos por worker con docker stats. Esto muestra la CPU y la RAM para cada contenedor de worker. Si los workers están saturando constantemente la CPU o alcanzando los límites de memoria, optimiza los flujos de trabajo o consigue un VPS más grande. Comprender el rendimiento de n8n implica monitorizar estas métricas a lo largo del tiempo.
Configura N8N_METRICS=true y N8N_METRICS_INCLUDE_API_ENDPOINTS=true en las variables de entorno para habilitar métricas. Esto expone métricas compatibles con Prometheus en el punto final /metrics donde puedes rastrear la profundidad de la cola, números de ejecución y rendimiento de los workers a lo largo del tiempo.
Conclusión
El modo cola convierte n8n de una herramienta para un solo usuario en algo capaz de gestionar cargas de trabajo de producción. Separar la interfaz web, la cola de trabajos y la ejecución distribuida crea una escalabilidad real de n8n que crece con tus necesidades en lugar de alcanzar límites en el peor momento posible.
La configuración no es simple. Has orquestado Docker Compose con múltiples servicios, sincronizado variables de entorno que deben coincidir perfectamente, implementado infraestructura de PostgreSQL y Redis, y lanzado procesos de workers. Pero ahora tienes un sistema de automatización de flujos de trabajo que gestiona cientos de ejecuciones simultáneas sin problemas.
Lo que viene a continuación importa tanto como hacerlo funcionar. Configura copias de seguridad automáticas de PostgreSQL: flujos de trabajo, credenciales e historial de ejecución residen allí. Monitoriza el uso de recursos de los workers y escala de forma proactiva según los patrones de tráfico. Configura la agregación de registros para poder resolver problemas en workers distribuidos. Protege Redis si tu VPS está expuesto a redes que no controlas.
El VPS hosting significa que controlas las decisiones de escalado. Los servicios en la nube de n8n gestionado cobran por ejecución o limitan los flujos de trabajo. Ejecutar modo cola en tu infraestructura significa escalar en función de los costes reales de recursos, no de los niveles de suscripción. El coste es que debes gestionar la complejidad. Pero posees la capacidad.
Preguntas frecuentes del modo de cola de n8n
¿Qué es el modo de cola de n8n?
El modo de cola de n8n separa la interfaz web de la ejecución del flujo de trabajo utilizando una cola de trabajos basada en Redis y procesos de workers separados. El proceso principal de n8n gestiona la interfaz de usuario y los disparadores entrantes, enviando trabajos de flujo de trabajo a las colas de Redis. Los procesos de workers monitorizan esas colas constantemente, extrayendo trabajos y ejecutando flujos de trabajo en paralelo.
Esto permite la escalabilidad horizontal donde añades más workers para gestionar cargas incrementadas sin modificar el código del flujo de trabajo. Requiere PostgreSQL en lugar de SQLite porque múltiples procesos necesitan acceso concurrente a la base de datos. Redis coordina la distribución de trabajos entre workers. Todos los procesos comparten la misma clave de cifrado para descifrar las credenciales de la base de datos.
El resultado es docenas o cientos de flujos de trabajo ejecutándose simultáneamente en lugar de esperar en cola detrás de un solo hilo de ejecución.
¿Cuándo usas n8n en cola?
En resumen: cuando se alcanzan los límites de una sola instancia. Las señales incluyen ejecuciones de flujo de trabajo lentas, tiempos de espera de webhook, retardos en la interfaz al abrir flujos de trabajo y colas de ejecución acumulándose durante el tráfico pico. Si estás procesando más de 100 ejecuciones por hora o ejecutando flujos de trabajo de larga duración que bloquean otras tareas, el modo cola es la opción adecuada.
Es excesivo para uso personal o automatización ligera con algunas ejecuciones diarias. El modo estándar funciona bien cuando las ejecuciones son poco frecuentes y los flujos de trabajo se completan rápidamente. El modo cola añade complejidad — Redis, PostgreSQL, múltiples contenedores, variables de entorno sincronizadas — que solo merece la pena bajo carga real.
Los entornos de producción que gestionan automatización crítica para el negocio necesitan el modo cola para fiabilidad. Incluso si la carga actual no lo exige, la arquitectura proporciona redundancia. Si un worker falla, los demás siguen procesando. El mantenimiento de la base de datos ocurre y los workers pierden brevemente la conexión y luego reanudan sin pérdida de datos porque el estado de la cola persiste en Redis y PostgreSQL.
¿Cuál es la mejor configuración de servidor para n8n?
La mejor configuración de servidor para n8n ejecutando el modo cola comienza con 2 núcleos de CPU y 4 GB de RAM para despliegues pequeños. Esto gestiona el proceso principal, PostgreSQL, Redis, más uno o dos workers procesando flujos de trabajo ligeros. Usarás alrededor de 1 GB para Redis y PostgreSQL combinados, 500 MB para el proceso principal de n8n, y entre 200 y 500 MB por worker dependiendo de la complejidad del flujo de trabajo.
Las configuraciones de producción que gestionan cargas serias requieren un mínimo de 4-8 núcleos de CPU y 8-16 GB de RAM. Esto permite ejecutar múltiples workers de forma concurrente sin contención de recursos. El rendimiento de PostgreSQL aumenta con núcleos de CPU dedicados y suficiente RAM para el almacenamiento en caché. Redis es ligero pero se beneficia de un almacenamiento rápido para la persistencia de la cola.
Monitoriza primero, luego escala en función del uso real en lugar de hacer suposiciones. Ejecuta flujos de trabajo reales bajo carga esperada y observa CPU, RAM y E/S de disco utilizando docker stats y herramientas de monitorización. Si los workers están saturando la CPU, añade núcleos o optimiza los flujos de trabajo. Si la RAM se llena, reduce el número de workers o añade más memoria. El almacenamiento es importante porque el historial de ejecución de PostgreSQL crece con el tiempo, así que ten en cuenta el crecimiento de la base de datos en las estimaciones de capacidad de disco.
