HeroCtl vs Coolify: quando o painel de um servidor não basta

A pergunta nunca foi "Coolify é bom?". É bom mesmo. A pergunta é "até quando o Coolify é o suficiente?".

Esse post não é sobre desbancar nada. É sobre desenhar uma linha — onde o painel num servidor único deixa de ser a resposta certa e começa a ser uma armadilha silenciosa que aparece no pior momento possível: na primeira reunião com o primeiro cliente que pergunta o número do SLA.

Por que o Coolify ganhou o segmento

Vale começar reconhecendo o que o Coolify acertou, sem ironia.

Instalação de cinco minutos numa VPS de US$10 por mês. Painel limpo, com um vocabulário familiar pra qualquer pessoa que já mexeu com Heroku ou Vercel. Plugin ecosystem ativo, comunidade engajada, lançamentos frequentes. O contrato gratuito pra self-hosting nunca mudou.

Pra um indie hacker em abril de 2026, com um servidor de 4 GB de RAM rodando um SaaS de US$5 mil de MRR, o Coolify é a melhor opção que existe no mercado. Melhor que o Dokku, melhor que o Caprover, melhor que o Dokploy em maturidade — e infinitamente melhor que orquestrar a mesma carga no Kubernetes gerenciado, que cobraria US$73 por mês só pelo plano de controle, antes de NAT, balanceador e qualquer coisa que entregue valor — assunto que destrinchamos em Kubernetes é overkill: quando você não precisa.

A categoria "Heroku auto-hospedado simples" foi inventada por essa geração de ferramentas. Coolify, Dokploy, Caprover dividem esse pódio. O Coolify lidera em adoção, em comunidade e em ritmo de release. Não é por acaso.

O ponto deste artigo é específico: existe uma parede que aparece quando o seu produto cresce, e essa parede não tem solução elegante dentro do Coolify. É um limite arquitetural, não um bug a ser consertado.

A parede invisível: o servidor único

Coolify foi desenhado em torno de um servidor central. O painel mora ali. O banco de configuração mora ali. As decisões de deploy partem dali.

Isso é uma escolha de design coerente — pra quem está numa VPS só, essa centralização é exatamente o que torna o produto tão simples. Não tem rede de cluster pra debugar, não tem certificado entre nós, não tem replicação de estado pra entender. Você liga uma máquina, instala, deploya. Cinco minutos.

A questão é o que acontece nos cenários abaixo:

• O disco da VPS começa a apresentar erros de I/O. O provedor agenda manutenção pra "remediar". A máquina fica indisponível por três horas numa madrugada de quarta-feira. Tudo que rodava nela está fora.
• Um update do kernel é empurrado pelo provedor e a máquina reinicia sozinha. O painel do Coolify volta — mas três contêineres entram em loop de restart porque dependem de uma volume mount que ainda está sendo remontado. Você descobre isso quarenta minutos depois, pelo Twitter de um cliente.
• O datacenter inteiro do provedor tem um incidente de rede regional. Acontece em janeiro de 2024 com um grande provedor europeu, em outubro de 2024 com um provedor americano, em fevereiro de 2026 com um provedor latino-americano. Sua máquina sequer está com defeito — só ficou inalcançável.
• Um deploy ruim consome toda a memória da máquina, o OOM killer começa a derrubar processos, e o próprio painel do Coolify entra em loop. Você não tem onde clicar pra reverter porque a interface que controla o cluster está dentro da máquina que precisa ser controlada.

Em todos esses cenários, a resposta operacional é a mesma: torcer pra máquina voltar, ou abrir um chamado, ou subir uma nova máquina e restaurar backup. Não há failover automático. Não há outra réplica do painel pra assumir. Não há eleição de coordenador entre servidores sobreviventes — porque só existe um servidor.

Quando o seu primeiro cliente sério pergunta "qual o SLA?", a resposta honesta é "best-effort, nossa máquina principal tem três noves de uptime histórico do provedor". É uma resposta que funciona pra alguns clientes. Não funciona pra clientes que têm o próprio SLA pra honrar. E são justamente esses clientes que pagam contratos anuais.

Multi-servidor no Coolify não é alta disponibilidade real

A confusão mais comum nessa conversa é o feature "remote servers" do Coolify.

O Coolify permite, sim, conectar máquinas adicionais como destinos de deploy. Você cadastra um IP, configura uma chave SSH, e o painel passa a saber que pode subir contêineres naquela máquina remota. Pra quem precisa separar staging de produção, ou colocar workers numa máquina mais barata, é útil de verdade.

Mas isso não é alta disponibilidade. É distribuição de carga.

