HeroCtl vs Dokploy: comparativo honesto

Em sub-Reddits de DevOps em 2026, entre os auto-hospedados que apareceram depois da onda do Coolify, o nome mais comentado é o Dokploy. Painel limpo. Instalação rápida. Comunidade que cresceu numa velocidade que a maioria dos projetos de orquestração da última década não viu.

E uma decisão técnica que define todo o resto: o Dokploy roda Docker Swarm como engine de cluster. Não é detalhe — é a fundação. Tudo que ele entrega de bom vem dessa escolha, e tudo que ele tem de limitação também.

Esse texto é a leitura honesta dessa escolha, e a comparação ponto a ponto com o caminho que o HeroCtl seguiu. Sem ataque ao Dokploy, sem pintura cor-de-rosa do HeroCtl. Os dois produtos resolvem problemas parecidos com filosofias diferentes, e a decisão entre eles é mais do que preferência de painel.

Onde o Dokploy acertou

Antes do contraste, o crédito. Equipes que avaliam o Dokploy hoje encontram um produto que faz cinco coisas certas e faz bem.

A UX é coesa. O painel tem identidade visual própria, fluxos lineares, e os botões fazem o que prometem. Pra quem vem do Heroku ou do antigo painel comercial que ficou caro nos últimos anos, o Dokploy passa a sensação familiar de "abre, clica, deploya". É o tipo de polimento que só aparece depois de muitas iterações em cima de feedback de usuário real.

A instalação é rápida. Um comando, cinco minutos, painel no ar. Pra projetos individuais e times pequenos, esse atrito mínimo é o que separa "vou tentar" de "vou desistir e continuar com a nuvem cara".

O multi-server vem de fábrica. Você adiciona um segundo e um terceiro servidor pelo painel e o Swarm por baixo cuida de distribuir contêineres. Pra quem nunca tinha pensado em alta disponibilidade, virar HA por configuração é um avanço grande sobre painéis que rodam só num servidor.

O roteador integrado funciona. Há um roteador embutido que termina TLS, emite certificados Let's Encrypt automaticamente e encaminha tráfego pros contêineres. Você não precisa montar e manter um proxy reverso separado, não escreve configuração de virtual host à mão, não decora flags de renovação de certificado.

Bom suporte a stacks comuns. Apps Node, Django, Rails, projetos com Dockerfile direto, projetos via docker compose — tudo gira sem ajustes. A comunidade publica plugins one-click pros bancos de dados mais comuns, pra ferramentas de filas, pra observabilidade básica.

Essa lista é honesta. Quem disser que o Dokploy é "só mais um wrapper" não está olhando direito. É um produto sério, com tração, e foi feito por gente que escutou usuário.

A escolha técnica fundamental — Docker Swarm

O ponto que muda a conversa é a engine. O Dokploy não inventou seu próprio plano de controle de cluster — ele consome o Swarm que já vem dentro do Docker. O painel fala com a API do Swarm, que coordena os agentes em cada servidor. Quando você adiciona um servidor pelo painel, é um swarm join por baixo.

Essa decisão tem virtudes reais. O Swarm é estável há quase uma década. A API é consistente com o docker compose que a maioria dos times já conhece — declarar serviços tem a mesma cara em ambos. A eleição de coordenador é embutida, vem de graça com o swarm init. E porque é parte do Docker, qualquer servidor que já tem Docker instalado pode entrar no cluster com um comando.

O problema é o que aconteceu com o Swarm desde 2019. A Docker Inc decidiu naquele ano focar quase toda a engenharia de orquestração em outros produtos da empresa, e o Swarm entrou no que comunicados internos da época descreviam como "modo manutenção". Tradução prática: correções de segurança continuam, releases de bug fix continuam, mas features novas pararam. Não há roadmap público de evolução. Ninguém da equipe Docker apresentou em conferência, nos últimos cinco anos, melhorias de scheduling, de rede, de criptografia entre serviços, de integração com novos runtimes.

O Swarm não está abandonado — está em estase. E estase tem um custo composto.

