Cuándo necesitas escalar n8n
Una instancia básica de n8n con Docker maneja sin problemas decenas de workflows y cientos de ejecuciones diarias. Pero cuando gestionas automatizaciones para múltiples clientes, procesas miles de webhooks por hora, o ejecutas workflows pesados con llamadas a IA, necesitas una arquitectura que escale horizontalmente. Ahí es donde Kubernetes entra en juego.
Arquitectura n8n en modo Queue
n8n soporta un modo de ejecución distribuido llamado Queue Mode. En lugar de que una sola instancia ejecute todos los workflows, la arquitectura se divide en: un Main instance (maneja el editor, webhooks y scheduling), múltiples Workers (ejecutan los workflows en paralelo), y Redis como broker de mensajes entre el main y los workers.
Esta arquitectura permite escalar workers independientemente según la carga. Si un lunes por la mañana se disparan 500 workflows simultáneamente, Kubernetes puede auto-escalar de 2 a 10 workers en segundos con un HPA (Horizontal Pod Autoscaler) basado en la profundidad de la cola de Redis.
Despliegue con Helm Chart
n8n ofrece un Helm chart oficial que simplifica el despliegue en Kubernetes. El chart incluye: el deployment del main instance, el deployment de workers (con réplicas configurables), el StatefulSet de PostgreSQL (o puedes apuntar a un servicio managed como RDS/Cloud SQL), el deployment de Redis, Ingress con TLS, y ConfigMaps/Secrets para la configuración.
Para equipos DevOps que ya gestionan clusters de Kubernetes, integrar n8n es natural. Puedes incluirlo en tu pipeline de CI/CD con Jenkins y gestionarlo como cualquier otro servicio del cluster.
Persistencia y alta disponibilidad
En Kubernetes, la persistencia de datos requiere atención especial. PostgreSQL debe usar PersistentVolumeClaims con una StorageClass adecuada (por ejemplo, gp3 en AWS, pd-ssd en GCP). Redis puede ser efímero (los mensajes en cola son transitorios), pero para mayor resiliencia, usa Redis Cluster o un servicio managed como ElastiCache.
Para alta disponibilidad del main instance, configura un deployment con al menos 2 réplicas y un leader election mechanism. Los workers son stateless por naturaleza, así que escalarlos es trivial. Monitoriza la salud de cada componente con probes de Kubernetes y métricas de Prometheus.
Monitorización del cluster n8n
n8n expone métricas en formato Prometheus (/metrics) que incluyen: número de workflows activos, ejecuciones en cola, tiempo medio de ejecución, errores por tipo, y uso de memoria. Combina estas métricas con las de Kubernetes (CPU, memoria, network) en un dashboard de Grafana para tener visibilidad completa.
Configura alertas para: cola de workers creciendo (indica que necesitas más workers), errores de credenciales (puede indicar tokens expirados), y consumo de memoria alto (algunos nodos de n8n pueden consumir mucha RAM al procesar datasets grandes).
Costes y optimización
El coste de ejecutar n8n en Kubernetes depende del cluster. Un setup mínimo en AWS EKS: un nodo t3.medium para el main ($30/mes), dos nodos t3.small para workers ($15/mes cada uno), RDS PostgreSQL db.t3.micro ($15/mes), ElastiCache Redis cache.t3.micro ($12/mes). Total: ~$87/mes para una plataforma de automatización sin límites de workflows ni ejecuciones. Comparado con Zapier Business a $599/mes (con límite de 50.000 tasks), el ahorro es significativo.
Para optimizar costes, usa Spot Instances para los workers (si un worker se interrumpe, el job vuelve a la cola y otro worker lo recoge), configura cluster autoscaler para reducir nodos en horarios de baja actividad, y programa los workflows pesados (reportes, backups, sincronizaciones masivas) en horarios valle.
