HeroCtl vs Dokploy: comparativo honesto

En sub-Reddits de DevOps en 2026, entre los auto-hospedados que aparecieron tras la ola de Coolify, el nombre más comentado es Dokploy. Panel limpio. Instalación rápida. Comunidad que creció a una velocidad que la mayoría de los proyectos de orquestación de la última década no vio.

Y una decisión técnica que define todo el resto: Dokploy ejecuta Docker Swarm como engine de cluster. No es detalle — es la fundación. Todo lo que entrega de bueno viene de esa elección, y todo lo que tiene de limitación también.

Este texto es la lectura honesta de esa elección, y la comparación punto a punto con el camino que HeroCtl siguió. Sin ataque a Dokploy, sin pintura color de rosa de HeroCtl. Los dos productos resuelven problemas parecidos con filosofías diferentes, y la decisión entre ellos es más que preferencia de panel.

Donde Dokploy acertó

Antes del contraste, el crédito. Equipos que evalúan Dokploy hoy encuentran un producto que hace cinco cosas correctas y las hace bien.

La UX es coherente. El panel tiene identidad visual propia, flujos lineales, y los botones hacen lo que prometen. Para quien viene de Heroku o del antiguo panel comercial que se volvió caro en los últimos años, Dokploy pasa la sensación familiar de "abre, clica, deploya". Es el tipo de pulido que solo aparece tras muchas iteraciones encima de feedback de usuario real.

La instalación es rápida. Un comando, cinco minutos, panel al aire. Para proyectos individuales y equipos pequeños, esa fricción mínima es lo que separa "voy a probar" de "voy a desistir y continuar con la nube cara".

El multi-server viene de fábrica. Añades un segundo y un tercer servidor por el panel y el Swarm por debajo cuida de distribuir contenedores. Para quien nunca había pensado en alta disponibilidad, volverse HA por configuración es un avance grande sobre paneles que corren solo en un servidor.

El router integrado funciona. Hay un router embebido que termina TLS, emite certificados Let's Encrypt automáticamente y enruta tráfico a los contenedores. No necesitas montar y mantener un proxy reverso separado, no escribes configuración de virtual host a mano, no decoras flags de renovación de certificado.

Buen soporte a stacks comunes. Apps Node, Django, Rails, proyectos con Dockerfile directo, proyectos vía docker compose — todo gira sin ajustes. La comunidad publica plugins one-click para los bancos de datos más comunes, para herramientas de colas, para observabilidad básica.

Esa lista es honesta. Quien diga que Dokploy es "solo otro wrapper" no está mirando bien. Es un producto serio, con tracción, y fue hecho por gente que escuchó al usuario.

La elección técnica fundamental — Docker Swarm

El punto que cambia la conversación es la engine. Dokploy no inventó su propio plano de control de cluster — consume el Swarm que ya viene dentro de Docker. El panel habla con la API de Swarm, que coordina los agentes en cada servidor. Cuando añades un servidor por el panel, es un swarm join por debajo.

Esa decisión tiene virtudes reales. Swarm es estable hace casi una década. La API es consistente con docker compose que la mayoría de los equipos ya conoce — declarar servicios tiene la misma cara en ambos. La elección de coordinador es embebida, viene gratis con swarm init. Y porque es parte de Docker, cualquier servidor que ya tiene Docker instalado puede entrar en el cluster con un comando.

El problema es lo que sucedió con Swarm desde 2019. Docker Inc decidió aquel año enfocar casi toda la ingeniería de orquestación en otros productos de la empresa, y Swarm entró en lo que comunicados internos de la época describían como "modo mantenimiento". Traducción práctica: correcciones de seguridad continúan, releases de bug fix continúan, pero features nuevas pararon. No hay roadmap público de evolución. Nadie del equipo Docker presentó en conferencia, en los últimos cinco años, mejoras de scheduling, de red, de criptografía entre servicios, de integración con nuevos runtimes.

Swarm no está abandonado — está en estasis. Y estasis tiene un coste compuesto.