Quando uma rede sobreposta entre nós tem um caso de borda em provedores cloud específicos, esse caso fica esperando alguém de fora propor patch. Quando um padrão novo de runtime de contêiner aparece — runtimes leves, contêineres confidenciais, melhorias de isolamento — o Swarm não absorve. Quando você quer criptografia entre serviços que vai além da overlay encrypted opcional do Swarm, a resposta é "monta um produto separado por cima".

O Dokploy herda esse perfil. Cada limitação do Swarm vira uma limitação do Dokploy sem caminho próprio de evolução. Não é culpa do Dokploy — é a consequência matemática de construir em cima de uma engine que parou de evoluir.

A escolha técnica do HeroCtl

O HeroCtl tomou a decisão oposta: construir o plano de controle do zero, sem depender do Swarm nem do colosso de orquestração popular. Não é purismo de "não inventado aqui". É a constatação de que orquestração na faixa "1 a 500 servidores" é um problema diferente do que tanto o Swarm quanto o colosso resolvem, e nenhum dos dois vai voltar a focar nesse nicho.

A consequência prática é liberdade de roadmap. Quando o time decide que criptografia entre serviços precisa ser nativa — não plugin, não overlay opcional, não operador externo — basta implementar. Quando decidimos que métricas persistentes deveriam rodar como job interno do próprio cluster, sem montar três produtos externos, foi uma decisão de arquitetura sem condicionante. Quando precisamos otimizar o caminho de deploy pra que mil contêineres entrem em rotação em poucos minutos, não há fila atrás da Docker Inc nem da fundação que mantém o colosso.

A contrapartida é honesta: o HeroCtl é mais novo. Tem menos quilometragem que o Swarm. Tem comunidade menor. A pilha de plugins one-click é mais curta. Esse é o trade-off de construir o plano de controle inteiro em vez de consumir um pronto. Os primeiros seis meses de produção fechada — quatro servidores, cinco vCPUs totais, dez gigabytes de RAM, dezesseis contêineres ativos, cinco sites com TLS automático — mostraram que o núcleo aguenta. O painel ainda está em catch-up visual.

Comparação operacional

Lado a lado, em quesitos que importam pra quem vai operar.

Instalação. Dokploy: cinco minutos pra painel no ar — instala Docker se não tem, faz swarm init, sobe o painel. HeroCtl: cinco minutos também — baixa um arquivo executável, registra o serviço, sobe o agente. Empate operacional.

Multi-server real. Dokploy depende do plano de controle do Swarm — três servidores coordenadores ou mais pra que a perda de um não derrube o cluster. HeroCtl tem plano de controle replicado próprio, também em três servidores ou mais. Os dois entregam HA real. A diferença é de quem você está dependendo: do estado atual do Swarm ou do estado atual do HeroCtl.

Painel. Os dois têm. Em 2026, o do Dokploy está mais polido visualmente — anos a mais de iteração e uma comunidade maior dando feedback. O do HeroCtl cobre os mesmos casos de uso (deploy, métricas, logs, cluster topology, certificados, secrets, audit) mas em catch-up estético. Honestidade de produto: se a estética do painel é determinante na decisão e tem peso maior do que arquitetura, o Dokploy ganha hoje.

Plugins e marketplace. O Dokploy tem mais plugins one-click hoje — Postgres, Redis, MinIO, observabilidade. O HeroCtl roda qualquer contêiner como job, com a mesma interface uniforme; o que falta é a vitrine de "clica e tem". Pra quem prefere descrever um job em arquivo de configuração e versionar no repositório, o HeroCtl chega no mesmo lugar. Pra quem prefere clicar e ter, o Dokploy chega mais rápido.

Métricas e logs. Dokploy: stack via plugins externos — Prometheus, Grafana, Loki ou similares montados separadamente. HeroCtl: métricas e logs como jobs internos do próprio cluster, com escritor único embutido. A diferença é menos sobre quem entrega melhor dado, mais sobre quantos produtos você está mantendo. Time pequeno costuma valorizar a pilha mais curta; time com SRE costuma preferir a flexibilidade de plugar a stack que já conhece.