A diferença está em onde o cérebro do sistema mora. No Coolify, o cérebro é a máquina principal — onde o painel roda, onde o banco SQLite ou Postgres do Coolify vive, onde as filas internas estão. As máquinas remotas são braços. Se o cérebro cai, os braços continuam segurando o que tinham nas mãos no momento da queda — os contêineres já em execução não morrem. Mas você perde:

• O painel web, integralmente.
• A capacidade de fazer deploys, reverter, mudar variável de ambiente, ler log centralizado.
• A capacidade de redirecionar tráfego entre réplicas se uma cair.
• Renovação automática de certificados (se a máquina principal era a que respondia ao desafio ACME).
• Health checks que reiniciariam contêineres com problema.

Você fica num estado zumbi: o site do cliente até pode continuar respondendo por algumas horas, mas você perdeu o controle do orquestrador. Religar a máquina principal vira a única operação útil — e se a razão da queda foi disco corrompido, você está restaurando backup às quatro da manhã.

Isso não é falha do Coolify. É uma consequência direta do desenho arquitetural — desenho que faz total sentido pra quem nunca vai precisar de nada além disso. O problema é quando a sua empresa cresce e as expectativas do cliente mudam. A ferramenta não cresce junto.

O passo seguinte natural

HeroCtl começa exatamente onde o Coolify pára. Mesma promessa de instalação simples — um comando, cinco minutos, painel web pronto. Mas o cérebro do sistema é replicado entre três ou mais servidores desde o primeiro momento.

Em termos práticos: você instala o mesmo binário em três máquinas Linux com Docker. Os três servidores combinam estado entre si por consenso entre servidores. Decisões importantes (qual contêiner vai pra qual nó, qual versão está ativa, qual certificado está renovado) são gravadas no log replicado e confirmadas só depois que a maioria concordou. Se um dos três cai — kill -9, queda de energia, partição de rede — os dois que sobraram elegem um novo coordenador em cerca de sete segundos e seguem servindo tráfego.

Não é mágica. É uma técnica conhecida há vinte anos, usada em produção por bancos, por sistemas de mensageria, por bancos de dados distribuídos. A novidade do HeroCtl é embalar isso num pacote que você instala em cinco minutos, com painel web embutido e sem exigir um operador especializado.

O roteador integrado distribui o tráfego entrante entre as réplicas saudáveis automaticamente. Se um servidor está fora, ele para de receber requisições — sem você precisar mexer em DNS, sem você precisar acordar de madrugada. Os certificados Let's Encrypt vivem no log replicado, então qualquer servidor sobrevivente pode renová-los e servi-los; não há "máquina principal" responsável pelo TLS.

A bateria de testes de caos cobre os cenários reais: kill -9 do coordenador (eleição em sete segundos, sem perda de requisição de leitura), partição de rede de 30 segundos (cluster reconverge sozinho), perda momentânea de quórum (sistema entra em modo somente-leitura preservando o tráfego existente, retoma escritas quando o quórum volta), wipe de disco em um nó (rejoina o cluster e baixa o estado do log replicado), drain forçado (workloads migram pros nós sobreviventes em segundos). Todos os cinco cenários sobrevividos no cluster público que serve este blog.

Lado a lado, sem floreio

A tabela abaixo é a versão honesta. Não tem coluna sem ressalva — toda ferramenta de orquestração é um conjunto de tradeoffs, e o HeroCtl também.

A linha que mais importa pra esta conversa é a quinta — alta disponibilidade real. As outras são consequências dela. Sem consenso entre servidores, não dá pra ter painel resiliente. Sem painel resiliente, não dá pra prometer SLA. Sem SLA, alguns clientes não fecham contrato.

A última linha também merece atenção. Coolify é incrível com um servidor. HeroCtl é incrível com três a quinhentos. Não são produtos da mesma faixa — são produtos que cobrem faixas adjacentes do mesmo problema.

Quando ficar no Coolify

Esta seção existe porque a honestidade é o mecanismo de defesa de uma ferramenta nova. Se a gente disser "todo mundo deveria usar HeroCtl", a gente está errando. Há cinco perfis em que recomendamos firmemente continuar no Coolify.

Você tem um servidor só e não pretende ter mais. Se a sua arquitetura cabe inteira numa VPS de 4 ou 8 GB de RAM, e o seu modelo de negócio não exige SLA contratual, o Coolify é a resposta correta. HeroCtl rodando num servidor único funciona, mas você está pagando o overhead de uma camada de coordenação que nunca vai precisar coordenar com ninguém. É como comprar um carro de cinco lugares pra fazer apenas viagens solo — não é errado, é só desnecessário.