Cuando una red sobrepuesta entre nodos tiene un caso de borde en proveedores cloud específicos, ese caso queda esperando que alguien de fuera proponga patch. Cuando un patrón nuevo de runtime de contenedor aparece — runtimes ligeros, contenedores confidenciales, mejoras de aislamiento — Swarm no absorbe. Cuando quieres criptografía entre servicios que va más allá del overlay encrypted opcional del Swarm, la respuesta es "monta un producto separado por encima".

Dokploy hereda ese perfil. Cada limitación de Swarm se vuelve una limitación de Dokploy sin camino propio de evolución. No es culpa de Dokploy — es la consecuencia matemática de construir encima de una engine que paró de evolucionar.

La elección técnica de HeroCtl

HeroCtl tomó la decisión opuesta: construir el plano de control desde cero, sin depender de Swarm ni del coloso de orquestación popular. No es purismo de "no inventado aquí". Es la constatación de que orquestación en la franja "1 a 500 servidores" es un problema diferente del que tanto Swarm como el coloso resuelven, y ninguno de los dos va a volver a enfocarse en ese nicho.

La consecuencia práctica es libertad de roadmap. Cuando el equipo decide que criptografía entre servicios necesita ser nativa — no plugin, no overlay opcional, no operador externo — basta implementar. Cuando decidimos que métricas persistentes deberían correr como job interno del propio cluster, sin montar tres productos externos, fue una decisión de arquitectura sin condicionante. Cuando necesitamos optimizar el camino de deploy para que mil contenedores entren en rotación en pocos minutos, no hay cola detrás de Docker Inc ni de la fundación que mantiene el coloso.

La contrapartida es honesta: HeroCtl es más nuevo. Tiene menos kilometraje que Swarm. Tiene comunidad menor. La pila de plugins one-click es más corta. Ese es el trade-off de construir el plano de control entero en lugar de consumir uno listo. Los primeros seis meses de producción cerrada — cuatro servidores, cinco vCPUs totales, diez gigabytes de RAM, dieciséis contenedores activos, cinco sitios con TLS automático — mostraron que el núcleo aguanta. El panel aún está en catch-up visual.

Comparación operacional

Lado a lado, en cuestiones que importan para quien va a operar.

Instalación. Dokploy: cinco minutos para panel al aire — instala Docker si no tiene, hace swarm init, sube el panel. HeroCtl: cinco minutos también — descarga un archivo ejecutable, registra el servicio, sube el agente. Empate operacional.

Multi-server real. Dokploy depende del plano de control de Swarm — tres servidores coordinadores o más para que la pérdida de uno no tire el cluster. HeroCtl tiene plano de control replicado propio, también en tres servidores o más. Los dos entregan HA real. La diferencia es de quién estás dependiendo: del estado actual de Swarm o del estado actual de HeroCtl.

Panel. Los dos tienen. En 2026, el de Dokploy está más pulido visualmente — años más de iteración y una comunidad mayor dando feedback. El de HeroCtl cubre los mismos casos de uso (deploy, métricas, logs, cluster topology, certificados, secretos, audit) pero en catch-up estético. Honestidad de producto: si la estética del panel es determinante en la decisión y tiene peso mayor que arquitectura, Dokploy gana hoy.

Plugins y marketplace. Dokploy tiene más plugins one-click hoy — Postgres, Redis, MinIO, observabilidad. HeroCtl ejecuta cualquier contenedor como job, con la misma interfaz uniforme; lo que falta es la vitrina de "clica y tienes". Para quien prefiere describir un job en archivo de configuración y versionar en el repositorio, HeroCtl llega al mismo lugar. Para quien prefiere clicar y tener, Dokploy llega más rápido.

Métricas y logs. Dokploy: stack vía plugins externos — Prometheus, Grafana, Loki o similares montados separadamente. HeroCtl: métricas y logs como jobs internos del propio cluster, con escritor único embebido. La diferencia es menos sobre quién entrega mejor dato, más sobre cuántos productos estás manteniendo. Equipo pequeño suele valorar la pila más corta; equipo con SRE suele preferir la flexibilidad de plugar la stack que ya conoce.