Criptografia entre serviços. Dokploy não traz por padrão. O Swarm tem rede overlay com criptografia opcional, mas o Dokploy não promove esse caminho como primeira classe. Pra criptografia mútua de verdade entre todos os serviços, é mais um produto em cima. HeroCtl traz embutido — toda comunicação entre contêineres do cluster é cifrada por padrão, com PKI automática, sem operador externo. É a diferença entre "tem opção" e "vem ligado".

Observabilidade do plano de controle. Dokploy: você inspeciona o estado do Swarm via comandos docker no servidor mais painel pra app. HeroCtl: API uniforme do plano de controle expõe estado de jobs, agentes, eleição, certificados, em endpoints próprios — auditados.

Tabela comparativa

A versão honesta da decisão. Como sempre, todo orquestrador é um conjunto de tradeoffs.

A coluna que mais provoca a decisão é a primeira. Tudo o resto deriva dela.

Quando o Dokploy é a escolha certa

A honestidade exige a seção. Há cenários em que recomendar o Dokploy é a resposta correta.

Você gosta de Docker Swarm e ele atende ao que você precisa hoje. Apps web típicas, banco de dados gerenciado fora do cluster, baixa exigência de criptografia interna, time pequeno que prefere previsibilidade a evolução de plataforma. O Swarm vai aguentar isso por anos. Construir em cima dele significa construir em cima de algo testado e estável, mesmo que parado.

O painel mais polido do segmento self-hosted importa muito pro seu time. Se a interface visual é parte da venda interna pro resto da empresa, se o seu CTO vai mostrar pro CEO e a impressão importa, o Dokploy chega na frente em 2026. O HeroCtl está fechando essa distância, mas ainda não fechou.

Você já tem deploys via docker compose e quer caminho de migração mínimo. O Dokploy aceita compose com pouca fricção. Subir um time inteiro acostumado com compose pra um modelo novo de job spec é um custo organizacional que nem todo projeto justifica.

Você quer comunidade ativa de plugins one-click. Se o seu fluxo é "preciso de Postgres com replicação, clica, pronto", o Dokploy entrega isso hoje. O HeroCtl entrega o mesmo Postgres, mas você descreve o job e versiona em repositório.

Você não tem requisitos formais de criptografia entre serviços nativa nem auditoria detalhada. Pra time de cinco pessoas com SaaS que ainda não vendeu pro primeiro cliente Enterprise, o Dokploy é resposta suficiente. Sair dele depois é trabalho — mas é trabalho que talvez você nunca precise fazer.

Quando o HeroCtl é a escolha certa

Os perfis simétricos.

Você quer um plano de controle que evolui com decisões próprias. Pra projetos onde a plataforma de execução é parte do produto — não só infra acessória — depender de uma engine em manutenção é um risco estratégico. Construir em cima de algo que evolui é diferente de construir em cima de algo que mantém.

Criptografia entre serviços precisa ser nativa. Se a sua arquitetura tem dezenas de serviços conversando, dados sensíveis trafegando entre eles, e você não quer montar uma malha de serviço separada nem confiar em "rede privada do provedor cloud" como única camada, faz diferença ter cifragem por padrão.

Você precisa de auditoria detalhada. Quem assinou Business sabe quem fez o quê e quando — quem promoveu versão de qual job, quem rodou qual comando administrativo, quem rotacionou qual segredo. Pra times com requisitos de compliance crescentes, isso não é opcional.

Você quer escrow de código-fonte como seguro de continuidade. Enterprise inclui contrato com terceira parte custodiante: se a empresa por trás do HeroCtl encerrar operações, o código é entregue aos clientes pagantes com licença de continuidade interna. Pra organizações que não podem se dar ao luxo de "e se a empresa quebrar", essa estrutura é o que destrava a aprovação de procurement.

