Por que criamos o HeroCtl

Cada cluster que opera em produção hoje precisa decidir entre três caminhos, e nenhum deles é bom o suficiente para o time de cinco pessoas tentando shippar uma SaaS.

O caminho doloroso: Kubernetes

Você abre um manifesto de "hello world" e tem 300 linhas. Adiciona um templating manager pra organizar — agora são 300 linhas mais 200 linhas de templates. Decide usar uma versão gerenciada na nuvem pra evitar manter o plano de controle — paga US$73/mês por cluster, mais NAT, mais Application Load Balancer. Precisa de TLS automático? Instala um operador especializado. Métricas? Outro operador. Roteamento entre serviços com criptografia? Mais dois operadores e dois dias estudando malha de serviço. Logs centralizados? Mais um stack.

A complexidade não é acidental. O sistema é uma plataforma para construir plataformas — feita por um time que precisava orquestrar 100 mil máquinas. Quando uma startup com quatro servidores adota a mesma ferramenta, está usando uma escavadeira pra plantar uma muda. Tratamos a tese geral em Kubernetes é overkill: quando você não precisa.

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

O custo real não é a infra, é o time. Operadores sérios desse sistema cobram salários de seis dígitos. Você precisa de pelo menos um na equipe — preferencialmente dois pra plantão. É o seu primeiro engenheiro contratado depois do CTO. Antes do designer, antes do segundo dev de produto, antes de qualquer coisa que entregue valor pro usuário.

O caminho fácil: painéis self-hosted modernos

Um comando de instalação num único servidor, abre o painel, deploya em cinco minutos. Funciona. Os dois líderes desse segmento somam 80 mil estrelas em repositórios públicos. A comunidade explodiu nos últimos dois anos porque resolveu o problema certo: a maioria dos times não precisa do colosso, precisa de Heroku auto-hospedado.

O problema só aparece depois. Você cresce, cliente pede SLA, o servidor único vira ponto único de falha. Tenta replicar pra dois ou três servidores — esses painéis não têm consenso distribuído, não têm eleição de líder. São aplicações web em cima do Docker. Elegantes pra um servidor; frágeis pra três.

Quando o seu primeiro cliente sério perguntar "qual o SLA?", você terá que responder "best-effort" ou começar a migrar — provavelmente pro colosso. Recomeçar do zero no segundo ano da empresa.

O caminho técnico que existia

Há um orquestrador que é tecnicamente o que você quer. Binário único, consenso distribuído de verdade, multi-tenant, escala pra milhares de nós. O fornecedor gastou oito anos polindo isso, e quem rodou em produção não tem o que reclamar do core.

Mas em agosto de 2023 o fornecedor trocou a licença de uma OSS legítima para uma licença "source available" que restringe uso comercial. Em fevereiro de 2025, a empresa foi comprada por um conglomerado historicamente conhecido por contratos de cinco anos e amarração de plataforma. Hoje aquele orquestrador faz parte da carteira do conglomerado — e a licença te impede de oferecer a tecnologia como serviço ou embeddar em produto sem licenciamento comercial.

Pra empresas que já tinham aquilo em produção, é um problema gerenciável. Pra você adotando hoje em 2026, é um asterisco grande: a próxima feature crítica pode subir só pra versão paga, ou a licença pode mudar de novo numa próxima reorganização.

A lição que tiramos disso não é "open source ou nada" — é "publique o contrato comercial desde o dia um, sem mudança retroativa". Software comercial honesto é melhor do que software aberto que vira comercial no meio do caminho. O problema do orquestrador técnico não foi virar pago; foi mudar as regras pra quem já tinha apostado.

A lacuna

Nenhum dos três caminhos combina:

• Binário único (operacional simples)
• Alta disponibilidade real (consenso entre múltiplos servidores, eleição de líder, durabilidade)
• Experiência tipo Heroku (zero arquivo de orquestração extenso, painel web, certificados automáticos)
• Contrato comercial explícito desde o dia um (plano gratuito permanente, planos pagos publicados — sem mudança retroativa de termos)
• Bateria incluída (roteamento, malha entre serviços, métricas — sem montar cinco produtos)

Os painéis modernos têm a experiência e o contrato gratuito, mas perdem em alta disponibilidade. O orquestrador técnico tem a HA mas mudou o contrato com quem já tinha adotado e nunca priorizou experiência. O colosso tem tudo isso só se você montar manualmente — e o "manualmente" custa um time.

Lado a lado, sem floreio

A tabela abaixo é a versão honesta da decisão. Não tem coluna sem ressalva — todo orquestrador é um conjunto de tradeoffs, e o nosso também.