Criptografía entre servicios. Dokploy no trae por defecto. Swarm tiene red overlay con criptografía opcional, pero Dokploy no promueve ese camino como primera clase. Para criptografía mutua de verdad entre todos los servicios, es un producto más por encima. HeroCtl la trae embebida — toda comunicación entre contenedores del cluster es cifrada por defecto, con PKI automática, sin operador externo. Es la diferencia entre "tiene opción" y "viene encendido".

Observabilidad del plano de control. Dokploy: inspeccionas el estado de Swarm vía comandos docker en el servidor más panel para app. HeroCtl: API uniforme del plano de control expone estado de jobs, agentes, elección, certificados, en endpoints propios — auditados.

Tabla comparativa

La versión honesta de la decisión. Como siempre, todo orquestador es un conjunto de tradeoffs.

La columna que más provoca la decisión es la primera. Todo lo demás deriva de ella.

Cuándo Dokploy es la elección correcta

La honestidad exige la sección. Hay escenarios en los que recomendar Dokploy es la respuesta correcta.

Te gusta Docker Swarm y atiende lo que necesitas hoy. Apps web típicas, base de datos gestionada fuera del cluster, baja exigencia de criptografía interna, equipo pequeño que prefiere previsibilidad a evolución de plataforma. Swarm va a aguantar eso por años. Construir encima de él significa construir encima de algo testeado y estable, aunque parado.

El panel más pulido del segmento auto-hospedado importa mucho para tu equipo. Si la interfaz visual es parte de la venta interna para el resto de la empresa, si tu CTO va a mostrar al CEO y la impresión importa, Dokploy llega al frente en 2026. HeroCtl está cerrando esa distancia, pero aún no la cerró.

Ya tienes deploys vía docker compose y quieres camino de migración mínimo. Dokploy acepta compose con poca fricción. Subir un equipo entero acostumbrado con compose a un modelo nuevo de job spec es un coste organizacional que no todo proyecto justifica.

Quieres comunidad activa de plugins one-click. Si tu flujo es "necesito Postgres con replicación, clico, listo", Dokploy entrega eso hoy. HeroCtl entrega el mismo Postgres, pero describes el job y versionas en el repositorio.

No tienes requisitos formales de criptografía entre servicios nativa ni auditoría detallada. Para equipo de cinco personas con SaaS que aún no vendió al primer cliente Enterprise, Dokploy es respuesta suficiente. Salir de él después es trabajo — pero es trabajo que tal vez nunca necesites hacer.

Cuándo HeroCtl es la elección correcta

Los perfiles simétricos.

Quieres un plano de control que evoluciona con decisiones propias. Para proyectos donde la plataforma de ejecución es parte del producto — no solo infra accesoria — depender de una engine en mantenimiento es un riesgo estratégico. Construir encima de algo que evoluciona es diferente de construir encima de algo que mantiene.

Criptografía entre servicios necesita ser nativa. Si tu arquitectura tiene decenas de servicios conversando, datos sensibles transitando entre ellos, y no quieres montar una malla de servicio separada ni confiar en "red privada del proveedor cloud" como única capa, hace diferencia tener cifrado por defecto.

Necesitas auditoría detallada. Quien firmó Business sabe quién hizo qué y cuándo — quién promovió versión de qué job, quién corrió qué comando administrativo, quién rotó qué secreto. Para equipos con requisitos de compliance crecientes, eso no es opcional.

Quieres escrow de código fuente como seguro de continuidad. Enterprise incluye contrato con tercera parte custodiante: si la empresa detrás de HeroCtl encierra operaciones, el código es entregado a los clientes pagantes con licencia de continuidad interna. Para organizaciones que no pueden darse el lujo de "y si la empresa quiebra", esa estructura es lo que destranca la aprobación de procurement.