Faixa de aplicação 3 a 500 servidores com requisitos formais. É a faixa onde nem o Swarm em manutenção nem o colosso desenhado pra dezenas de milhares de máquinas servem bem. É exatamente onde o HeroCtl mira.

A questão do Swarm em produção

Convém ser justo aqui — e ser específico.

O Swarm continua estável. Pra a maioria absoluta dos casos de uso, ele vai entregar o que promete por mais alguns anos. Apps web típicas, microsserviços de complexidade média, deploys rolling, healthchecks, descoberta de serviço básica — tudo isso roda. Histórias de cluster Swarm em produção há cinco ou seis anos sem incidente grave existem em volume.

O ponto não é "Swarm vai quebrar". É "Swarm não vai melhorar". Construir em cima dele em 2026 é assinar tacitamente que o conjunto de capacidades que ele tem hoje é o conjunto que você vai ter pra sempre. Pra projetos onde isso é um trade-off aceitável, sem problema. Pra projetos onde criptografia entre serviços, observabilidade nativa, integração com runtimes novos, ou extensibilidade do scheduler vão importar nos próximos três anos, vale considerar uma stack que continua evoluindo.

Tem outro ângulo. Quando o Swarm tem um caso de borda — rede sobreposta com perda intermitente em provedores cloud específicos, scheduling estranho quando um nó volta depois de partição longa, comportamento inesperado de health check em contêineres com inicialização lenta — esses casos hoje são debugados pela comunidade de fora. A Docker Inc não está de plantão. Resolver vira projeto da sua equipe. No HeroCtl, esses casos são tratados pelo time que escreveu o código — você abre relato, a gente sobe correção. É um modelo de suporte diferente porque o investimento de engenharia continua acontecendo.

Não é argumento ideológico de "código novo é melhor". O Swarm é estável precisamente porque é antigo. O argumento é prático: a evolução do produto que você vai usar nos próximos cinco anos depende de quem está investindo. No Dokploy, parte da evolução depende de gente que parou de mexer no Swarm em 2019. No HeroCtl, depende de gente que está mexendo no plano de controle hoje.

Migração entre eles

Caminho conceitual, não receita. Cada projeto tem detalhes próprios — escreva pra gente se quiser ajuda específica.

Imagens Docker servem nos dois. Dockerfile que você usa no Dokploy é o mesmo que você usa no HeroCtl. Não há build especial, não há runtime customizado.

Variáveis de ambiente migram com mesmas chaves. Onde você tem um bloco de env vars no Dokploy, você tem um bloco equivalente no job spec do HeroCtl. Os nomes não mudam.

Volumes nomeados se mantêm. Volume montado em /var/lib/postgresql/data continua montado lá. O conceito de volume persistente entre reinícios é o mesmo.

O compose que o Dokploy aceita não converte 1:1 pro job spec do HeroCtl, mas o mapeamento é direto. Serviço vira task. Network vira política de rede. Deploy strategy vira estratégia de rolling update. A primeira migração leva uma tarde por aplicação; depois disso, copiar e colar com substituições.

Ingress: o roteador do Dokploy e o roteador integrado do HeroCtl ambos terminam em configuração-como-código. Você descreve host, redirect, certificado em pouquíssimas linhas em qualquer dos dois. A tradução é mecânica.

Pra times com até dez aplicações, migração manual numa tarde. Acima disso, conversor experimental cobre os casos comuns — escreve pra gente.

Perguntas que a gente recebe

O HeroCtl é mais maduro que o Dokploy? Não em todas as dimensões. O Dokploy tem mais tempo de comunidade, mais plugins, painel mais polido visualmente. O HeroCtl tem plano de controle próprio com evolução ativa, alta disponibilidade real testada em bateria de caos documentada, e roadmap independente de qualquer outro projeto. "Maduro" depende do eixo. Em estética de painel e marketplace, o Dokploy. Em arquitetura de plataforma e contrato comercial explícito, o HeroCtl.

