Por qué creamos HeroCtl

Cada cluster que opera en producción hoy tiene que decidir entre tres caminos, y ninguno de ellos es lo bastante bueno para el equipo de cinco personas que intenta lanzar un SaaS.

El camino doloroso: Kubernetes

Abres un manifiesto de "hello world" y tiene 300 líneas. Añades un templating manager para organizar — ahora son 300 líneas más 200 líneas de plantillas. Decides usar una versión gestionada en la nube para evitar mantener el plano de control — pagas US$73/mes por cluster, más NAT, más Application Load Balancer. ¿Necesitas TLS automático? Instalas un operador especializado. ¿Métricas? Otro operador. ¿Enrutamiento entre servicios con cifrado? Dos operadores más y dos días estudiando service mesh. ¿Logs centralizados? Otro stack más.

La complejidad no es accidental. El sistema es una plataforma para construir plataformas — hecha por un equipo que necesitaba orquestar 100 mil máquinas. Cuando una startup con cuatro servidores adopta la misma herramienta, está usando una excavadora para plantar un esqueje. Tratamos la tesis general en Kubernetes overkill: cuándo no lo necesitas.

"Most development teams find Kubernetes overkill for dev environments." — Top 13 Kubernetes Alternatives 2026

El coste real no es la infra, es el equipo. Operadores serios de ese sistema cobran salarios de seis cifras. Necesitas al menos uno en el equipo — preferiblemente dos para guardia. Es tu primer ingeniero contratado después del CTO. Antes del diseñador, antes del segundo dev de producto, antes de cualquier cosa que entregue valor al usuario.

El camino fácil: paneles self-hosted modernos

Un comando de instalación en un único servidor, abres el panel, despliegas en cinco minutos. Funciona. Los dos líderes de ese segmento suman 80 mil estrellas en repositorios públicos. La comunidad explotó en los últimos dos años porque resolvió el problema correcto: la mayoría de los equipos no necesita el coloso, necesita Heroku auto-hospedado.

El problema solo aparece después. Creces, el cliente pide SLA, el servidor único se convierte en punto único de fallo. Intentas replicar a dos o tres servidores — esos paneles no tienen consenso distribuido, no tienen elección de líder. Son aplicaciones web sobre Docker. Elegantes para un servidor; frágiles para tres.

Cuando tu primer cliente serio pregunte "¿cuál es el SLA?", tendrás que responder "best-effort" o empezar a migrar — probablemente al coloso. Reempezar desde cero en el segundo año de la empresa.

El camino técnico que existía

Hay un orquestador que es técnicamente lo que quieres. Binario único, consenso distribuido de verdad, multi-tenant, escala a miles de nodos. El proveedor invirtió ocho años puliéndolo, y quien lo ha corrido en producción no tiene quejas del core.

Pero en agosto de 2023 el proveedor cambió la licencia de una OSS legítima a una licencia "source available" que restringe el uso comercial. En febrero de 2025, la empresa fue comprada por un conglomerado históricamente conocido por contratos de cinco años y amarre de plataforma. Hoy aquel orquestador forma parte de la cartera del conglomerado — y la licencia te impide ofrecer la tecnología como servicio o embeberla en producto sin licenciamiento comercial.

Para empresas que ya lo tenían en producción, es un problema gestionable. Para ti adoptándolo hoy en 2026, es un asterisco grande: la próxima feature crítica puede subir solo a la versión de pago, o la licencia puede cambiar de nuevo en una próxima reorganización.

La lección que sacamos de esto no es "open source o nada" — es "publica el contrato comercial desde el día uno, sin cambio retroactivo". Software comercial honesto es mejor que software abierto que se vuelve comercial a mitad de camino. El problema del orquestador técnico no fue volverse de pago; fue cambiar las reglas para quien ya había apostado.

La brecha

Ninguno de los tres caminos combina:

• Binario único (operacional simple)
• Alta disponibilidad real (consenso entre múltiples servidores, elección de líder, durabilidad)
• Experiencia tipo Heroku (cero archivo de orquestación extenso, panel web, certificados automáticos)
• Contrato comercial explícito desde el día uno (plan gratuito permanente, planes de pago publicados — sin cambio retroactivo de términos)
• Batería incluida (enrutamiento, malla entre servicios, métricas — sin montar cinco productos)

Los paneles modernos tienen la experiencia y el contrato gratuito, pero pierden en alta disponibilidad. El orquestador técnico tiene la HA pero cambió el contrato con quien ya lo había adoptado y nunca priorizó la experiencia. El coloso tiene todo eso solo si lo montas manualmente — y el "manualmente" cuesta un equipo.

Lado a lado, sin adornos

