HEROCTL

Orquestração de
contêineres, sem cerimônia.

Um instalador. Cluster com alta disponibilidade em três comandos. Cinco sites em paralelo no mesmo cluster — incluindo este, servido por um quarto do CPU de um nó.

instalar
curl -sSL get.heroctl.com/install.sh | sh
Ver como funciona Ver o console
prova, não promessa
live
0sites
em produção agora neste cluster
0versões
promovidas sem travar o cluster
0req/s
sustentado por 1 réplica · 0 erros
0,0% CPU
no líder servindo os 5 sites
[01]por que existe

Kubernetes foi feito pro Google. Sua empresa não é o Google.

01custo humano

"4 engenheiros de plantão 24/7. US$ 564 mil por ano só pra manter o cluster de pé."

heroctl: 3 servidores + 1 worker operam mil nós. Zero operador dedicado.

fonte · CNCF Survey 2025
02complexidade

"80% dos incidentes em Kubernetes vêm de complexidade operacional — não da infra."

heroctl: Um instalador. Sem banco externo. Sem Helm. Sem CRD. Sem mesh extra.

fonte · Cloud Native Now, 2026
03yaml hell

"300 linhas de YAML pra subir um serviço. Um espaço errado derruba tudo."

heroctl: Configuração de dez linhas, validada na hora do submit. Zero ambiguidade.

fonte · mogenius, 2026
[02]como funciona

Três comandos até produção. Não é exagero de marketing — é o caminho real.

Instale

Um instalador único, sem dependência externa. Roda em Linux moderno. Pesa menos de 40 MB.

curl -sSL get.heroctl.com/install.sh | sh
→ heroctl instalado em /usr/local/bin
→ Linux x86_64 · 38 MB · checksum OK

Suba o cluster com alta disponibilidade

Três servidores se elegem automaticamente. Certificados internos, criptografia entre nós e descoberta de serviços já vêm ligados. Sobrevive à perda de um servidor.

heroctl server --bootstrap --peers=s1,s2,s3
→ líder eleito em 2.1s
→ certificados internos distribuídos
→ ingress up em :80 e :443

Envie o primeiro serviço

Arquivo de configuração curto, validado no momento do envio. Atualização gradual, canary ou rainbow — você escolhe por flag.

heroctl run api.yml --canary=25
→ plano: 4 réplicas em 3 nós
→ canary 25% saudável → promovendo
→ deploy concluído · 0 erros · 12s
[03]recursos

O que costuma ser um add-on, aqui vem de fábrica.

exclusivo

Rainbow deploys

Múltiplas versões convivendo no mesmo serviço. Mude o tráfego por flag, não por pipeline. Teste A/B com usuários reais, migração gradual, rollout por região — tudo declarativo.

embutido

Alta disponibilidade embutida

Três servidores se organizam sozinhos. Líder eleito em menos de 15 segundos no failover.

zero-config

Certificados automáticos

Criptografia entre serviços sai de fábrica. A plataforma emite e rotaciona certificados sozinha.

embutido

Roteador + TLS integrados

Ingress, TLS com Let's Encrypt e roteamento por host — tudo no próprio manifesto do serviço.

em tempo real

Observação em tempo real

Dashboards e API reagem em até 46ms com 200 nós. Sem polling de 30 segundos.

contra zombies

Auto-cura contra zumbis

Quatro relógios correm em paralelo: sincronização entre servidores, alocações órfãs, redes de isolamento, contêineres encerrados. Specs quebradas não ficam assombrando o cluster.

liveness + readiness

Rollover saudável

Servidores e contêineres novos só entram no pool de roteamento depois de passar no health check. Liveness e readiness separadas, como no Kubernetes.

[04]escolha como atualizar

Quatro estratégias. Uma linha de diferença.

Troque strategy e o orquestrador reconfigura o pipeline de deploy, o roteador e os health checks. Sem plugin externo, sem operador especializado, sem arquivo extra.

deploy.rolling
update {
strategy = "rolling"
max_parallel = 1
min_healthy_time = "10s"
healthy_deadline = "3m"
auto_revert = true
}

Rolling

Uma por vez, espera ficar saudável, continua.

O padrão seguro. Cada instância sobe, passa no health check, e só então a próxima começa. Zero downtime, previsível, fácil de auditar.

rollback automático em qualquer uma · nenhuma config extra
[05]console

Isso é o que você opera todo dia.

Sem vídeo, sem tour guiado — clique em qualquer tela pra ver em tamanho real.

dashboard4 nós · 9 allocations · 5 jobs
[06]auto-recuperação

Quatro relógios correndo o tempo todo para o cluster se consertar sozinho.

Sistemas distribuídos derivam em silêncio: uma alocação órfã aqui, um contêiner esquecido ali, uma rede sem uso acumulando. A plataforma roda quatro varreduras independentes em cadências diferentes e corrige no momento em que vê o desvio — nada chega ao operador.