Você está rodando aplicações internas ou de desenvolvimento. Ambientes de staging, dashboards internos, ferramentas que só o seu time usa, side-projects experimentais — todos esses casos não justificam multiplicar servidores. Uma queda de duas horas num staging não custa nada além do incômodo. Coolify entrega o melhor custo-benefício pra esse tipo de workload, e a gente recomenda abertamente.

Você é hobby developer. Projetos pessoais, blogs, portfolios, experimentos com APIs novas — fica no Coolify. O custo mental de operar um cluster de três servidores é maior do que o ganho percebido. Você quer publicar coisa, não administrar infraestrutura. O Coolify foi desenhado pra esse perfil. A gente não vai tentar empurrar uma ferramenta com mais cerimônia operacional do que o caso pede.

Você tem dependência forte de plugins do ecossistema Coolify. Se o seu fluxo depende de três plugins específicos do Coolify pra integrar com serviços terceiros que ainda não temos integração nativa, migrar agora é prematuro. Espere o HeroCtl maturecer essas integrações ou avalie se a integração específica vale o trabalho de reescrever. A gente prefere que você espere a integração existir do que migrar e descobrir um buraco no meio do caminho.

Você não está sentindo dor. Esse é o critério mais importante e o mais subestimado. Se o Coolify nunca falhou pra você, se a sua máquina principal tem três anos de uptime, se nenhum cliente seu já cobrou SLA — não migre por moda. Migração de ferramenta de orquestração tem custo real (uma a duas semanas de um engenheiro sênior, mais ajustes). Pague esse custo só quando a dor justificar. Migrar antes de sentir dor é uma forma elegante de queimar tempo de engenharia que poderia estar virando produto.

A regra mental simples: se a frase "se essa máquina cair às três da manhã, tenho problema sério com cliente" descreve a sua situação, é hora de avaliar. Se a frase "se essa máquina cair às três da manhã, eu acordo amanhã, religo, e tudo segue" descreve, fique onde está.

Como migrar quando faz sentido

A migração não precisa ser um big bang. O caminho que recomendamos é gradual, em quatro etapas, e mantém o Coolify funcionando o tempo todo.

Etapa 1 — Subir o cluster HeroCtl em paralelo. Três servidores novos, na mesma região, sem tocar no Coolify existente. Roda o instalador em cada um, junta no cluster, abre o painel. Validação básica: o painel responde nos três IPs, certificado de teste é emitido, um contêiner "hello world" sobe e responde. Tempo médio: uma tarde.

Etapa 2 — Migrar uma aplicação de baixo risco. Escolha uma aplicação interna ou de baixíssimo tráfego. Algo que, se ficar fora por dez minutos, não causa pânico. Reescreve o arquivo de configuração no formato do HeroCtl (em geral, cinquenta linhas substituem o que era um conjunto de campos no painel do Coolify). Sobe no cluster novo. Aponta um subdomínio de teste. Valida por uma semana.

Etapa 3 — Migrar workloads com tráfego real, uma de cada vez. Pra cada aplicação migrada, faz blue-green: sobe a versão no HeroCtl, aponta o DNS pra HeroCtl, mantém o Coolify rodando a versão antiga por 24 a 72 horas como fallback. Se algo der errado, rollback é trocar o DNS de volta. Quando tudo estabilizar, desliga a aplicação no Coolify.

Etapa 4 — Desligar o Coolify. Quando todas as aplicações migraram e ficaram estáveis por uma semana ou duas, desliga a máquina do Coolify. Mantém o backup do banco do Coolify por mais um trimestre, por garantia. Aí sim, encerra a VPS.

O ponto alto desse caminho é que em nenhum momento você fica sem opção de rollback. O Coolify continua rodando até o último dia. Se a migração der errado em alguma etapa, você volta um passo, ajusta, tenta de novo. Não há "ponto de não-retorno" forçado por arquitetura.

Tempo total típico, pra um portfolio de dez a vinte aplicações: duas a três semanas, com um engenheiro dedicando metade do tempo. Pra portfolios maiores, escala linearmente.

Perguntas que a gente recebe

O Coolify deploya em N servidores também. Qual é a diferença real? Coolify deploya contêineres em N servidores. HeroCtl roda o orquestrador em N servidores. A diferença é onde o cérebro vive. No Coolify, o cérebro vive na máquina principal — máquinas remotas são braços. No HeroCtl, o cérebro é distribuído: três ou mais servidores combinam estado por consenso, e qualquer um pode assumir o papel de coordenador se o atual cair. É a mesma diferença entre "ter cópias de um documento em vários computadores" e "ter um documento colaborativo em tempo real". Os dois têm múltiplas máquinas; só o segundo sobrevive à perda de uma delas sem perder controle.

