n8n en Kubernetes: Helm Chart, Queue Mode y cuándo merece la pena

n8n normalmente se puede ejecutar con Docker Compose en un único servidor en pocos minutos, y para la gran mayoría de las pequeñas y medianas empresas este enfoque resulta totalmente suficiente. Kubernetes con el Helm Chart oficial solo se vuelve relevante cuando los workflows deben distribuirse en varios nodos, escalarse automáticamente o reiniciarse de forma autónoma en caso de fallos, por ejemplo con un volumen de webhooks muy alto o cuando la empresa ya cuenta con una plataforma Kubernetes para otras aplicaciones. El chart oficial es mantenido por el propio n8n en el repositorio n8n-io/n8n-hosting y se publica a través de un registro OCI. Según el README del chart, este admite dos modos de funcionamiento: un modo independiente con SQLite sin dependencias externas y un modo de cola (Queue Mode) que requiere PostgreSQL y Redis y distribuye la carga de trabajo entre pods worker independientes. Estado: agosto de 2026.

¿Qué cubre exactamente el Helm Chart oficial de n8n?

El chart instala n8n mediante el comando helm install con la referencia OCI oci://ghcr.io/n8n-io/n8n-helm-chart/n8n y un archivo values.yaml propio para la configuración. Según la documentación, se requieren al menos Helm 3.12 y un clúster de Kubernetes en versión 1.25 o superior. En el Queue Mode, que es la configuración predeterminada del chart, la arquitectura distingue tres tipos de pods: pods main para la interfaz, la API y los webhooks no productivos, pods worker que procesan los workflows desde la cola de Redis y que normalmente se ejecutan en varias réplicas, así como pods webhook dedicados opcionales para el tráfico de webhooks en producción. El chart también incorpora soporte para el autoescalado horizontal mediante HPA y KEDA, tanto para los workers como para los procesadores de webhooks.

¿Cómo se relacionan el Queue Mode y Redis?

El Queue Mode es el requisito para que varios workers de n8n puedan procesar workflows en paralelo, y para ello n8n necesita Redis como cola. Sin el Queue Mode, una única instancia de n8n procesa los workflows de forma secuencial en el mismo proceso que también sirve la interfaz, lo cual no supone un problema con pocos workflows, pero se convierte en un cuello de botella con carga alta. Con el Queue Mode activado, n8n coloca los workflows que deben ejecutarse en una cola de Redis, de la que los pods worker los recogen y los procesan de forma independiente entre sí. Según la información del repositorio de hosting, para el uso en producción se recomienda Redis a partir de la versión 7, siendo la versión 6 el mínimo requerido en cuanto se configura un nombre de usuario de Redis. PostgreSQL se añade en esta configuración como base de datos principal, ya que SQLite no está previsto para el Queue Mode.

¿Qué requisitos y esfuerzo debería prever de forma realista?

Quien utilice el Helm Chart en producción necesita, además de un clúster de Kubernetes en funcionamiento, experiencia en la operación de PostgreSQL, Redis y la configuración de ingress, ya que el chart se encarga de la orquestación de los componentes de n8n, pero no de la operación de las dependencias externas. Según la documentación del chart, varias instancias main para alta disponibilidad requieren además una licencia Enterprise, así como balanceo de carga basado en sesiones a nivel del balanceador de carga. Para el aislamiento de la ejecución de código, el chart ofrece los llamados task runners como sidecars independientes, que requieren su propia autenticación. En la práctica, esto significa que la sobrecarga operativa frente a una instalación con Docker Compose es notable, desde el mantenimiento del clúster y la monitorización hasta las estrategias de copia de seguridad para Redis y PostgreSQL. Para una pyme con un puñado de automatizaciones que pueden permitirse esperar unos segundos más en la cola, esto suele ser excesivo. El esfuerzo tiene sentido sobre todo cuando los equipos de TI ya cuentan con experiencia en Kubernetes o cuando n8n pasa a formar parte de una plataforma más grande que ya se ejecuta en Kubernetes. Quien no esté seguro de qué modelo de hosting se ajusta a su propia carga de automatización debería aclarar esta cuestión antes de la implementación, por ejemplo en el marco de una consultoría de n8n, en lugar de tener que lidiar posteriormente con una infraestructura sobredimensionada. Echar un vistazo a la calculadora de ROI también ayuda a valorar si el esfuerzo operativo adicional de una solución Kubernetes es proporcional al beneficio de automatización esperado.

Preguntas frecuentes sobre n8n en Kubernetes

¿Necesito obligatoriamente Kubernetes para n8n?

No, para la mayoría de las pymes una instalación con Docker Compose en un único servidor resulta totalmente suficiente. Kubernetes solo se vuelve relevante cuando entran en juego el escalado en varios nodos, la tolerancia a fallos automática o una plataforma Kubernetes ya existente en la empresa. Para empezar o para proyectos de automatización más pequeños, la sobrecarga operativa de un clúster normalmente no está justificada.

¿Tengo que usar obligatoriamente el Queue Mode con el Helm Chart?

No, el chart oficial también admite un modo independiente con SQLite y sin dependencias externas como Redis o PostgreSQL. El Queue Mode solo merece la pena cuando varios workers deben procesar workflows en paralelo, porque entonces una cola de Redis se encarga de la distribución. Para un volumen de workflows único y manejable, el modo independiente es considerablemente más sencillo de operar.

¿Qué versión de Kubernetes necesito para el chart oficial?

Según el README del chart oficial, se requieren como mínimo Helm 3.12 y Kubernetes 1.25. Las versiones de clúster más antiguas no están oficialmente admitidas por el chart, por lo que debería comprobarse una actualización del clúster antes de la instalación. Estos requisitos mínimos pueden cambiar con futuras versiones del chart.

¿Es el chart oficial adecuado para producción o solo para pruebas?

El chart está diseñado para el uso en producción y aporta funciones como el autoescalado horizontal mediante HPA y KEDA, así como pods webhook dedicados para el tráfico en producción. Sin embargo, el requisito es que las dependencias externas como PostgreSQL y Redis se operen ellas mismas de forma lista para producción, ya que el chart solo se encarga de la orquestación del propio n8n. Quien no cuente con esta experiencia operativa internamente debería evaluar el esfuerzo de forma realista antes de tomar una decisión.