{"id":29287,"date":"2026-03-23T10:19:46","date_gmt":"2026-03-23T09:19:46","guid":{"rendered":"https:\/\/contabo.com\/blog\/guia-de-configuracion-del-modo-cola-de-n8n-para-la-escalabilidad-en-vps\/"},"modified":"2026-04-08T18:48:50","modified_gmt":"2026-04-08T16:48:50","slug":"guia-de-configuracion-del-modo-cola-de-n8n-para-la-escalabilidad-en-vps","status":"publish","type":"post","link":"https:\/\/contabo.com\/blog\/es\/guia-de-configuracion-del-modo-cola-de-n8n-para-la-escalabilidad-en-vps\/","title":{"rendered":"Gu\u00eda de configuraci\u00f3n para el modo queue n8n"},"content":{"rendered":"\n
\"Gu\u00eda<\/figure>\n\n\n\n

Una sola instancia de n8n funcion\u00f3 perfectamente durante aproximadamente seis meses. Luego alcanzamos m\u00e1s de 200 ejecuciones de flujos de trabajo al d\u00eda y todo empez\u00f3 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 \u00fanico hilo disponible. n8n simplemente no escalaba.<\/p>\n\n\n\n

El modo cola de n8n soluciona esto al dividir responsabilidades en tu configuraci\u00f3n 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 \u2014pueden ser tres, pueden ser diez\u2014 se quedan extrayendo trabajos de una cola de Redis y ejecutando realmente los flujos de trabajo. As\u00ed que ahora diez flujos de trabajo pueden ejecutarse simult\u00e1neamente en lugar de esperar en cola. Eso es una verdadera automatizaci\u00f3n de flujos de trabajo.<\/p>\n\n\n\n

Configurar\u00e1s esto con Docker Compose, Redis para la cola de trabajos y PostgreSQL porque SQLite no gestiona bien m\u00faltiples procesos (de hecho, los gestiona terriblemente). Las variables de entorno deben coincidir exactamente entre todos los contenedores o nada funcionar\u00e1. Necesitar\u00e1s acceso a VPS y conocimientos de Docker. Prep\u00e1rate para la resoluci\u00f3n de problemas. Pero terminar\u00e1s con una configuraci\u00f3n que puede gestionar cientos de ejecuciones simult\u00e1neas de flujo de trabajo sin atascarse.<\/a><\/p>\n\n\n\n

\u00bfListo para comenzar?<\/p>\n\n\n\n

C\u00f3mo funciona el modo cola de n8n<\/h2>\n\n\n\n

El n8n est\u00e1ndar agrupa todo en un solo proceso. La interfaz web funciona all\u00ed. Los oyentes de webhook se ejecutan all\u00ed. Las ejecuciones de flujo de trabajo se ejecutan all\u00ed. Todos compiten por CPU y memoria. Inicia un flujo de trabajo que procesa un archivo de 50 MB y todo lo dem\u00e1s 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\u00e1 ocupado.<\/p>\n\n\n\n

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\u00eda una descripci\u00f3n de trabajo a Redis con detalles como ID de flujo de trabajo, datos de disparadores y qu\u00e9 credenciales usar. Luego contin\u00faa con la siguiente tarea.<\/a><\/p>\n\n\n\n

Los workers monitorizan constantemente el broker de mensajes Redis. Est\u00e1n 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\u00e1 disponible. Si se activan diez flujos de trabajo simult\u00e1neamente y tienes diez workers en ejecuci\u00f3n, los diez se ejecutan a la vez.<\/p>\n\n\n\n

Todo se conecta a la misma base de datos de PostgreSQL. Las credenciales residen all\u00ed, 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\u00edficos a m\u00e1quinas espec\u00edficas, lo que complicar\u00eda enormemente la orquestaci\u00f3n de flujos de trabajo. La base de datos registra el estado de ejecuci\u00f3n en tiempo real, por lo que el proceso principal te muestra actualizaciones de progreso en la UI a pesar de que la ejecuci\u00f3n est\u00e9 ocurriendo en un contenedor completamente diferente en alguna parte.<\/p>\n\n\n\n

La ejecuci\u00f3n paralela es por qu\u00e9 querr\u00edas lidiar con toda esta complejidad. Un flujo de trabajo que procesa 10.000 filas de una hoja de c\u00e1lculo no bloquea a otro que solo necesita enviar un mensaje a Slack. Por lo general, conviene ejecutar operaciones con archivos de gran tama\u00f1o en workers dedicados con m\u00e1s RAM, mientras que los flujos de trabajo solo de API se ejecutan en workers m\u00e1s peque\u00f1os, aunque esto depende de la carga de trabajo espec\u00edfica.<\/p>\n\n\n\n

Requisitos previos<\/h2>\n\n\n\n

Necesitas un VPS de n8n<\/a> o un Dedicated Server<\/a> con un m\u00ednimo de 2 n\u00facleos de CPU y 4 GB de RAM. Querr\u00e1s 4 o m\u00e1s n\u00facleos y 8 GB o m\u00e1s para entornos de producci\u00f3n que manejen un volumen real de automatizaci\u00f3n 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\u00e1s.<\/p>\n\n\n\n

Docker y Docker Compose deben estar instalados y funcionando. Esta gu\u00eda asume Docker 24+ y Compose v2. Si todav\u00eda est\u00e1s usando \u00abdocker-compose\u00bb (con guion) en lugar de \u00abdocker compose\u00bb (con espacio), est\u00e1s en la versi\u00f3n antigua y deber\u00edas actualizar. La sintaxis de docker compose de n8n cambi\u00f3 recientemente.<\/a><\/p>\n\n\n\n

Deber\u00edas saber ya lo b\u00e1sico de n8n autoalojado. Esto no es \u00abtu primera instalaci\u00f3n de n8n\u00bb; necesitas entender flujos de trabajo, c\u00f3mo funcionan las credenciales y los conceptos generales de n8n alrededor de las variables de entorno. El modo cola a\u00f1ade capas de complejidad sobre esa base. Empieza de forma sencilla si eres nuevo: busca \u00abn8n\u00bb en nuestro blog para ver muchos art\u00edculos \u00fatiles que te ayudar\u00e1n a empezar.<\/p>\n\n\n\n

El conocimiento de PostgreSQL ayuda, pero realmente no es necesario. Tendr\u00e1s un entorno Docker de PostgreSQL en funcionamiento, pero las operaciones reales de la base de datos ocurren autom\u00e1ticamente una vez que tienes los par\u00e1metros de conexi\u00f3n correctos. SQLite no funciona con el modo cola en absoluto. M\u00faltiples procesos tratando de acceder al mismo archivo SQLite crean corrupci\u00f3n. PostgreSQL es obligatorio, no una sugerencia.<\/p>\n\n\n\n

La comodidad con la l\u00ednea de comandos es esencial. Editar\u00e1s archivos docker-compose.yml, definir\u00e1s variables de entorno (muchas) y ejecutar\u00e1s comandos de Docker para escalar workers hacia arriba y hacia abajo. Tambi\u00e9n necesitar\u00e1s revisar los registros cuando los contenedores no inicien. Si navegar por directorios en una terminal y leer mensajes de error te resulta intimidante, familiar\u00edzate con eso primero.<\/p>\n\n\n\n

Configurando el modo cola de n8n<\/h2>\n\n\n\n

La configuraci\u00f3n de n8n para el modo cola sigue un orden espec\u00edfico. Configurar\u00e1s Docker Compose de n8n de forma sistem\u00e1tica: 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\u00e1s fallos de dependencias: los contenedores fallar\u00e1n porque intentar\u00e1n conectarse a servicios que a\u00fan no existen. M\u00e1s tarde, cuando necesites a\u00f1adir capacidad, usar\u00e1s comandos de escalado de Docker Compose para iniciar workers adicionales, pero la configuraci\u00f3n inicial debe hacerse en esta secuencia exacta.<\/p>\n\n\n\n

Prepara un contenedor Redis<\/h3>\n\n\n\n

Redis es el componente base para la distribuci\u00f3n de trabajos de n8n. Los workers extraen trabajos de la cola de Redis. El proceso principal env\u00eda nuevas ejecuciones a esas colas. Sin Redis en funcionamiento, el modo cola no funciona en absoluto.<\/p>\n\n\n\n

Crea un directorio para tu configuraci\u00f3n y a\u00f1ade Redis a la configuraci\u00f3n de Docker Compose. Aqu\u00ed est\u00e1 la definici\u00f3n b\u00e1sica del servicio:<\/p>\n\n\n\n

redis:
  image: redis:7-alpine
  container_name: n8n_redis
  ports:
    - \"6379:6379\"
  volumes:
    - redis_data:\/data
  command: redis-server --appendonly yes
  restart: unless-stopped
<\/code><\/pre>\n\n\n\n
Esa opci\u00f3n –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.<\/p>\n\n\n\n
Para la conexi\u00f3n de Redis en n8n, los workers y el proceso principal se conectar\u00e1n usando redis como nombre de host, ya que todos est\u00e1n en la misma red de Docker. El puerto 6379 es el predeterminado de Redis. Puedes a\u00f1adir autenticaci\u00f3n por contrase\u00f1a con –requirepass yourpassword en el comando, aunque para contenedores en una red Docker privada es opcional.<\/p>\n\n\n\n
Inicia solo Redis: docker compose up -d redis. Revisa los registros de inmediato: docker logs n8n_redis. Deber\u00edas ver \u00abListo para aceptar conexiones\u00bb sin errores. Prueba desde tu host usando redis-cli ping antes de avanzar. Conviene detectar problemas de conexi\u00f3n ahora, antes de configurar los dem\u00e1s contenedores.<\/p>\n\n\n\n
Configura las variables de entorno<\/h3>\n\n\n\n
Las variables de entorno controlan c\u00f3mo opera n8n en modo cola. Si la configuraci\u00f3n de n8n no es correcta, los procesos no se comunicar\u00e1n, los workers no arrancar\u00e1n, o peor a\u00fan, funcionar\u00e1n parcialmente pero corromper\u00e1n datos porque la clave de cifrado no coincide.<\/p>\n\n\n\n
Estas son las variables de entorno cr\u00edticas de n8n para la configuraci\u00f3n de n8n:<\/a><\/p>\n\n\n\n
EXECUTIONS_MODE=queue<\/strong> cambia n8n de modo predeterminado a modo cola. Config\u00faralo en el proceso principal y en todos los workers. Sin esto, n8n solo funciona en modo est\u00e1ndar de un solo proceso e ignora Redis por completo.<\/a><\/p>\n\n\n\n
N8N_ENCRYPTION_KEY<\/strong> debe ser id\u00e9ntico 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\u00ed que los flujos de trabajo se ejecutan pero fallan cuando intentan acceder a APIs o bases de datos. Los fallos silenciosos son los m\u00e1s dif\u00edciles de depurar. Genera una cadena aleatoria larga una vez, reutil\u00edzala en todos los contenedores y no la modifiques despu\u00e9s del despliegue a menos que quieras migrar manualmente todos los datos cifrados.<\/a><\/p>\n\n\n\n
QUEUE_BULL_REDIS_HOST y QUEUE_BULL_REDIS_PORT<\/strong> apuntan a Redis. Usa el nombre del servicio de Docker como el host ya que los contenedores se comunican a trav\u00e9s de la red interna de Docker. El puerto es 6379 a menos que lo hayas cambiado.<\/a><\/p>\n\n\n\n
DB_TYPE=postgresdb<\/strong> cambia de SQLite a PostgreSQL. Luego a\u00f1ade: DB_POSTGRESDB_HOST, DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_USER y DB_POSTGRESDB_PASSWORD<\/strong>. Todos los procesos se conectan a la misma base de datos con las credenciales id\u00e9nticas.<\/a><\/p>\n\n\n\n
Pon estos en un .env o directamente en docker-compose.yml bajo secciones de entorno. La configuraci\u00f3n se mantiene consistente a trav\u00e9s de los procesos principales y de workers excepto por algunos ajustes espec\u00edficos de workers.<\/p>\n\n\n\n
Despliega el proceso principal de n8n<\/h3>\n\n\n\n
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\u00faan con esto en el puerto 5678. Este es el n\u00facleo de tu despliegue de n8n.<\/p>\n\n\n\n
Aqu\u00ed est\u00e1 la definici\u00f3n del servicio de docker de n8n en docker-compose.yml para la instalaci\u00f3n de n8n:<\/a><\/p>\n\n\n\n
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
<\/code><\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
In\u00edcialo: docker compose up -d n8n. Revisa los registros de inmediato: docker logs -f n8n_main. Deber\u00edas ver mensajes de conexi\u00f3n exitosa a la base de datos y \u00abEl editor ahora es accesible a trav\u00e9s de\u00bb sin errores. Los fallos de conexi\u00f3n 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\u00e1 correctamente.<\/p>\n\n\n\n
Accede a la interfaz web en http:\/\/your-vps-ip:5678<\/a>. Crea un flujo de trabajo de prueba pero no lo ejecutes a\u00fan: los workers no est\u00e1n en ejecuci\u00f3n, as\u00ed que las ejecuciones se quedar\u00e1n en cola para siempre.<\/p>\n\n\n\n
Despliega la base de datos PostgreSQL<\/h3>\n\n\n\n
PostgreSQL almacena flujos de trabajo, credenciales, historial de ejecuci\u00f3n y estado de la cola. El modo cola necesita PostgreSQL porque m\u00faltiples procesos acceden a la base de datos de n8n simult\u00e1neamente. SQLite no puede gestionar esto de forma segura; en realidad no puede hacerlo en absoluto sin corromper datos.<\/p>\n\n\n\n
Agrega el servicio PostgreSQL de n8n a docker-compose.yml:<\/p>\n\n\n\n
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
<\/code><\/pre>\n\n\n\n
Las credenciales de la base de datos aqu\u00ed coinciden con las que colocaste en la configuraci\u00f3n principal de n8n. El contenedor de PostgreSQL persiste los datos en un volumen de Docker para que los contenidos sobrevivan a los reinicios.<\/p>\n\n\n\n
Para la configuraci\u00f3n de Docker de PostgreSQL, la base de datos se inicializa autom\u00e1ticamente la primera vez que se inicia. No es necesario ejecutar scripts SQL manualmente; n8n gestiona la creaci\u00f3n del esquema cuando se conecta por primera vez. Inicia PostgreSQL: docker compose up -d postgres. Revisa los registros: docker logs n8n_postgres. Busca \u00abel sistema de base de datos est\u00e1 listo para aceptar conexiones\u00bb.<\/p>\n\n\n\n
Si ya comenzaste el proceso principal de n8n, se conectar\u00e1 a PostgreSQL e inicializar\u00e1 las tablas autom\u00e1ticamente. Revisa los registros de n8n de nuevo para verificar mensajes de migraci\u00f3n de base de datos exitosa.<\/p>\n\n\n\n
Inicia procesos n8n Worker<\/h3>\n\n\n\n
Los workers son instancias de n8n ejecut\u00e1ndose en modo worker. Sin interfaz web. Sin puertos expuestos. Extraen trabajos de Redis, ejecutan flujos de trabajo y escriben resultados en PostgreSQL. Nada m\u00e1s.<\/a><\/p>\n\n\n\n
Aqu\u00ed est\u00e1 la definici\u00f3n del servicio de trabajador de n8n, similar al principal pero con diferencias clave:<\/p>\n\n\n\n
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
<\/code><\/pre>\n\n\n\n
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\u00edciles de depurar.<\/p>\n\n\n\n
Inicia un worker inicialmente: docker compose up -d n8n-worker. Revisa los registros: docker logs n8n-worker. Deber\u00edas ver \u00abel worker de n8n ahora est\u00e1 listo\u00bb y mensajes de conexi\u00f3n para Redis y PostgreSQL. Los workers de n8n registran cuando extraen trabajos, as\u00ed que inicialmente solo ver\u00e1s mensajes de inicializaci\u00f3n.<\/p>\n\n\n\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\u00f3n de servicio. Cada uno se conecta a la misma cola de Redis y base de datos PostgreSQL, extrayendo trabajos de manera independiente.<\/p>\n\n\n\n
Cu\u00e1ntos workers necesitas depende de tu carga de trabajo real, no de la teor\u00eda. Comienza con uno o dos. Monitoriza la profundidad de la cola y los tiempos de ejecuci\u00f3n 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\u00e1 kills por OOM.<\/p>\n\n\n\n
Prueba la configuraci\u00f3n de la cola n8n<\/h3>\n\n\n\n
Crea un flujo de trabajo con un nodo de Espera configurado a 10 segundos. A\u00f1ade nodos de Solicitud HTTP simples antes y despu\u00e9s para que puedas observar el flujo de ejecuci\u00f3n. Guarda y activa.<\/p>\n\n\n\n
Inicia el flujo de trabajo manualmente tres veces seguidas desde la interfaz web de configuraci\u00f3n de n8n. El modo est\u00e1ndar ejecutar\u00eda estos secuencialmente, m\u00e1s de 30 segundos en total. Con los workers en ejecuci\u00f3n, se ejecutan en paralelo.<\/p>\n\n\n\n
Consulta la lista de ejecuci\u00f3n en la interfaz web de n8n. Los tres deber\u00edan mostrar el estado \u00abEjecut\u00e1ndose\u00bb simult\u00e1neamente si los workers est\u00e1n procesando en paralelo. Observa los registros de los workers docker logs n8n-worker: muestra qu\u00e9 worker extrajo qu\u00e9 ejecuci\u00f3n. Ver\u00e1s mensajes como \u00abTrabajo recogido\u00bb con identificadores de ejecuci\u00f3n.<\/p>\n\n\n\n
La monitorizaci\u00f3n de automatizaci\u00f3n de n8n en la interfaz web muestra los tiempos de ejecuci\u00f3n. Compara con el modo est\u00e1ndar. El modo cola suele tener tiempos por ejecuci\u00f3n ligeramente superiores debido a la sobrecarga de la cola, pero el rendimiento total aumenta dr\u00e1sticamente porque los flujos de trabajo se ejecutan concurrentemente.<\/p>\n\n\n\n
Monitoriza y escala los workers de n8n<\/h3>\n\n\n\n
Monitoriza los tiempos de ejecuci\u00f3n 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\u00e1n llegando m\u00e1s r\u00e1pido de lo que los workers pueden procesarlos. Aumenta la capacidad.<\/p>\n\n\n\n
A\u00f1ade 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\u00f3n. Solo m\u00e1s capacidad. Aqu\u00ed es donde la escalabilidad de n8n realmente se muestra.<\/p>\n\n\n\n
Reduce la escala durante per\u00edodos 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.<\/p>\n\n\n\n
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\u00e1n saturando constantemente la CPU o alcanzando los l\u00edmites de memoria, optimiza los flujos de trabajo o consigue un VPS m\u00e1s grande. Comprender el rendimiento de n8n implica monitorizar estas m\u00e9tricas a lo largo del tiempo.<\/p>\n\n\n\n
Configura N8N_METRICS=true y N8N_METRICS_INCLUDE_API_ENDPOINTS=true en las variables de entorno para habilitar m\u00e9tricas. Esto expone m\u00e9tricas compatibles con Prometheus en el punto final \/metrics donde puedes rastrear la profundidad de la cola, n\u00fameros de ejecuci\u00f3n y rendimiento de los workers a lo largo del tiempo.<\/p>\n\n\n\n
Conclusi\u00f3n<\/h2>\n\n\n\n
El modo cola convierte n8n de una herramienta para un solo usuario en algo capaz de gestionar cargas de trabajo de producci\u00f3n. Separar la interfaz web, la cola de trabajos y la ejecuci\u00f3n distribuida crea una escalabilidad real de n8n que crece con tus necesidades en lugar de alcanzar l\u00edmites en el peor momento posible.<\/a><\/p>\n\n\n\n
La configuraci\u00f3n no es simple. Has orquestado Docker Compose con m\u00faltiples 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\u00f3n de flujos de trabajo que gestiona cientos de ejecuciones simult\u00e1neas sin problemas.<\/a><\/p>\n\n\n\n
Lo que viene a continuaci\u00f3n importa tanto como hacerlo funcionar. Configura copias de seguridad autom\u00e1ticas de PostgreSQL: flujos de trabajo, credenciales e historial de ejecuci\u00f3n residen all\u00ed. Monitoriza el uso de recursos de los workers y escala de forma proactiva seg\u00fan los patrones de tr\u00e1fico. Configura la agregaci\u00f3n de registros para poder resolver problemas en workers distribuidos. Protege Redis si tu VPS est\u00e1 expuesto a redes que no controlas.<\/p>\n\n\n\n
El VPS hosting significa que controlas las decisiones de escalado. Los servicios en la nube de n8n gestionado cobran por ejecuci\u00f3n o limitan los flujos de trabajo. Ejecutar modo cola en tu infraestructura significa escalar en funci\u00f3n de los costes reales de recursos, no de los niveles de suscripci\u00f3n. El coste es que debes gestionar la complejidad. Pero posees la capacidad.<\/p>\n\n\n\n
Preguntas frecuentes del modo de cola de n8n<\/h2>\n\n\n\n
\u00bfQu\u00e9 es el modo de cola de n8n?<\/h3>\n\n\n\n
El modo de cola de n8n separa la interfaz web de la ejecuci\u00f3n 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.<\/p>\n\n\n\n
Esto permite la escalabilidad horizontal donde a\u00f1ades m\u00e1s workers para gestionar cargas incrementadas sin modificar el c\u00f3digo del flujo de trabajo. Requiere PostgreSQL en lugar de SQLite porque m\u00faltiples procesos necesitan acceso concurrente a la base de datos. Redis coordina la distribuci\u00f3n de trabajos entre workers. Todos los procesos comparten la misma clave de cifrado para descifrar las credenciales de la base de datos.<\/a><\/p>\n\n\n\n
El resultado es docenas o cientos de flujos de trabajo ejecut\u00e1ndose simult\u00e1neamente en lugar de esperar en cola detr\u00e1s de un solo hilo de ejecuci\u00f3n.<\/p>\n\n\n\n
\u00bfCu\u00e1ndo usas n8n en cola?<\/h3>\n\n\n\n
En resumen: cuando se alcanzan los l\u00edmites de una sola instancia. Las se\u00f1ales 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\u00f3n acumul\u00e1ndose durante el tr\u00e1fico pico. Si est\u00e1s procesando m\u00e1s de 100 ejecuciones por hora o ejecutando flujos de trabajo de larga duraci\u00f3n que bloquean otras tareas, el modo cola es la opci\u00f3n adecuada.<\/p>\n\n\n\n
Es excesivo para uso personal o automatizaci\u00f3n ligera con algunas ejecuciones diarias. El modo est\u00e1ndar funciona bien cuando las ejecuciones son poco frecuentes y los flujos de trabajo se completan r\u00e1pidamente. El modo cola a\u00f1ade complejidad \u2014 Redis, PostgreSQL, m\u00faltiples contenedores, variables de entorno sincronizadas \u2014 que solo merece la pena bajo carga real.<\/p>\n\n\n\n
Los entornos de producci\u00f3n que gestionan automatizaci\u00f3n cr\u00edtica 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\u00e1s siguen procesando. El mantenimiento de la base de datos ocurre y los workers pierden brevemente la conexi\u00f3n y luego reanudan sin p\u00e9rdida de datos porque el estado de la cola persiste en Redis y PostgreSQL.<\/p>\n\n\n\n
\u00bfCu\u00e1l es la mejor configuraci\u00f3n de servidor para n8n?<\/h3>\n\n\n\n
La mejor configuraci\u00f3n de servidor para n8n ejecutando el modo cola comienza con 2 n\u00facleos de CPU y 4 GB de RAM para despliegues peque\u00f1os. Esto gestiona el proceso principal, PostgreSQL, Redis, m\u00e1s uno o dos workers procesando flujos de trabajo ligeros. Usar\u00e1s 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.<\/p>\n\n\n\n
Las configuraciones de producci\u00f3n que gestionan cargas serias requieren un m\u00ednimo de 4-8 n\u00facleos de CPU y 8-16 GB de RAM. Esto permite ejecutar m\u00faltiples workers de forma concurrente sin contenci\u00f3n de recursos. El rendimiento de PostgreSQL aumenta con n\u00facleos de CPU dedicados y suficiente RAM para el almacenamiento en cach\u00e9. Redis es ligero pero se beneficia de un almacenamiento r\u00e1pido para la persistencia de la cola.<\/p>\n\n\n\n
Monitoriza primero, luego escala en funci\u00f3n 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\u00f3n. Si los workers est\u00e1n saturando la CPU, a\u00f1ade n\u00facleos o optimiza los flujos de trabajo. Si la RAM se llena, reduce el n\u00famero de workers o a\u00f1ade m\u00e1s memoria. El almacenamiento es importante porque el historial de ejecuci\u00f3n de PostgreSQL crece con el tiempo, as\u00ed que ten en cuenta el crecimiento de la base de datos en las estimaciones de capacidad de disco.<\/p>\n","protected":false},"excerpt":{"rendered":"
El modo cola de n8n transforma una configuraci\u00f3n de automatizaci\u00f3n de flujos de trabajo de una sola instancia en un sistema distribuido capaz de manejar cientos de ejecuciones simult\u00e1neas. Esta gu\u00eda te acompa\u00f1a en todo el proceso de configuraci\u00f3n utilizando Docker Compose en un VPS: configurar Redis como cola de trabajos, desplegar PostgreSQL para el estado compartido, definir las variables de entorno entre los contenedores, iniciar el proceso principal de n8n y escalar los procesos worker que ejecutan los flujos de trabajo en paralelo. Aprender\u00e1s cu\u00e1ndo el modo cola tiene sentido (m\u00e1s de 100 ejecuciones por hora, flujos de trabajo de larga duraci\u00f3n bloqueando otras tareas), qu\u00e9 recursos del servidor necesitas (m\u00ednimo 2 n\u00facleos de CPU y 4 GB de RAM), y c\u00f3mo monitorear y escalar workers basados en la carga real. La configuraci\u00f3n requiere conocimientos de Docker y comodidad con la l\u00ednea de comandos, pero ofrece escalabilidad de n8n de grado de producci\u00f3n que crece con tus demandas de automatizaci\u00f3n de flujos de trabajo.<\/p>\n","protected":false},"author":63,"featured_media":28006,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"_uag_custom_page_level_css":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1988],"tags":[],"ppma_author":[1492],"class_list":["post-29287","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutoriales"],"uagb_featured_image_src":{"full":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_ES.webp",1200,630,false],"thumbnail":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_ES-150x150.webp",150,150,true],"medium":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_ES-600x315.webp",600,315,true],"medium_large":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_ES-768x403.webp",768,403,true],"large":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_ES.webp",1200,630,false],"1536x1536":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_ES.webp",1200,630,false],"2048x2048":["https:\/\/contabo.com\/blog\/wp-content\/uploads\/2026\/02\/blog-head_guide-n8n-queue-mode-setup_ES.webp",1200,630,false]},"uagb_author_info":{"display_name":"Christopher Carter","author_link":"https:\/\/contabo.com\/blog\/es\/author\/christophercarter\/"},"uagb_comment_info":0,"uagb_excerpt":"El modo cola de n8n transforma una configuraci\u00f3n de automatizaci\u00f3n de flujos de trabajo de una sola instancia en un sistema distribuido capaz de manejar cientos de ejecuciones simult\u00e1neas. Esta gu\u00eda te acompa\u00f1a en todo el proceso de configuraci\u00f3n utilizando Docker Compose en un VPS: configurar Redis como cola de trabajos, desplegar PostgreSQL para el…","authors":[{"term_id":1492,"user_id":63,"is_guest":0,"slug":"christophercarter","display_name":"Christopher Carter","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/63db81672a5ce4c1e8ee39753d00251d561b5b3a9967febf1c4f662024cef00f?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/posts\/29287","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/users\/63"}],"replies":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/comments?post=29287"}],"version-history":[{"count":7,"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/posts\/29287\/revisions"}],"predecessor-version":[{"id":29822,"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/posts\/29287\/revisions\/29822"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/media\/28006"}],"wp:attachment":[{"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/media?parent=29287"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/categories?post=29287"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/tags?post=29287"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/contabo.com\/blog\/es\/wp-json\/wp\/v2\/ppma_author?post=29287"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}