Modo de cola de n8n para Hostinger VPS: un ejercicio de despliegue económico
Este ejercicio despliega n8n en modo de cola en un VPS de Hostinger: requisitos, dimensionamiento, Redis, PostgreSQL y verificación de los workers.
Comprobado con las fuentes citadas el .
Resumen de la tarea: qué construirás y verificarás
Este artículo plantea un ejercicio editorial sobre el despliegue del modo de cola de n8n para un VPS de Hostinger: pasar de una configuración de instancia única a un proceso principal respaldado por Redis y uno o más workers, sin saltar directamente a un servidor de tamaño empresarial. La documentación oficial de n8n sobre escalado describe el modo de cola como el modo de ejecución que ofrece la mejor escalabilidad, razón por la cual los equipos acaban superando un único contenedor. El ejercicio que sigue mantiene todo en una sola máquina virtual modesta, de modo que un líder técnico pueda ver exactamente qué exige ese cambio en la práctica, en lugar de leer sobre él solo en abstracto.
Tarea: construir una pila de n8n en modo de cola que funcione —proceso principal, Redis, PostgreSQL y al menos un worker— en un único VPS económico, y luego verificar que un flujo de trabajo programado o activado manualmente se ejecute realmente mediante un worker y no mediante el proceso principal. Esto se presenta como un ejercicio práctico para que lo realices en tu propia infraestructura; a continuación describimos capacidades documentadas y una ruta recomendada, pero nosotros mismos no hemos ejecutado cada paso ni medido el resultado, así que trata las indicaciones de dimensionamiento como un punto de partida y no como un referente validado.
Sources: Scaling | Deploy | n8n Docs
Requisitos previos, entradas y restricciones
Requisitos previos: una cuenta de VPS en Hostinger (o un proveedor equivalente, aunque las notas de dimensionamiento siguientes son específicas de Hostinger), Docker y Docker Compose instalados en ese VPS, suficiente soltura con una terminal de Linux para editar archivos .env y ejecutar comandos de compose, y una configuración de n8n existente que ya entiendas en modo normal, sin cola. No necesitas experiencia previa administrando Redis o PostgreSQL, pero deberías estar dispuesto a leer los registros de los contenedores cuando algo no arranque a la primera. Esta sección establece lo que requiere específicamente el modo de cola de n8n en un VPS de Hostinger, y no lo que necesitaría un servidor genérico.
Entradas y restricciones: este ejercicio se limita a un único VPS que ejecuta todos los componentes juntos —proceso principal, Redis, PostgreSQL y workers—, no a una configuración multiservidor o multi-main. El presupuesto es la principal restricción: esta configuración necesita más vCPU que el mínimo absoluto, que se dimensiona en la siguiente sección, y la propia documentación de n8n recomienda no ejecutar EXECUTIONS_MODE=queue con una base de datos SQLite, lo que descarta la configuración más ligera posible. Por tanto, el ejercicio asume un plan de VPS con más margen que el mínimo absoluto de n8n para una sola instancia, y un contenedor de PostgreSQL desde el principio.
Sources: Enable queue mode | Deploy | n8n Docs, Parameters and limits of hosting plans in Hostinger, What are the VPS requirements for n8n?
Dimensionamiento del modo de cola de n8n para Hostinger VPS
La propia guía de requisitos de VPS de Hostinger indica un mínimo absoluto de 1 núcleo vCPU, 2 GB de RAM y 20 GB de almacenamiento SSD para ejecutar n8n, pero esa cifra describe una configuración de instancia única, no el modo de cola. El tutorial de modo de cola de Hostinger, por separado, recomienda al menos 2 vCPU una vez que Redis, PostgreSQL, el proceso principal y los workers se ejecutan todos juntos, y señala su propio plan KVM 2 como un ajuste cómodo para una configuración básica con tres workers. Se trata de recomendaciones del proveedor, no de resultados de pruebas de carga independientes, así que conviene leerlas como un punto de partida para dimensionar el modo de cola de n8n en Hostinger VPS, no como una garantía.
La propia página de límites de los planes de Hostinger indica que estas cifras de vCPU, RAM y ancho de banda pueden cambiar sin previo aviso, así que trata la tabla siguiente como una instantánea y confirma las cifras actuales en tu panel de VPS antes de basar una compra en ellas.
La misma guía de Hostinger señala, citando la propia documentación de n8n, que la memoria suele ser más crítica que la CPU para el rendimiento de n8n, algo que importa en cuanto Redis y PostgreSQL compiten por la RAM junto con el proceso principal y los workers. Ese razonamiento tiene una implicación práctica a la hora de elegir un plan: como la carga de trabajo no depende tanto de la CPU, conviene priorizar la RAM sobre vCPU adicionales si más adelante necesitas ampliar. Un redactor de contenido de Hostinger extrae una conclusión relacionada sobre esta misma configuración:
| Plan | Núcleos vCPU | RAM | Ancho de banda | Ajuste señalado por las fuentes |
|---|---|---|---|---|
| Mínimo absoluto de n8n (cualquier VPS) | 1 | 2 GB | No documentado | La guía general de n8n de Hostinger indica esto como el suelo mínimo, no dimensionado para el modo de cola |
| Hostinger KVM1 | 1 | 4 GB | 4 TB | Por debajo de la recomendación de 2 vCPU de Hostinger para el modo de cola |
| Hostinger KVM2 | 2 | 8 GB | 8 TB | Señalado como un ajuste cómodo para el proceso principal, Redis, PostgreSQL y tres workers |
En nuestra opinión, dimensionar directamente al nivel equivalente a KVM2 es la decisión pragmática para este ejercicio, ya que apretar el proceso principal, Redis, PostgreSQL y los workers en la especificación mínima absoluta sobre todo invita a una resolución de problemas evitable. En cuanto a la persistencia, la propia documentación de Redis advierte que el snapshotting RDB por sí solo no es ideal si necesitas minimizar la pérdida de datos cuando Redis se detiene de forma inesperada, y recomienda en su lugar la política AOF predeterminada de sincronizar con el disco cada segundo; ten en cuenta también que la variable de nombre de usuario de Redis que expone n8n requiere Redis versión 6 o superior.
Sources: Configuring n8n in queue mode for improved scalability, Parameters and limits of hosting plans in Hostinger, What are the VPS requirements for n8n?, VPS Hosting | Powerful KVM-based Virtual Private Server, Redis persistence, Queue mode | Deploy | n8n Docs
Configurar el modo de cola y desplegar el proceso principal y los workers
El ejemplo de referencia oficial de Docker Compose de n8n establece EXECUTIONS_MODE=queue en todos los contenedores y los apunta a un servicio Redis llamado redis, con comprobaciones de estado habilitadas en el propio archivo de compose. En ese mismo ejemplo, el servicio worker reutiliza el bloque de configuración compartido del servicio principal y simplemente sobrescribe el comando para ejecutarse como worker en lugar de iniciar el proceso normal, sin necesitar su propia imagen o build independiente.
Cada worker que inicias se ejecuta como su propia instancia de Node.js que opera en modo main, según la documentación oficial de n8n, que es como el modo de cola distribuye la ejecución entre varios procesos en lugar de uno solo. n8n recomienda establecer la concurrencia de los workers en 5 o más, aunque también advierte que combinar una concurrencia baja con muchos workers puede agotar el pool de conexiones de la base de datos. En modo de cola, establecer N8N_CONCURRENCY_PRODUCTION_LIMIT en cualquier valor distinto de -1 sobrescribe la opción --concurrency del comando del worker, mientras que un control de concurrencia relacionado en modo normal solo se aplica a las ejecuciones de producción.
Una respuesta del foro de la comunidad de n8n de enero de 2022 señala que no hay una diferencia real entre las imágenes Docker de worker, main y webhook, y que solo cambia el comando de inicio entre ellas. Trataríamos esa nota del foro con cautela: es una única respuesta de la comunidad de 2022, marcada como potencialmente desactualizada, no una garantía de que las imágenes actuales de worker y main sigan comportándose de forma idéntica. Como precaución editorial, sugerimos establecer una sola N8N_ENCRYPTION_KEY y compartirla entre el contenedor principal y todos los contenedores worker desde el principio, para que la configuración relacionada con las credenciales se mantenga coherente a medida que añades workers.
Sources: Enable queue mode | Deploy | n8n Docs, n8n-hosting/docker-compose/withPostgresAndWorker/docker-compose.yml at main · n8n-io/n8n-hosting · GitHub, Control concurrency | Deploy | n8n Docs, N8N Queue mode load testing - Questions - n8n Community
Criterios de finalización, resolución de problemas y reflexión
Criterios de finalización de este ejercicio: la documentación oficial de monitorización de n8n indica que el endpoint /healthz/readiness devuelve HTTP 200 en cuanto la base de datos está conectada, lo cual es una primera comprobación útil del proceso principal. En el caso específico de los workers, tanto el endpoint de comprobación de estado como el endpoint /metrics están deshabilitados por defecto, así que es necesario habilitar deliberadamente QUEUE_HEALTH_CHECK_ACTIVE y el indicador de métricas para usarlos. El tutorial de Hostinger sobre cómo ejecutar el modo de cola de n8n en un VPS de Hostinger sugiere confirmar que realmente funciona comprobando los registros de los workers en busca de una entrada 'Worker started execution' después de activar un flujo de trabajo.
Si nada se ejecuta, los dos culpables más probables son los que la propia documentación señala directamente: la limitación de SQLite ya mencionada antes en los requisitos previos, o una configuración de concurrencia de los workers demasiado baja para el número de workers en ejecución, como explicamos antes al introducir la concurrencia. Revisa los registros de los contenedores tanto del proceso principal como de cada worker antes de asumir que el problema es el propio Redis.
Reflexión: si tus workers se registran y un flujo de trabajo activado aparece en sus registros, tienes una configuración de modo de cola de n8n realmente funcional en un VPS de Hostinger, limitada deliberadamente a una sola máquina en lugar de un clúster distribuido. Creemos que ejecutar este ejercicio en un VPS económico antes de asumir una factura de nube mayor es un buen uso de una tarde, ya que pone de manifiesto cada decisión de configuración que impone el modo de cola —claves de cifrado compartidas, PostgreSQL, concurrencia de los workers— sin comprometer a un equipo con una infraestructura mayor de entrada. Trata la ampliación más allá de un VPS, los hosts separados de Redis y Postgres, o las configuraciones multi-main como un objetivo futuro, no como parte de este ejercicio.
Sources: Monitor n8n | Deploy | n8n Docs, Configuring n8n in queue mode for improved scalability, Enable queue mode | Deploy | n8n Docs