La tabla de abajo es la versión honesta de la decisión. No hay columna sin matiz — todo orquestador es un conjunto de tradeoffs, y el nuestro también.

La columna que importa es la penúltima: equipo mínimo para operar. Ahí vive el coste verdadero. Los otros criterios son la explicación del porqué.

Lo que estamos construyendo

HeroCtl es un único archivo ejecutable que instalas en N servidores Linux con Docker. Los primeros tres forman el quórum del plano de control replicado. Tú envías jobs vía CLI, API o panel web embebido — el cluster decide dónde correr, hace health check, gestiona rolling updates, emite certificados Let's Encrypt automáticamente vía router integrado.

Sin CRDs, sin operadores especializados, sin charts. El job spec es un archivo de configuración simple (50 líneas para app+ingress+secretos, no 300). Cifrado entre servicios y PKI automática vienen embebidos. Métricas persistentes corren como job del propio sistema. Logs con arquitectura de escritor único (sin montar Fluentd, sin montar Loki).

Hoy el stack público corre en producción: cuatro nodos en proveedor cloud, cinco sitios con TLS automático, dieciséis contenedores, downtime cero en rolling updates. El cluster sobrevivió a una batería completa de caos: kill -9 del servidor que coordina (elección en siete segundos), partición de red de 30 segundos, pérdida de quórum, wipe de disco, drain forzado. Cada uno de esos escenarios da para un post propio.

El resultado práctico es un modelo operacional radicalmente más corto. Subir una aplicación nueva son tres pasos: describes el servicio en un archivo de configuración de cincuenta líneas, lo envías vía CLI, y el cluster decide dónde correr, abre puerto, registra en el router, emite certificado Let's Encrypt y empieza a servir tráfico. Actualizar es un cuarto paso: cambias la versión de la imagen en el archivo, lo envías de nuevo, y el cluster orquesta la sustitución en rolling — sin ventana de mantenimiento, sin feature flag, sin migración manual de tráfico.

Depurar es la prueba real de cualquier orquestador. Cuando algo falla a las tres de la mañana, necesitas un camino corto entre "el sitio cayó" y "sé exactamente qué pasó". En HeroCtl, ese camino es único: el panel muestra qué contenedor falló, en qué servidor estaba corriendo, último log antes de morir, métricas de los últimos minutos, historial de versiones. Sin grep en tres productos diferentes, sin reconstituir contexto a partir de cinco dashboards, sin alternar entre herramientas de proveedores distintos solo para entender un fallo.

Cuándo HeroCtl no es para ti

La honestidad es el mecanismo de defensa de una herramienta nueva: contar dónde no encaja es lo que mantiene el producto enfocado. Cuatro perfiles en los que recomendamos otro camino.

Operas a nivel de cientos de miles de máquinas. Empresas que corren diez mil nodos o más eligieron el coloso por una razón real: fue diseñado para ese tamaño. HeroCtl es honesto sobre el techo: probamos hasta cientos de nodos en laboratorio, validamos algunas decenas en producción de clientes, y el roadmap apunta al rango "1 a 500 servidores". Por encima, el ecosistema del coloso te da herramientas que aún no tenemos — y construirlas solo para atender al 0,1% de los casos no es prioridad.

Tienes requisitos de compliance que listan herramientas nominalmente. Algunos frameworks de auditoría (FedRAMP, ITAR, ciertos contratos de gobierno) exigen que el stack corra sobre componentes específicos preaprobados. HeroCtl es demasiado joven para estar en esas listas. Si tu compliance officer necesita apuntar a un certificado existente, hoy la respuesta correcta es el coloso o el orquestador ex-OSS. Pero si necesitas el nombre de una herramienta en la lista de auditoría, no es HeroCtl todavía.

Necesitas una biblioteca profunda de operadores especializados. El ecosistema del coloso tiene cientos de operadores listos — Postgres con replicación automática, Kafka con balanceo, Cassandra con bootstrap. Si tu arquitectura depende de cuatro de esos operadores corriendo en producción desde el día uno, HeroCtl no sustituye. Nuestra propuesta es distinta: corres tu Postgres como un job común, cuidando del backup y la replicación como un humano cuida — sin delegar en un operador que tardó tres años en estabilizarse.

Quieres multi-cloud con workloads moviéndose entre proveedores en tiempo real. HeroCtl corre en cualquier servidor Linux con Docker, así que técnicamente puedes mezclar proveedores. Pero las primitivas para mover storage cifrado entre regiones, replicar bases a otro proveedor con failover automático, u orquestar redes virtuales entre nubes — eso el ecosistema del coloso lo resuelve mejor hoy. Está en nuestro roadmap, no en la versión actual.