Posso usar Coolify e HeroCtl juntos? Sim, e durante uma migração é a recomendação. Os dois rodam Docker como runtime, então não disputam recursos no nível do contêiner. O que muda é qual orquestrador olha pra qual conjunto de máquinas. Tecnicamente, dá pra manter aplicações antigas no Coolify pra sempre e usar o HeroCtl só pra workloads novos com requisito de HA — alguns times escolhem essa abordagem e nunca chegam a desligar o Coolify. Não há acoplamento forçado.

Quanto custa migrar? O custo direto é tempo de engenharia: duas a três semanas de meio-período pra um portfolio típico. O custo indireto é a curva de aprendizado do arquivo de configuração novo — geralmente meio dia pra um engenheiro sênior pegar o jeito. Não há custo de licença pra migrar (HeroCtl Community é gratuito permanente, sem limite de servidores ou de jobs), nem custo de saída do Coolify (você simplesmente para de usar). O custo de oportunidade é o engenheiro não estar fazendo outra coisa naquelas duas semanas.

O que eu perco do Coolify? A interface visual do Coolify é mais amigável pra quem nunca viu nada de orquestração — é um trade real. Alguns plugins do ecossistema Coolify ainda não têm equivalente no HeroCtl, especialmente integrações com serviços de nicho. A comunidade do Coolify é maior em volume — fóruns têm mais respostas pra perguntas específicas. E certas conveniências de UI (templates pré-configurados pra aplicações famosas) ainda não estão na mesma paridade. Esses pontos são reais e a gente reconhece.

E os plugins do Coolify que eu uso? Cada um vira uma análise individual. Pra integrações com bancos gerenciados (Postgres, Redis), o HeroCtl roda esses serviços como jobs comuns — sem necessidade de plugin específico. Pra integrações com serviços externos (envio de email, observabilidade SaaS), em geral é uma variável de ambiente apontando pra API do fornecedor — replicável em qualquer orquestrador. Pra plugins muito específicos, vale escrever pra gente — em alguns casos, equivalente nativo já está no roadmap.

Eu só tenho um servidor agora. Vale a pena já começar com HeroCtl? Honestamente: não. Se você tem um servidor só e nenhuma intenção de adicionar mais nos próximos seis meses, o Coolify é melhor pro seu caso. HeroCtl rodando num único servidor funciona, mas você está pagando overhead de coordenação que não tem com quem coordenar. A hora certa de começar com HeroCtl é quando você sabe que vai ter três ou mais servidores — seja porque o tráfego cresceu, seja porque o cliente pediu SLA, seja porque você quer dormir melhor. Antes disso, fica no Coolify.

Quando os preços de Business e Enterprise saem? Já estão publicados na página de planos, sem "fale com vendas". Business adiciona SSO/SAML, RBAC granular, auditoria detalhada, backup gerenciado e suporte com SLA — pra times com requisitos formais de plataforma. Enterprise adiciona escrow de código-fonte, contrato de continuidade e suporte 24×7. O contrato é congelado pra clientes existentes — não há cláusula de mudança retroativa. Community segue gratuita permanente, sem limite de servidores, sem limite de jobs, sem feature gates artificiais. Indivíduos e times pequenos nunca precisam sair do Community.

E se eu quiser voltar pro Coolify depois de migrar? Possível. Os contêineres rodam Docker em ambos os casos — as imagens são as mesmas. O que muda é o arquivo de configuração e o painel. Voltar significa recriar as configurações no Coolify e reapontar o DNS. A gente nunca trancou ninguém: o binário do HeroCtl não tem phone-home obrigatório, não há kill-switch remoto, e o cluster instalado continua funcionando offline pra sempre. Se a sua decisão é desligar e voltar, é só desligar e voltar. A liberdade de saída é o que torna a confiança honesta.

Fechamento

A escolha entre Coolify e HeroCtl não é técnica, é situacional.

Coolify é a resposta certa pra uma fase específica do crescimento de um produto: solo dev, MRR inicial, um servidor, sem pressão de SLA. HeroCtl é a resposta certa pra fase seguinte: time pequeno, MRR crescente, três ou mais servidores, primeiros contratos com SLA, primeiros clientes que cobram disponibilidade. As duas ferramentas atendem perfis adjacentes do mesmo problema.

Se você está na primeira fase, instala Coolify e fica feliz. Se você está entrando na segunda fase e sente a parede chegando, HeroCtl te encontra do outro lado.

Pra começar, em qualquer um dos três servidores Linux com Docker:

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

A instalação roda em cinco minutos, o painel sobe em cada um dos servidores, e o cluster está pronto pra receber jobs. Pra mais sobre por que o HeroCtl existe e que problema ele tenta resolver, leia o post de fundação.

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