[01]
a cada 60s

Sincronização entre servidores

Cada servidor confere o estado de cada serviço ativo e alinha silenciosamente com os pares. Discrepâncias sutis desaparecem antes de virar incidente.

Zero intervenção · desde que os servidores se falem
[02]
a cada 5min

Alocações órfãs

Serviços cujo dono foi removido (namespace deletado, configuração apagada) são detectados e encerrados automaticamente. Sem lixo ocupando CPU ou portas.

Dispara junto com exclusão · não requer limpeza manual
[03]
a cada 15min

Redes de isolamento

Bridges de namespace sem contêiner ativo são recolhidas automaticamente. Espaço IP preservado, sem esgotamento silencioso de pool.

Usa o próprio runtime como trava de segurança
[04]
a cada 10min

Contêineres encerrados

Contêineres terminados ficam 10 minutos em disco para inspeção post-mortem e depois são removidos. Logs acessíveis, depois espaço liberado.

Janela de auditoria embutida · mesmo padrão do Kubernetes
todas as cadências são configuráveis
[07]honestamente

Lado a lado. Sem exagero. Sem retoques.

recurso
Instalação
kubernetes
Dezenas de componentes
docker swarm
Um comando (vem com Docker)
nomad
Três ferramentas separadas
heroctl
Um comando
recurso
Ingress / TLS
kubernetes
Controlador + gerenciador de cert externo
docker swarm
Roteador interno + cert por fora
nomad
Gateway + serviço extra
heroctl
Tudo integrado
recurso
Criptografia entre serviços
kubernetes
Gerenciador de cert + CRDs
docker swarm
Automática
nomad
Serviço de secrets externo
heroctl
Automática
recurso
Manifesto do serviço
kubernetes
YAML de 300+ linhas
docker swarm
docker-compose
nomad
Arquivo de configuração próprio
heroctl
Dez linhas · validadas no envio
recurso
Alta disponibilidade
kubernetes
Banco externo
docker swarm
Integrada
nomad
Próprio mas separado
heroctl
Integrada
recurso
Deploy rainbow
kubernetes
Malha de serviço + integração própria
docker swarm
Não suportado
nomad
Plugin externo
heroctl
Por flag
recurso
Desenvolvimento ativo
kubernetes
Intenso
docker swarm
Mantido mas sem grandes novidades desde 2019
nomad
Ativo
heroctl
Ativo · roadmap público
recurso
Engenheiros dedicados
kubernetes
4 ou mais
docker swarm
1 a 2
nomad
1 a 2
heroctl
Nenhum

// Kubernetes é pra quem tem time de infra dedicado e topa o investimento: pessoas, ecossistema, meses de onboarding, conta do cloud maior. Docker Swarm resolve bem quem só quer subir um compose e seguir a vida. No meio — onde a maioria dos times de verdade vive — é pra isso que HeroCtl existe. Um comando te coloca em produção.

[08]menos pra manter

Um stack contra um binário.

Pra colocar um site HTTPS em produção com alta disponibilidade, cada alternativa exige montar uma pilha. O HeroCtl é a pilha.

kubernetes12 comp.
auto-hospedado em produção
  • kube-apiserver
  • etcd
  • controller-manager
  • scheduler
  • kubelet
  • kube-proxy
  • CNI (Calico/Cilium)
  • CoreDNS
  • cert-manager
  • ingress-nginx
  • ExternalDNS
  • metrics-server
rancher6 comp.
Rancher + RKE2 em produção
  • Rancher Manager
  • RKE2 (= Kubernetes)
  • cert-manager
  • ingress-nginx
  • ExternalDNS
  • etcd
nomad5 comp.
stack HashiCorp web-ready
  • Nomad
  • Consul
  • Consul Connect
  • Vault
  • Traefik/Envoy
heroctl1 comp.
um binário
  • heroctl
inclui tudo à esquerda
[08·b]footprint mínimo

Nosso cluster inteiro cabe onde o painel de controle deles começa.

rancher · painel de controle HA
só o management plane, sem as workloads
cpu
12 vCPU
ram
24 GB
kubernetes · control plane auto-hospedado
api-server + etcd + controller + scheduler em HA
cpu
6 vCPU
ram
12 GB
nomad + consul + vault · servidores
3 rings Raft separados, só o plano de controle
cpu
6 vCPU
ram
12 GB
heroctl · cluster inteiro servindo 5 sites
3 servidores + 1 worker. Inclui control plane, ingress, TLS e os 5 workloads.
cpu
5 vCPU
ram
10 GB

// Números mínimos dos próprios docs de cada produto (abr/2026). Nossa linha é medida no cluster que está servindo este site. Gerenciados como EKS/GKE removem o peso do seu lado, mas aparecem como conta fixa por cluster e ainda exigem os add-ons de ingress, TLS e mTLS que cada time acaba operando.

[09]ruthless honesty

