Nos últimos dias, decidi testar o Coolify como uma camada de PaaS (Platform as a Service) auto-hospedada no meu próprio ambiente de servidores. O objetivo principal foi entender sua arquitetura interna, mapear cenários de convivência com ferramentas tradicionais (como o CloudPanel) e avaliar como a sua interface visual gerencia o ciclo de vida de aplicações em containers.
Abaixo, compartilho minhas anotações práticas, diagnósticos de baixo nível e estratégias de infraestrutura.
1. O que é o coolify e como ele funciona por baixo do capô?#
O Coolify posiciona-se como uma alternativa open-source e self-hosted a serviços como Heroku, Netlify e Vercel. Ele funciona como um controlador de orquestração que abstrai o Docker Engine (com suporte experimental a Swarm — Kubernetes não é suportado na v4 atual), eliminando a necessidade de gerenciar manualmente arquivos de configuração web e pipelines complexos de CI/CD para cada aplicação.
Mecanismo de execução e build#
- Comunicação com o Docker: O Coolify interage diretamente com o socket local (
/var/run/docker.sock) para provisionar containers, criar redes virtuais e gerenciar volumes. - Engine de build (Nixpacks vs Dockerfiles): Em vez de exigir um Dockerfile em cada repositório, o Coolify utiliza o Nixpacks por padrão. Ele inspeciona os arquivos do projeto (
package.json,composer.json,requirements.txt), identifica a stack e gera uma imagem Docker em camadas otimizadas. - Roteamento dinâmico com Traefik: Ele traz nativamente o Traefik como proxy reverso de borda. O Traefik monitora o socket do Docker e lê labels injetadas nos containers. Quando uma aplicação sobe, o Traefik detecta a rota, emite certificados SSL via Let's Encrypt (ACME) e atualiza o tráfego em tempo real, sem necessidade de recarregar daemons manualmente.
Gestão de recursos no kernel#
Ao contrário de ambientes tradicionais que utilizam cotas de disco por UID/GID (quotatool), o Coolify apoia-se nos Cgroups (Control Groups) do Kernel Linux:
- Os limites de CPU e memória definidos na interface são repassados como
--cpuse--memoryna API do Docker. - Bancos de dados e serviços com estado utilizam Docker Volumes mapeados em
/var/lib/docker/volumes/, mantendo os dados persistidos mesmo após atualizações de versão das imagens.
2. O desafio: rodar coolify e CloudPanel no mesmo servidor?#
No meu ambiente, o CloudPanel já estava em produção gerenciando vhosts Nginx e aplicações PHP. A dúvida inicial foi: é viável instalar e rodar o Coolify na mesma máquina física ou VPS?
A resposta direta é: tecnicamente é possível, mas traz gargalos sérios de convivência.
O conflito de portas (Traefik vs Nginx)#
O primeiro obstáculo ocorre na camada de transporte:
- O CloudPanel faz o bind direto do Nginx nas portas padrão
80(HTTP) e443(HTTPS). - O Coolify, por padrão, tenta inicializar o Traefik nas mesmas portas
80e443. - Ao tentar subir o Traefik com o Nginx ativo, a chamada de sistema
bind()do Kernel retorna o erroEADDRINUSE(Address already in use), fazendo o container do proxy entrar em loop de falha (CrashLoopBackOff).
Competição por recursos e OOM killer#
Em um servidor compartilhado:
- O CloudPanel roda processos locais (Nginx, PHP-FPM, MySQL) diretamente no host.
- Um build pesado disparado pelo Coolify (compilando aplicações Node.js ou Rust com Nixpacks) pode gerar picos de consumo de CPU e RAM.
- Se a memória RAM esgotar, o OOM Killer do Kernel Linux será acionado, com risco de encerrar processos vitais do banco de dados ou do servidor web.
3. Estratégias de arquitetura e convivência#
Para solucionar a convivência entre os dois ecossistemas, analisei dois caminhos práticos:
Abordagem 1: Instâncias separadas (cenário recomendado)#
A divisão física ou por VPS isolada é o modelo mais estável:
- Servidor 1 (CloudPanel): Dedicado a sites convencionais, aplicações PHP e serviços sob a stack do Nginx.
- Servidor 2 (Coolify): Dedicado exclusivamente a microsserviços, APIs e containers provisionados via Git.
Essa separação garante isolamento total de falhas: um pico de consumo durante um build no Coolify não afeta a disponibilidade dos sites no CloudPanel.
Abordagem 2: Coolify sem Traefik + reverse proxy no CloudPanel#
Se for obrigatório manter tudo em uma única máquina:
- Configura-se o proxy de cada recurso como None (sem proxy interno) na interface do Coolify.
- Os containers das aplicações são expostos em portas locais (
127.0.0.1:3000,127.0.0.1:3001). - No CloudPanel, cria-se um site do tipo Reverse Proxy, encaminhando o domínio
app.dominio.com.brpara a porta local correspondente.
Ponto de atenção: Ao desativar o Traefik, a emissão e renovação automática de certificados SSL passa a ser gerenciada exclusivamente pela interface do CloudPanel.
4. Gestão visual e recursos da interface#
Um dos pontos mais fortes do Coolify é a sua interface web, que transforma operações complexas de terminal em fluxos visuais:
- Automação Git e CI/CD: Conexão direta com GitHub ou GitLab via Webhooks. Cada
git pushinicia o build e realiza deploys atômicos com zero downtime. - Catálogo de serviços One-Click: Criação de bancos de dados (PostgreSQL, MySQL, Redis, MongoDB) com geração automática de senhas, redes privadas e volumes montados.
- Streaming de logs em tempo real: Conexão via WebSockets transmitindo o
stdoutestderrdos containers diretamente para o navegador. - Terminal interativo: Acesso direto ao console dos containers (
docker exec) pelo navegador e ajuste de variáveis de ambiente (.env) com redeploy automatizado.
Decisão prática de arquitetura#
O Coolify é uma excelente solução para quem busca a agilidade de um PaaS moderno mantendo o controle total da infraestrutura. No entanto, sua arquitetura baseada em containers e o uso padrão do Traefik exigem atenção especial ao compartilhar o host com painéis web tradicionais.
A melhor abordagem prática é manter responsabilidades separadas em servidores distintos ou, quando a convivência for necessária, planejar com clareza o mapeamento de portas e a cadeia de proxies reversos para evitar colisões no bind de rede.
Este artigo foi útil?
Deixe uma reação rápida para apoiar o conteúdo:
Veja também
Este post está licenciado sob CC BY-NC.
Comentários
Participe da discussão abaixo.
0 comentários