A coluna que importa é a penúltima: time mínimo pra operar. É ali que o custo verdadeiro mora. Os outros critérios são a explicação do porquê.

O que estamos construindo

HeroCtl é um único arquivo executável que você instala em N servidores Linux com Docker. Os primeiros três viram quórum pro plano de controle replicado. Você submete jobs via CLI, API ou painel web embutido — o cluster decide onde rodar, faz health check, gerencia rolling deploys, emite certificados Let's Encrypt automaticamente via roteador integrado.

Sem CRDs, sem operadores especializados, sem charts. O job spec é um arquivo de configuração simples (50 linhas pra app+ingress+secrets, não 300). Criptografia entre serviços e PKI automática vêm embutidas. Métricas persistentes rodam como job do próprio sistema. Logs com arquitetura de escritor único (sem montar Fluentd, sem montar Loki).

Hoje a stack pública roda em produção: quatro nós em provedor cloud, cinco sites com TLS automático, dezesseis contêineres, downtime zero em rolling deploys. O cluster sobreviveu a uma bateria completa de caos: kill -9 do servidor que coordena (eleição em sete segundos), partição de rede de 30 segundos, perda de quórum, wipe de disco, drain forçado. Cada um desses cenários vira um post próprio.

O resultado prático é um modelo operacional radicalmente mais curto. Subir uma aplicação nova é três passos: você descreve o serviço num arquivo de configuração de cinquenta linhas, submete via CLI, e o cluster decide onde rodar, abre porta, registra no roteador, emite certificado Let's Encrypt e começa a servir tráfego. Atualizar é um quarto passo: muda a versão da imagem no arquivo, submete de novo, e o cluster orquestra a substituição em rolling — sem janela de manutenção, sem flag de feature, sem migração manual de tráfego.

Depurar é o teste real de qualquer orquestrador. Quando algo dá errado às três da manhã, você precisa de um caminho curto entre "o site caiu" e "sei exatamente o que aconteceu". No HeroCtl, esse caminho é único: o painel mostra qual contêiner falhou, em qual servidor estava rodando, último log antes de morrer, métricas dos últimos minutos, histórico de versões. Sem grep em três produtos diferentes, sem reconstituir contexto a partir de cinco dashboards, sem alternar entre ferramentas de fornecedores diferentes só pra entender uma falha.

Quando o HeroCtl não é pra você

A honestidade é o mecanismo de defesa de uma ferramenta nova: contar onde ela não cabe é o que mantém o produto focado. Quatro perfis em que recomendamos outro caminho.

Você opera no nível de centenas de milhares de máquinas. Empresas que rodam dez mil nós ou mais escolheram o colosso por uma razão real: ele foi desenhado pra esse tamanho. HeroCtl é honesto sobre o teto: testamos até centenas de nós em laboratório, validamos algumas dezenas em produção de clientes, e o roadmap mira a faixa "1 a 500 servidores". Acima disso, o ecossistema do colosso te dá ferramentas que ainda não temos — e construí-las só pra atender 0,1% dos casos não é prioridade.

Você tem requisitos de compliance que listam ferramentas nominalmente. Alguns frameworks de auditoria (FedRAMP, ITAR, certos contratos de governo) exigem que a stack rode sobre componentes específicos pré-aprovados. HeroCtl é jovem demais pra estar nessas listas. Se o seu compliance officer precisa apontar pra um certificado existente, hoje a resposta correta é o colosso ou o orquestrador ex-OSS. Mas se você precisa do nome de uma ferramenta na lista de auditoria, não é HeroCtl ainda.

Você precisa de uma biblioteca profunda de operadores especializados. O ecossistema do colosso tem centenas de operadores prontos — Postgres com replicação automática, Kafka com balanceamento, Cassandra com bootstrap. Se a sua arquitetura depende de quatro desses operadores rodando em produção desde o dia um, HeroCtl não substitui. A nossa proposta é diferente: você roda o seu Postgres como um job comum, cuidando de backup e replicação como um humano cuida — não delegando pra um operador que tomou três anos pra estabilizar.

Você quer multi-cloud com workloads se movendo entre provedores em tempo real. HeroCtl roda em qualquer servidor Linux com Docker, então tecnicamente você pode misturar provedores. Mas as primitivas pra mover storage cifrado entre regiões, replicar bancos pra outro provedor com failover automático, ou orquestrar redes virtuais entre nuvens — isso o ecossistema do colosso resolve melhor hoje. Está no nosso roadmap, não na versão atual.

