Se já abandonou o PaaS gerido, o seu VPS está provisionado, a chave SSH adicionada, e o cursor do terminal pisca na linha de instalação. A única questão que resta: executa curl ... | bash para o Coolify, ou para o Dokploy?
Ambas as ferramentas se instalam com um comando. Ambas lhe dão implementações com Git-push, SSL automático, uma UI web e um proxy reverso por cima do Docker. As diferenças interessantes são as que aparecem em produção: como cada uma lida com um docker-compose.yml, o que acontece durante uma implementação, e como cada projeto respondeu às notícias que remodelaram esta comparação em 2026. Duas notícias carregam aqui a maior parte do peso: as Divulgações de CVE do Coolify de janeiro de 2026 e o Reestruturação da licença do Dokploy do mesmo mês.
Esta publicação associa cada ferramenta a um caso de uso específico em vez de coroar um vencedor. No final, esperamos que saiba qual delas se adapta ao seu fluxo de trabalho.
Resumo rápido
- Coolify é mais antigo e tem o ecossistema maior (~55k estrelas no GitHub, mais de 300 templates de serviços de um clique), mais pesado em repouso, Apache 2.0 em toda a parte, sem nível pago no lado self-hosted.
- Dokploy é mais recente (~34k estrelas), mais leve em repouso, núcleo Apache 2.0 mais uma Source Available License separada que controla futuras funcionalidades pagas (SSO, RBAC, registos de auditoria, white-labeling).
- Hoje o Coolify não consegue fazer implementações zero-downtime via Docker Compose; apenas via Dockerfile, Nixpacks ou implementações de imagem única. O Dokploy inclui o Docker Swarm como modo de primeira classe; o Swarm do Coolify está rotulado como experimental.
- Os CVEs do Coolify de janeiro de 2026 estão corrigidos na v4.0.0 (April 27, 2026). Atualize o Coolify e não exponha o dashboard publicamente.
Quando nenhuma das ferramentas é a resposta certa
Tanto o Coolify como o Dokploy têm o formato errado para algumas configurações. Três alternativas que vale a pena conhecer, em resumo:
- Kamal (da 37signals): para equipas com uma ou duas apps que querem zero UI; basta
kamal deploya partir do seu portátil. Mais simples do que o Coolify ou o Dokploy por uma margem larga, e a escolha certa quando não quer um dashboard. - Dokku: o clássico, modelo Git-push de servidor único. Mais antigo, âmbito mais reduzido, muito estável. O original "Heroku num VPS".
- GitHub Actions + Docker Compose num VPS sem extras: a pilha mais pequena possível. Sem UI de orquestração, mas também sem overhead de orquestração. Bom para uma única app onde o fluxo de implementação é
docker compose pull && docker compose up -dacionado a partir do CI.
Se o seu formato é uma app num servidor, tanto o Coolify como o Dokploy são provavelmente excessivos; experimente primeiro uma das opções acima. Se tem várias apps, várias bases de dados, ou uma equipa com membros não técnicos que precisam de uma UI para operar as coisas, a escolha entre Coolify e Dokploy é a mais acertada. Para um levantamento mais amplo das opções nesta categoria, veja a nossa compilação de plataformas de nuvem auto-hospedadas com interface web.
Coolify e Dokploy num relance
Coolify v4.0.0 estável foi lançado em April 27, 2026, após um longo ciclo beta. O Dokploy está na v0.29.4 a partir de May 11, 2026. Ambos são projetos PaaS self-hosted de código aberto no espaço das alternativas a Heroku/Render/Vercel, ambos envolvem o Docker com uma UI, um proxy reverso com HTTPS por predefinição (Traefik) e implementações baseadas em Git.
| Recurso | Coolify | Dokploy |
|---|---|---|
| Última versão estável | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| Licença | Apache 2.0 | Núcleo Apache 2.0 + Source Available para funcionalidades pagas |
| Pilha tecnológica | PHP / Laravel | TypeScript / Node.js |
| Estrelas no GitHub | ~55,000 | ~34,000 |
| RAM mínima (oficial) | 2 GB | 2 GB |
| CPU mínimo (oficial) | 2 cores | não especificado |
| RAM em repouso (reportada pela comunidade) | 500 MB – 1.2 GB | 300 – 400 MB |
| Zero-downtime com Docker Compose | Não suportado (apenas Dockerfile/Nixpacks) | Tratamento padrão de Compose |
| Clustering multi-servidor | Docker Swarm (experimental) | Docker Swarm (nativo) |
| Suporte a ARM64 | Sim (incl. Raspberry Pi OS) | Não publicitado na documentação |
| Sistemas de build | Nixpacks, Dockerfile, imagem Docker | Nixpacks, Dockerfile, imagem Docker, Heroku Buildpacks, Paketo, Railpack |
| Proxy reverso | Traefik | Traefik |
| Âmbito de monitorização self-hosted | Métricas integradas + visualizador de logs | Métricas básicas de recursos + análise de erros de log/build com IA (v0.29.0+) |
A nossa opinião: escolha o Dokploy se quer menor overhead em repouso, suporte multi-servidor nativo e tratamento padrão de Docker Compose sem ajustes específicos da plataforma. Escolha o Coolify se quer a maior biblioteca de apps de um clique, suporte a ARM64/Raspberry Pi, ou Apache 2.0 puro sem qualquer nível pago futuro à espreita.
Pegada de recursos e dimensionamento do VPS
Um PaaS self-hosted pode poupar-lhe o custo do Heroku. Se a camada de orquestração consumir 1,5 GB do seu VPS de 2 GB em repouso, não lhe sobra nada para onde implementar. Por isso, a primeira questão prática num servidor pequeno é: quanto lhe custa cada ferramenta antes mesmo de implementar uma única app?
O uso de RAM em repouso do Coolify depende da monitorização que está ativada, com uma pegada de CPU base de 5–7% que dispara quando a recolha de métricas é executada. A própria documentação do Coolify usa uma carga de trabalho de produção representativa de 8 GB de RAM, 4 cores e 150 GB de armazenamento a correr 3 apps Node.js, 4 sites estáticos e algumas bases de dados. É uma referência de dimensionamento razoável se a sua pilha for semelhante.
O Dokploy, em contraste, corre muito mais leve, bem abaixo de 2% de CPU quando nada está a ser implementado.
A Análise de produção da LogRocket a correr ambas as ferramentas lado a lado chegou à mesma conclusão direcional: um docker stop && docker start numa app Dokploy não despoleta uma reconstrução completa, enquanto a mesma operação no Coolify despoleta. Só isso desloca o custo em estado estável a favor do Dokploy, especialmente em planos de VPS mais pequenos onde tempestades de reconstrução consomem o seu orçamento de CPU.
Para dimensionamento, aqui está a configuração de VPS que eu recomendaria:
- Coolify, carga de trabalho leve: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, carga de trabalho de referência de produção: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, carga de trabalho leve: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, folga para produção: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
Dica de profissional: a RAM em repouso do Coolify escala com a configuração de monitorização. Se está apertado de memória, reduza o intervalo de recolha de métricas (ou desative inteiramente a monitorização integrada se já correr Prometheus/Grafana noutro sítio) antes de provisionar um servidor maior.
A realidade da implementação: Docker Compose, Dockerfile e zero-downtime
A maioria das equipas chega a uma destas ferramentas com um docker-compose.yml existente e uma expectativa: cola o ficheiro, clica em implementar, vê a app subir. A forma como cada plataforma lida com o Compose padrão, e o que acontece aos pedidos em curso durante a implementação seguinte, é onde a distinção prática aparece.
O Coolify suporta Docker Compose, Dockerfile, Nixpacks (deteção automática a partir dos ficheiros do projeto) e implementações diretas de imagem Docker. Há, no entanto, uma ressalva que vale a pena explicitar: as implementações zero-downtime (atualizações contínuas, blue/green) funcionam no Coolify apenas via Dockerfile, Nixpacks ou implementações de imagem única. Não funcionam via Docker Compose. Um responsável pela manutenção do Coolify confirmou numa discussão no GitHub que "para implementações baseadas em compose, todos os contentores são parados antes de iniciar os novos, não há atualização contínua para implementações baseadas em compose atualmente." O suporte de atualização contínua para Compose está no roadmap para a v5; a v4 não o terá. A solução alternativa que o responsável sugere é dividir uma pilha de Compose em serviços Coolify individuais, o que é uma migração nada trivial se o seu ficheiro Compose expressar relações reais entre serviços.
A consequência para o utilizador surge num tópico do Hacker News sobre o Coolify, onde um operador colocou a questão sem rodeios: "qualquer pedido pendente quando atualizas uma app é simplesmente eliminado." Isso é exato para as implementações de Compose hoje em dia.
A camada de Compose do Coolify acrescenta também aquilo a que o projeto chama "variáveis mágicas." Isso significa injeção automática de imagens auxiliares, reescritas de rede e substituições de ambiente. A intenção é ser mais eficiente; o efeito secundário é que um docker-compose.yml que corre sem problemas no seu portátil precisa por vezes de ajustes para correr sem problemas no Coolify. O mesmo tópico do Hacker News traz à superfície um caso representativo: "Adicionei 8 variáveis dentro do docker-compose, apenas 7 são reconhecidas." Se a sua pilha de Compose for pequena e padrão, talvez não encontre estes problemas. Se for grande ou invulgar, vai encontrá-los.
A postura do Dokploy é diferente. A análise prática da LogRocket análise prática , concluiu que o Dokploy "pode implementar um docker-compose.yml existente com pouca ou nenhuma modificação" e mantém-se próximo do modelo de routing nativo baseado em labels do Docker. A mesma análise nota que o parar/iniciar de contentores no Dokploy não despoleta uma reconstrução completa, ao passo que a mesma ação no Coolify despoleta. Este é um sinal direcional sobre o comportamento em tempo de execução, e não uma "garantia de zero-downtime" formal da documentação do Dokploy, mas alinha-se com o que os self-hosters reportam em instâncias de VPS mais pequenas.
O Dokploy também suporta Heroku Buildpacks, Paketo Buildpacks e Railpack, para além de Nixpacks e Dockerfile. Para equipas que chegam do Heroku com heroku.yml ou fluxos de trabalho baseados em buildpacks, esse é o caminho de menor resistência.
Conclusão-chave da secção: se os seus serviços existentes são uma verdadeira pilha de Docker Compose, o Coolify obrigá-lo-á a reestruturar a sua estratégia de implementação ou a aceitar uma breve indisponibilidade a cada push. O Dokploy não.
Segurança: As divulgações de CVE do Coolify de janeiro de 2026
Leio a história mais ampla desta forma: o Coolify é seguro de correr hoje se o mantiver atualizado e não expuser o dashboard à internet pública. A divulgação não desqualifica o projeto. A divulgação responsável foi seguida e os patches saíram. O que ela revela é que a superfície de ataque disponível para um utilizador autenticado de baixo privilégio era mais ampla do que deveria ser. Isso é uma lição de design para o projeto e uma lição operacional para o operador: aperte já o modelo de exposição.
Dica de profissional: mesmo depois de aplicar o patch, trate o seu dashboard do Coolify como o SSH. Ligue-o a uma rede privada, coloque-o atrás de uma VPN, ou ponha-o atrás de Tailscale. Não exponha a porta 8000 à internet pública só porque o script de instalação o torna fácil.
O Dokploy também não está isento deste tipo de problema. As notas de lançamento da v0.29.3 reconhecem uma vulnerabilidade de segurança identificada no Dokploy e incluem um script de patch de segurança que se espera que execute juntamente com a atualização. Superfície mais pequena, histórico de projeto mais curto, mas aplica-se a mesma disciplina operacional: atualize no dia em que os patches saem, não deixe o dashboard na internet pública.
Conclusão-chave da secção: a história dos CVE é uma bandeira amarela para a prática operacional do Coolify, não uma bandeira vermelha contra o projeto, mas eleva o nível de exigência quanto à disciplina de atualização e à forma como expõe o dashboard.
Licenciamento: O que é gratuito, o que não é
A licença do Dokploy foi reestruturada em January 21, 2026. Eis o que mudou e o que significa para os self-hosters.
O Dokploy é agora Apache 2.0 padrão para o núcleo, substituindo a anterior Apache 2.0 adaptada não padrão que confundia os utilizadores sobre o que era código aberto e o que não era. Uma Dokploy Source Available License separada rege agora o código nos diretórios proprietary/ diretórios: código-fonte visível, pago para uso em produção. As funcionalidades que o Dokploy diz que ficarão sob essa licença:
- Single Sign-On (SSO/SAML) e controlos de acesso avançados
- Branding personalizado e white-labeling
- Alta disponibilidade, auto-scaling e recuperação de desastres
- Monitorização avançada, integrações e funcionalidades de conformidade
O projeto comprometeu-se explicitamente a nunca mover uma funcionalidade de código aberto existente para o nível pago; a funcionalidade paga futura destina-se a organizações que precisam de cola empresarial. Hoje, o 2FA já se encontra sob o nível Startup na página de preços do Dokploy.
A situação do Coolify é simples. O projeto é Apache 2.0 no GitHub; todas as funcionalidades da versão self-hosted são gratuitas. Existe uma oferta Coolify Cloud para equipas que querem que o responsável pela manutenção o aloje, mas a versão self-hosted é um produto completo, sem barreiras de funcionalidades e sem caminho de upgrade para um nível pago que hoje não tem.
A minha leitura: para developers individuais e equipas pequenas que fazem self-host no seu próprio VPS, o Dokploy é funcionalmente gratuito e assim permanecerá. Para uma organização que acabe por precisar de SSO, RBAC granular, registos de auditoria ou white-labeling, o Dokploy acabará por o empurrar para um nível pago. O Coolify não, porque o Coolify não tem esse nível no roadmap.
Um esclarecimento entre fontes que vale a pena fazer: a build self-hosted do Dokploy inclui métricas básicas de recursos (CPU, memória, armazenamento, rede), e a v0.29.0 acrescentou análise de logs e erros de build com IA. O sistema de monitorização do Dokploy é apenas na cloud para as funcionalidades de monitorização mais avançadas. A monitorização, contudo, continua a correr localmente numa instalação self-hosted para métricas básicas de recursos pré-contentor.
Multi-servidor e clustering: realidade vs marketing
Mais cedo ou mais tarde um único VPS não chega, e ambos os projetos promovem o suporte multi-servidor de forma proeminente nas suas landing pages. A realidade no terreno não é a mesma.
A documentação oficial de escalabilidade do Coolify é direta sobre isto: o suporte a Docker Swarm está rotulado como experimental. O padrão multi-servidor standard usa servidores remotos validados ligados por SSH com um Docker Registry partilhado entre eles e instâncias de Traefik a correr por servidor. O modo Swarm requer um mínimo de três servidores na mesma arquitetura (todos ARM, ou todos AMD64). Kubernetes? "Apenas planeado, mas ainda não no roadmap, por isso sem ETA." Se ler a própria página do Coolify sobre isto, a versão curta é: o multi-servidor funciona, o Swarm é uma beta, e o Kubernetes é uma visão.
O Dokploy inclui o Docker Swarm como modo de primeira classe, sem flag experimental. O Traefik trata do routing tanto em configurações de servidor único como de Swarm. O lançamento da v0.29.0 acrescentou suporte multi-servidor não-root, o que fecha uma lacuna real (acabou-se o SSH só-root para adicionar nós remotos).
Se o clustering multi-nó é algo de que vai precisar nos próximos seis meses, e não "um dia num diapositivo," o Dokploy é a escolha de menor risco hoje em dia.
Conclusão-chave da secção: se o clustering está no seu roadmap de curto prazo, a diferença no Swarm inverte a recomendação a favor do Dokploy, independentemente dos outros eixos.
Sistemas de build e suporte a linguagens
As equipas que chegam do Heroku darão mais importância a quais ecossistemas de buildpack cada ferramenta suporta, porque isso decide quanta reescrita o seu projeto precisa antes da primeira implementação.
O caminho de build do Coolify é Nixpacks (predefinido, detetado automaticamente a partir dos ficheiros do seu projeto), Dockerfile, ou uma imagem Docker pré-construída. O Nixpacks é sólido para os casos comuns (Node, Python, PHP, Go, Rust), mas a deteção automática tem arestas por limar. Vale a pena verificar para a sua pilha: um problema do Nixpacks de janeiro de 2026 que afetava projetos Laravel com ambos composer.json e package.json produziu blocos de localização Nginx duplicados, o que quebrou uma classe de implementações até ser corrigido a montante.
O Dokploy suporta Nixpacks, Dockerfile e imagem Docker, e acrescenta por cima Heroku Buildpacks, Paketo Buildpacks e Railpack. Se o seu projeto já se constrói sem problemas com heroku.yml ou um buildpack, o Dokploy permite-lhe manter esse fluxo de trabalho. O Coolify vai pedir-lhe que o converta.
À primeira vista, ambas as ferramentas parecem iguais: implementações com Git-push a partir de GitHub, GitLab, Bitbucket, SSL automático Let's Encrypt, uma UI web para variáveis de ambiente e gestão de bases de dados. A amplitude dos sistemas de build é um dos poucos pontos onde o Dokploy claramente vai mais longe.
Catálogos de apps de um clique
Para operadores não técnicos que querem implementar serviços de código aberto conhecidos (n8n, Plausible, Supabase, Ghost, Listmonk, o habitual repertório self-hosted), o tamanho da biblioteca de templates de um clique é um verdadeiro fator diferenciador. Para alguns utilizadores, isso é mais importante do que outras áreas como o desempenho ou ser leve.
O Coolify oferece mais de 300 serviços de um clique em cerca de 40 categorias: IA, analítica, automação, bases de dados, segurança, armazenamento e o resto. É a maior biblioteca por uma margem larga e a resposta prática para não-developers que querem um serviço implementado sem escrever um ficheiro Compose.
A biblioteca de templates do Dokploy é mais pequena. A documentação atual do Dokploy não publica uma contagem clara, por isso não lhe vou dar um número.
A resposta prática: se o seu fluxo de trabalho é "implementar n8n, Supabase e Plausible com dois cliques cada," o Coolify vence este eixo claramente. Se escreve as suas próprias apps e só as quer implementadas, o tamanho do catálogo não interessa e os outros eixos sim.
Como escolher: recomendações por caso de uso
Não há aqui um único vencedor. Há correspondências entre uma ferramenta e um formato de implementação:
- Equipa não técnica que quer uma biblioteca de serviços: Coolify. O catálogo de mais de 300 templates é uma vantagem significativa.
- Developer focado em Docker que quer leveza + tratamento padrão de Compose: Dokploy.
- Hardware ARM64 (Raspberry Pi, VPS baseado em ARM): Coolify. O Dokploy não publicita suporte a ARM64 na documentação atual; se está em ARM, opte por predefinição pelo Coolify até confirmar o contrário.
- Clustering multi-nó que vai usar este trimestre: Dokploy. Swarm nativo vs. Swarm experimental é o fator decisivo.
- Apache 2.0 puro, sem possível nível pago futuro: Coolify.
- A migrar do Heroku e querer manter os Heroku Buildpacks: Dokploy.
- Preocupado com os CVEs de janeiro de 2026: um Coolify atualizado (v4.0.0+) está bem. A verdadeira questão é o seu modelo de exposição. Se não conseguir ligar o dashboard a uma rede privada ou VPN, o Dokploy é a escolha de menor stress: superfície mais pequena e um histórico mais curto de divulgações de alta severidade.
Uma nota sobre implementar qualquer uma das ferramentas
Depois de escolher, a instalação em si é um comando em qualquer dos projetos, mas há um atalho que vale a pena conhecer. Tanto o Coolify como o Dokploy estão disponíveis como implementações de um clique em nosso marketplace, com Ubuntu 24.04 e Docker pré-instalados e o dashboard já acessível. Se quer saltar a configuração manual, os anúncios no marketplace para Coolify e Dokploy são o caminho mais rápido. Se prefere começar a partir de um SO limpo e executar o instalador oficial você mesmo, ambos os projetos publicam um script de uma linha; escolha o que se adapta ao seu fluxo de provisionamento.
Perguntas frequentes
O Dokploy ainda é código aberto após a alteração de licença de 2026?
Sim, para a plataforma central. A partir de January 21, 2026, o núcleo do Dokploy é Apache 2.0 padrão. Uma Dokploy Source Available License separada rege agora o código nos diretórios proprietary/ diretórios, atualmente delimitada a futuras funcionalidades empresariais (SSO/SAML, RBAC granular, registos de auditoria, white-labeling). Para uso self-hosted individual e de equipas pequenas, o Dokploy é funcionalmente código aberto.
As vulnerabilidades de segurança do Coolify de janeiro de 2026 ainda são uma preocupação?
Os 11 CVEs divulgados estão corrigidos na v4.0.0 do Coolify (lançada a April 27, 2026). Se está a correr a v4.0.0 ou mais recente, as vulnerabilidades divulgadas estão resolvidas. O que resta é a exposição: mantenha o Coolify atualizado e não exponha o dashboard à internet pública. Ligue-o a uma rede privada ou coloque-o atrás de uma VPN.