Preguntas que recibimos

¿HeroCtl es otro wrapper de Docker más? No. Los wrappers de Docker no hacen consenso entre servidores, no eligen coordinador, no sobreviven a la pérdida de un nodo con redistribución automática de trabajo. HeroCtl es un plano de control replicado que coordina agentes en cada servidor. Docker queda como runtime de contenedor — una decisión de implementación, no la sustancia del producto.

¿Y si la empresa detrás de HeroCtl quiebra? Tres protecciones contractuales. Primero, el binario no tiene phone-home obligatorio — una vez instalado, tu cluster sigue funcionando sin hablar nunca con servidor nuestro. No hay kill-switch remoto, no hay activación periódica que expira. Segundo, los contratos Enterprise incluyen escrow de código fuente: si la empresa cierra operaciones, el código se entrega a los clientes pagantes vía tercera parte custodia, con licencia para continuidad interna. Tercero, el contrato de precio actual está congelado para quien firma hoy — no hay cláusula que permita cambio retroactivo de términos. Lo que pasó con el orquestador técnico en 2023 y en 2025 está estructuralmente impedido aquí.

¿Cuánto consume de RAM y CPU en cluster pequeño? El cluster público de demostración corre en cuatro servidores totalizando cinco vCPUs y diez gigabytes de RAM, con dieciséis contenedores activos sirviendo cinco sitios. El plano de control ocupa entre 200 y 400 MB por servidor — sobra para workload real. Comparativamente, el plano de control de una versión gestionada del coloso empieza en cerca de 700 MB por nodo-maestro antes de que suba ninguna aplicación.

¿Puedo migrar del orquestador ex-OSS a HeroCtl? Sí. Las primitivas son similares (job, group, task; cluster con plano de control replicado; agentes en cada servidor). La diferencia grande está en el archivo de configuración — el nuestro es más corto y tiene menos abstracciones. Para equipos con pocas decenas de jobs, la migración es manual y lleva una tarde. Por encima tenemos un convertidor experimental que cubre los casos comunes. Escríbenos si es tu caso.

¿Cómo funciona el pago? Tres planes con línea clara entre ellos. Community es gratuito para siempre, sin límite de servidores, sin límite de jobs, sin feature gates artificiales — corre todo el stack descrito arriba, incluyendo HA, router, certificados automáticos, métricas y logs. Individuos y equipos pequeños nunca necesitan salir de aquí. Business añade SSO/SAML, RBAC granular, auditoría detallada, backup gestionado y soporte con SLA — para equipos con requisitos formales de plataforma. Enterprise añade escrow de código fuente, contrato de continuidad, soporte 24×7 y desarrollo dedicado.

Los precios de Business y Enterprise están publicados en la página de planes — sin "habla con ventas" obligatorio. La línea de corte está diseñada para que solo pagues cuando la empresa sea lo bastante grande para que SSO y auditoría sean exigencias reales, no preferencia.

¿Está listo para producción? Está corriendo el stack público desde hace seis meses, sobrevivió a una batería documentada de escenarios de caos, y soporta el blog que estás leyendo ahora. "Listo" depende de tu apetito al riesgo y del tamaño de tu equipo. Para un indie hacker, tres servidores y un SaaS de US$10k MRR, está más que listo. Para un banco regulado por tres organismos, espera unos trimestres más y conversa con nosotros sobre Business Edition primero.

¿Dónde corren los datos sensibles (secretos, certificados, configuraciones)? En el propio cluster, cifrados en reposo. El cluster es la caja fuerte — no hay servicio externo de bóveda obligatorio. Si quieres integrar con una bóveda externa de tu nube (KMS de proveedor cloud), hay punto de extensión; pero la configuración por defecto es autosuficiente.

Lo que viene en los próximos posts

La intención del blog es técnica y directa: sin fluff de marketing.

• Ingeniería: cómo se configura el consenso, cómo funciona la defensa contra contenedores-zombi reteniendo puertos, por qué elegimos snapshot en memoria en lugar de bitmap persistido para asignación de puertos
• Comparativos: HeroCtl vs Coolify, HeroCtl vs Nomad, HeroCtl vs Kamal, HeroCtl vs Dokploy — números reales, no opinión
• Casos de uso: setup con 1 servidor (sustituir panel simple), 3 servidores (HA real), 10+ servidores (escala)
• Releases: changelog narrativo de las features que se entregan

Si eres desarrollador sintiendo que el coloso es demasiado y el panel auto-hospedado es poco, quédate por aquí. Si operas el orquestador técnico y estás incierto sobre el futuro post-adquisición, escríbenos — hay camino de migración.

La intención es simple: orquestación de contenedores, sin ceremonia.