E o painel, o do Dokploy é melhor? Em 2026, sim — mais polido visualmente, mais anos de iteração, mais feedback de comunidade incorporado. O do HeroCtl cobre os mesmos casos de uso e está em catch-up estético. A pergunta importante é se a diferença visual é o critério decisivo pra você. Pra alguns times é. Pra outros, arquitetura pesa mais.

Qual consome menos recurso? Dokploy adiciona o overhead do painel mais o overhead do Swarm dentro do Docker — o Swarm em si é leve, mas o painel é uma aplicação web razoavelmente completa. HeroCtl tem plano de controle entre 200 e 400 MB por servidor, incluindo painel web embutido. Em cluster pequeno os dois cabem confortavelmente em servidores modestos. A diferença não é determinante na decisão.

E o backup de banco? Nos dois, banco de dados é uma responsabilidade explícita de quem opera. O Dokploy tem plugins one-click pra Postgres e similares, mas backup automático é configuração adicional — geralmente você monta cron job ou plugin de backup separado. HeroCtl trata banco como qualquer outro job, com volume persistente; backup é um job paralelo que você define. Business inclui backup gerenciado com janelas e retenção. Em nenhum dos dois "ligar e esquecer" é resposta honesta — banco merece atenção em ambos.

O Dokploy é open source, HeroCtl não é, isso me preocupa? Pergunta justa. O HeroCtl tem Community Edition gratuita pra sempre, sem limite de servidores, sem limite de jobs, sem feature gates artificiais. O binário não tem phone-home obrigatório nem kill-switch remoto — uma vez instalado, o cluster funciona offline indefinidamente. Enterprise inclui escrow de código-fonte com terceira parte custodiante, então se a empresa por trás do produto encerrar operações, o código é entregue aos clientes pagantes com licença de continuidade interna. Não é o mesmo que open source, mas resolve o que open source resolve nesse contexto: garantia contra desaparecimento do fornecedor. O contrato comercial está publicado desde o dia um e congelado pra quem assina hoje — não há cláusula de mudança retroativa.

Posso usar os dois, um pra dev e outro pra prod? Tecnicamente sim, mas raramente faz sentido. Imagens Docker são portáteis entre os dois, então o caminho funciona. Na prática, dois orquestradores diferentes em ambientes adjacentes dobra o conhecimento operacional do time. Recomendamos escolher um e ficar nele. Se a dúvida é a fundo qual escolher, escreva pra gente — discutir caso a caso é mais útil do que conselho genérico.

Qual escala mais alto? Pra cima de mil servidores, nenhum dos dois é a escolha óbvia — essa faixa é território do colosso desenhado pra dezenas de milhares de máquinas. Na faixa de 1 a 500 servidores, o HeroCtl foi desenhado especificamente. O Dokploy escala bem dentro do que o Swarm escala — tipicamente até algumas dezenas de nós em produção sem ginástica. Acima disso, o Swarm passa a exigir cuidados que não estavam na proposta original do produto.

Fechamento

A escolha entre Dokploy e HeroCtl não é entre produto bom e produto ruim. Os dois são sérios. A escolha é entre filosofias diferentes de plataforma.

O Dokploy escolheu construir uma camada de UX e produto em cima de uma engine madura mas estática. O HeroCtl escolheu construir o plano de controle inteiro pra controlar a evolução. Trade-offs reais nas duas direções.

Se você está em Dokploy hoje e não está sentindo as limitações, fica. É um produto bom. Se você está avaliando os dois em greenfield, leia o post sobre por que criamos o HeroCtl pra entender a motivação por trás da decisão de construir o plano de controle do zero. Se você está vindo do Heroku ou de painéis comerciais que ficaram caros, vale também o post Heroku auto-hospedado em 2026 — o contexto de mercado ajuda.

Pra experimentar o HeroCtl em três minutos:

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

Um arquivo executável, um servidor pra começar, dois mais quando você quiser HA real. Painel embutido, certificados automáticos, criptografia entre serviços por padrão. Sem phone-home, sem kill-switch, contrato comercial congelado.

A intenção é simples: orquestração de contêineres, sem cerimônia.