¿Cuándo merece la pena n8n en Kubernetes en lugar de Docker Compose? El Helm Chart oficial, el Queue Mode y Redis explicados.
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.
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.
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.
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.
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.
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.
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.
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.
NordFlux crea empleados digitales para las organizaciones: automatizaciones y agentes KI que asumen el trabajo repetitivo. Usted mantiene el control.
n8n puede funcionar de forma conforme al RGPD, pero no lo es automáticamente. Qué distingue la nube del alojamiento propio y dónde los flujos de trabajo pierden datos.
SSO, Audit-Logs, residencia de datos: a partir de qué plan de n8n comienza la seguridad, y cuándo el alojamiento propio es más económico que Business o Enterprise.
Planes en la nube, autoalojamiento, licencia Sustainable Use: lo que n8n cuesta realmente en la empresa y por qué la licencia rara vez es el principal factor de coste.
El Helm chart, el modo Queue y Redis se configuran rápido, pero mantener Kubernetes en producción exige un conocimiento que rara vez existe en el día a día. NordFlux construye y opera su infraestructura de n8n, desde una VM sencilla hasta un despliegue Kubernetes a escala, según lo que su carga de trabajo realmente necesite.