Perguntas que a gente recebe

O HeroCtl é mais um wrapper do Docker? Não. Wrappers de Docker não fazem consenso entre servidores, não elegem coordenador, não sobrevivem à perda de um nó com automática redistribuição de trabalho. HeroCtl é um plano de controle replicado que coordena agentes em cada servidor. O Docker fica como runtime de contêiner — uma escolha de implementação, não a substância do produto.

E se a empresa por trás do HeroCtl quebrar? Três proteções contratuais. Primeiro, o binário não tem phone-home obrigatório — uma vez instalado, o seu cluster continua funcionando sem nunca falar com servidor nosso. Não há kill-switch remoto, não há ativação periódica que expira. Segundo, contratos Enterprise incluem escrow de código-fonte: se a empresa encerrar operações, o código é entregue aos clientes pagantes via terceira parte custodiante, com licença pra continuidade interna. Terceiro, o contrato de preço atual está congelado pra quem assina hoje — não há cláusula que permita mudança retroativa de termos. O que aconteceu com o orquestrador técnico em 2023 e em 2025 está estruturalmente impedido aqui.

Quanto consome de RAM e CPU em cluster pequeno? O cluster público de demonstração roda em quatro servidores totalizando cinco vCPUs e dez gigabytes de RAM, com dezesseis contêineres ativos servindo cinco sites. O plano de controle ocupa entre 200 e 400 MB por servidor — sobra pra workload real. Comparativamente, o plano de controle de uma versão gerenciada do colosso começa em cerca de 700 MB por nó-mestre antes de qualquer aplicação subir.

Posso migrar do orquestrador ex-OSS pro HeroCtl? Sim. As primitivas são similares (job, group, task; cluster com plano de controle replicado; agentes em cada servidor). A diferença grande está no arquivo de configuração — o nosso é mais curto e tem menos abstrações. Pra times com poucas dezenas de jobs, a migração é manual e leva uma tarde. Acima disso temos um conversor experimental que cobre os casos comuns. Escreve pra gente se for o seu caso.

Como funciona o pagamento? Três planos com linha clara entre eles. Community é gratuito pra sempre, sem limite de servidores, sem limite de jobs, sem feature gates artificiais — roda toda a stack descrita acima, incluindo HA, roteador, certificados automáticos, métricas e logs. Indivíduos e times pequenos nunca precisam sair daqui. Business adiciona SSO/SAML, RBAC granular, auditoria detalhada, backup gerenciado e suporte com SLA — pra times que têm requisitos formais de plataforma. Enterprise adiciona escrow de código-fonte, contrato de continuidade, suporte 24×7 e desenvolvimento dedicado.

Os preços de Business e Enterprise são publicados na página de planos — sem "fale com vendas" obrigatório. A linha de corte é desenhada pra você só pagar quando a empresa for grande o suficiente pra que SSO e auditoria sejam exigências reais, não preferência.

Está pronto pra produção? Está rodando a stack pública há seis meses, sobreviveu a uma bateria documentada de cenários de caos, e suporta o blog que você está lendo agora. "Pronto" depende do seu apetite a risco e do tamanho do seu time. Pra um indie hacker, três servidores e um SaaS de US$10k MRR, é mais do que pronto. Pra um banco regulado por três órgãos, espere mais alguns trimestres e converse com a gente sobre Business Edition primeiro.

Onde rodam os dados sensíveis (segredos, certificados, configurações)? No próprio cluster, criptografados em repouso. O cluster é o cofre — não há serviço externo de cofre obrigatório. Se você quer integrar com um cofre externo da sua nuvem (KMS de provedor cloud), há ponto de extensão; mas a configuração padrão é auto-suficiente.

O que vem nos próximos posts

A intenção do blog é técnica e direta: sem fluff de marketing.

• Engenharia: como o consenso é configurado, como funciona a defesa contra contêineres-zumbi segurando portas, por que escolhemos snapshot em memória em vez de bitmap persistido pra alocação de portas
• Comparativos: HeroCtl vs Coolify, HeroCtl vs Nomad, HeroCtl vs Kamal, HeroCtl vs Dokploy — números reais, não opinião
• Casos de uso: setup com 1 servidor (substituir painel simples), 3 servidores (HA real), 10+ servidores (escala)
• Novidades: changelog narrativo das features que shipam

Se você é desenvolvedor sentindo que o colosso é demais e o painel auto-hospedado é pouco, fique por aqui. Se você opera o orquestrador técnico e está incerto sobre o futuro pós-aquisição, escreva pra gente — tem caminho de migração.

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