Franja de aplicación 3 a 500 servidores con requisitos formales. Es la franja donde ni Swarm en mantenimiento ni el coloso diseñado para decenas de miles de máquinas sirven bien. Es exactamente donde HeroCtl apunta.

La cuestión del Swarm en producción

Conviene ser justo aquí — y ser específico.

Swarm continúa estable. Para la mayoría absoluta de los casos de uso, va a entregar lo que promete por algunos años más. Apps web típicas, microservicios de complejidad media, deploys rolling, healthchecks, descubrimiento de servicio básico — todo eso corre. Historias de cluster Swarm en producción hace cinco o seis años sin incidente grave existen en volumen.

El punto no es "Swarm va a romper". Es "Swarm no va a mejorar". Construir encima de él en 2026 es firmar tácitamente que el conjunto de capacidades que tiene hoy es el conjunto que vas a tener para siempre. Para proyectos donde eso es un trade-off aceptable, sin problema. Para proyectos donde criptografía entre servicios, observabilidad nativa, integración con runtimes nuevos, o extensibilidad del scheduler van a importar en los próximos tres años, vale la pena considerar una stack que sigue evolucionando.

Hay otro ángulo. Cuando Swarm tiene un caso de borde — red sobrepuesta con pérdida intermitente en proveedores cloud específicos, scheduling extraño cuando un nodo vuelve después de partición larga, comportamiento inesperado de health check en contenedores con inicialización lenta — esos casos hoy son debugueados por la comunidad de fuera. Docker Inc no está de plantón. Resolver se vuelve proyecto de tu equipo. En HeroCtl, esos casos son tratados por el equipo que escribió el código — abres reporte, subimos corrección. Es un modelo de soporte diferente porque la inversión de ingeniería sigue sucediendo.

No es argumento ideológico de "código nuevo es mejor". Swarm es estable precisamente porque es antiguo. El argumento es práctico: la evolución del producto que vas a usar en los próximos cinco años depende de quién está invirtiendo. En Dokploy, parte de la evolución depende de gente que paró de tocar Swarm en 2019. En HeroCtl, depende de gente que está tocando el plano de control hoy.

Migración entre ellos

Camino conceptual, no receta. Cada proyecto tiene detalles propios — escríbenos si quieres ayuda específica.

Imágenes Docker sirven en los dos. Dockerfile que usas en Dokploy es el mismo que usas en HeroCtl. No hay build especial, no hay runtime customizado.

Variables de entorno migran con mismas claves. Donde tienes un bloque de env vars en Dokploy, tienes un bloque equivalente en el job spec de HeroCtl. Los nombres no cambian.

Volúmenes nombrados se mantienen. Volume montado en /var/lib/postgresql/data continúa montado allí. El concepto de volumen persistente entre reinicios es el mismo.

El compose que Dokploy acepta no convierte 1:1 al job spec de HeroCtl, pero el mapeo es directo. Servicio se vuelve task. Network se vuelve política de red. Deploy strategy se vuelve estrategia de rolling update. La primera migración lleva una tarde por aplicación; después de eso, copiar y pegar con sustituciones.

Ingress: el router de Dokploy y el router integrado de HeroCtl ambos terminan en configuración-como-código. Describes host, redirect, certificado en poquísimas líneas en cualquiera de los dos. La traducción es mecánica.

Para equipos con hasta diez aplicaciones, migración manual en una tarde. Por encima de eso, conversor experimental cubre los casos comunes — escríbenos.

Preguntas que recibimos

¿HeroCtl es más maduro que Dokploy? No en todas las dimensiones. Dokploy tiene más tiempo de comunidad, más plugins, panel más pulido visualmente. HeroCtl tiene plano de control propio con evolución activa, alta disponibilidad real testada en batería de caos documentada, y roadmap independiente de cualquier otro proyecto. "Maduro" depende del eje. En estética de panel y marketplace, Dokploy. En arquitectura de plataforma y contrato comercial explícito, HeroCtl.