Onde o HeroCtl não é a melhor escolha.

Três situações onde outra ferramenta serve melhor. Todas raras — e nem sempre tão absolutas quanto parecem à primeira vista. Se nenhuma for a sua, você está exatamente no meio da curva onde HeroCtl foi desenhado.

não é aqui

Escala planetária — hoje

Se já hoje você opera 10.000+ nós em múltiplas regiões ativas, com federação, malha de serviço e roteamento geográfico complexo.

use

Kubernetes + Istio + Argo é o estado da arte — e cobra caro: 4+ SREs dedicados 24/7 e conta cloud em outro patamar. HeroCtl vai de 1 nó a alguns milhares numa região. Quando você de fato chega na CNCF-scale, a equipe que formou aqui carrega a bagagem técnica pra migrar.

não é aqui

Certificação com produto nomeado

Se o seu auditor exige um produto citado nominalmente em contrato com selo FedRAMP High, PCI Level 1 ou conformidade CNCF formal, assinado por fornecedor enterprise com SLA.

use

Red Hat OpenShift ou Rancher Prime têm o selo. Os controles técnicos que o selo exige — criptografia em trânsito, isolamento, auditoria — estão aqui. O que falta é o papel assinado.

não é aqui

Biblioteca profunda de operators

Se a sua platform team já mantém dezenas de operators do ecossistema K8s — Postgres, Kafka, Crossplane, Prometheus — e abstrações específicas por banco são produto interno.

use

Kubernetes. Esse ecossistema é o ponto forte real dele. Para a maioria dos times, aliás, serviços gerenciados (RDS, Redis Cloud, MSK) resolvem o mesmo problema sem operator nenhum — e sem virar time de plataforma.

Três edge cases. Todos raros. Tudo que sobra — times de 3 a 50 pessoas rodando dezenas a alguns milhares de contêineres em 1, 2 ou dezenas de servidores — é a imensa maioria. E é exatamente o que HeroCtl resolve com um instalador e três comandos, sem time de plataforma dedicado, sem licença corporativa, sem conta de cloud que surpreende no fim do mês.

[10]medido em 23/abr/2026

Os números saíram do cluster. Sem extrapolação.

Cluster real de 4 nós · 5 vCPU · ~10 GB, servindo 5 sites ao vivo. Carga gerada pela borda pública — rota completa internet → roteador → contêiner → resposta. Ferramentas: ab e hey.

capacidade observada

~100 req/s por réplica

1 réplica · 128 CPU shares · 64 MB RAM · nginx:alpine servindo HTML estático. Acima disso, o roteador devolve 503 em vez de derrubar o contêiner.

chaos battery · 17 / 19 cenários de falha recuperados sozinhos
borda pública → heroctl.com · c=20 · 30s sem erros
01Resposta mediana
0 ms
02Resposta P95
0 ms
03Resposta P99
0 ms
04Vazão sustentada
0 req/s
05Erros
0 / 2.937
control plane · carga real de 5 sites caught up
01API P50 (control plane)
0 ms
02API P99 (control plane)
0 ms
03Lag Raft (commit → apply)
0 ms
04CPU do líder servindo 5 sites
0,0 %
05RAM do líder
0 MB / 1.963
[11]Notas de quem opera o cluster

Diário técnico,

Engenharia, comparativos honestos, decisões de arquitetura e custos reais — tudo o que a gente aprende rodando HeroCtl em produção.

Engenharia·

Deploy zero-downtime sem Kubernetes: tutorial prático em 2026

Você não precisa de Kubernetes pra ter deploy sem downtime. Tutorial completo com 2 servidores, Caddy/Traefik na frente, e rolling update via script ou orquestrador leve.

15 min
Engenharia·

API Gateway self-hosted: quando vale instalar Kong, Traefik ou similar

API gateway resolve auth, rate limit, transformações e observabilidade — em troca de mais um componente crítico. Quando reverse proxy simples basta vs quando vale o gateway dedicado.

13 min
Engenharia·

Service mesh é overkill pra startup brasileira? Quando vale instalar Istio/Linkerd

Service mesh resolve problemas reais (mTLS, observabilidade entre serviços, traffic shaping). Mas adiciona 30-50% overhead de RAM/CPU e complexidade. Quando vale e quando é overkill.

13 min
Caso de uso·

Como sair da AWS sem reescrever toda a stack: guia prático 2026

Migrar de AWS pra cloud mais barato (Hetzner/DO) ou auto-hospedado parece projeto de 1 ano. Na prática, dá pra fazer em 6-8 semanas se você mapear os 12 serviços AWS-only que sua stack usa de verdade.

16 min
Ver todos os posts
pronto pra começar

Pare de administrar
o seu orquestrador.

38 segundos pra instalar. Três minutos pra subir o cluster. Depois disso, volta a construir produto.

Instalar em 38 s Ver o console

sem cadastro · sem cartão · sem vendedor ligando depois