¿Y el panel, el de Dokploy es mejor? En 2026, sí — más pulido visualmente, más años de iteración, más feedback de comunidad incorporado. El de HeroCtl cubre los mismos casos de uso y está en catch-up estético. La pregunta importante es si la diferencia visual es el criterio decisivo para ti. Para algunos equipos lo es. Para otros, arquitectura pesa más.

¿Cuál consume menos recurso? Dokploy añade el overhead del panel más el overhead de Swarm dentro de Docker — Swarm en sí es ligero, pero el panel es una aplicación web razonablemente completa. HeroCtl tiene plano de control entre 200 y 400 MB por servidor, incluyendo panel web embebido. En cluster pequeño los dos caben cómodamente en servidores modestos. La diferencia no es determinante en la decisión.

¿Y el backup de base? En los dos, base de datos es una responsabilidad explícita de quien opera. Dokploy tiene plugins one-click para Postgres y similares, pero backup automático es configuración adicional — generalmente montas cron job o plugin de backup separado. HeroCtl trata base como cualquier otro job, con volumen persistente; backup es un job paralelo que defines. Business incluye backup gestionado con ventanas y retención. En ninguno de los dos "encender y olvidar" es respuesta honesta — base merece atención en ambos.

Dokploy es open source, HeroCtl no, ¿eso me preocupa? Pregunta justa. HeroCtl tiene Community Edition gratuita para siempre, sin límite de servidores, sin límite de jobs, sin feature gates artificiales. El binario no tiene phone-home obligatorio ni kill-switch remoto — una vez instalado, el cluster funciona offline indefinidamente. Enterprise incluye escrow de código fuente con tercera parte custodiante, así que si la empresa detrás del producto encierra operaciones, el código es entregado a los clientes pagantes con licencia de continuidad interna. No es lo mismo que open source, pero resuelve lo que open source resuelve en ese contexto: garantía contra desaparición del proveedor. El contrato comercial está publicado desde el día uno y congelado para quien firma hoy — no hay cláusula de cambio retroactivo.

¿Puedo usar los dos, uno para dev y otro para prod? Técnicamente sí, pero raramente tiene sentido. Imágenes Docker son portables entre los dos, así que el camino funciona. En la práctica, dos orquestadores diferentes en entornos adyacentes duplica el conocimiento operacional del equipo. Recomendamos elegir uno y quedarse en él. Si la duda es a fondo cuál elegir, escríbenos — discutir caso por caso es más útil que consejo genérico.

¿Cuál escala más alto? Por encima de mil servidores, ninguno de los dos es la elección obvia — esa franja es territorio del coloso diseñado para decenas de miles de máquinas. En la franja de 1 a 500 servidores, HeroCtl fue diseñado específicamente. Dokploy escala bien dentro de lo que Swarm escala — típicamente hasta algunas decenas de nodos en producción sin gimnasia. Por encima de eso, Swarm pasa a exigir cuidados que no estaban en la propuesta original del producto.

Cierre

La elección entre Dokploy y HeroCtl no es entre producto bueno y producto malo. Los dos son serios. La elección es entre filosofías diferentes de plataforma.

Dokploy eligió construir una capa de UX y producto encima de una engine madura pero estática. HeroCtl eligió construir el plano de control entero para controlar la evolución. Trade-offs reales en las dos direcciones.

Si estás en Dokploy hoy y no estás sintiendo las limitaciones, quédate. Es un producto bueno. Si estás evaluando los dos en greenfield, lee el post sobre por qué creamos HeroCtl para entender la motivación detrás de la decisión de construir el plano de control desde cero. Si estás viniendo de Heroku o de paneles comerciales que se volvieron caros, vale también el post Heroku auto-hospedado en 2026 — el contexto de mercado ayuda.

Para experimentar HeroCtl en tres minutos:

curl -sSL get.heroctl.com/install.sh | sh

Un archivo ejecutable, un servidor para empezar, dos más cuando quieras HA real. Panel embebido, certificados automáticos, criptografía entre servicios por defecto. Sin phone-home, sin kill-switch, contrato comercial congelado.

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