Cloudron vs CasaOS vs Coolify no VPS

O que você está construindo

Escolher uma ferramenta é tão importante quanto instalá-la. Três painéis prometem transformar um VPS vazio em um host de aplicativos via interface gráfica: Cloudron, CasaOS e Coolify. Este guia instala cada um deles em uma instância limpa de Ubuntu 24.04, instala um primeiro aplicativo e analisa detalhes que raramente aparecem em prints: TLS, backups, atualizações, consumo de memória e a dificuldade de migração. Ao final, você saberá qual deles é o ideal ou se a resposta honesta é "nenhum deles, use apenas Docker Compose".

Nenhum deles é mágica. Por baixo de todos os três, existe o mesmo Docker Engine que você poderia operar manualmente. O que um painel oferece, em troca de custo ou recursos, são quatro tarefas automatizadas: instalação de apps com um clique, certificados TLS automáticos, backups agendados e gerenciamento de usuários. Se essas quatro funções justificarem o overhead para você, o painel vale o investimento. Se você roda apenas um ou dois serviços e prefere saber exatamente o que está no seu servidor, leia a seção "Pule todos eles" primeiro para evitar trabalho desnecessário.

Pré-requisitos compartilhados e problemas comuns

Todos os três assumem um VPS KVM, não virtualização baseada em containers. O Docker exige um kernel real, e o Cloudron rejeita OpenVZ e LXC. Verifique com systemd-detect-virt: kvm ou qemu são aceitáveis, openvz ou lxc não são. Em um plano KVM o comando imprime kvm, e em bare metal imprime none; qualquer um dos dois indica que você pode continuar.

Além disso, os requisitos divergem, e este é o primeiro fator de escolha.

• RAM. O CasaOS funciona bem com 1GB; ele foi desenvolvido para hardware Raspberry Pi e permanece leve. O Coolify exige no mínimo 2GB de RAM e dois núcleos de CPU, sendo que cerca de 600 MB são consumidos pelo próprio Coolify. O Cloudron exige no mínimo 2GB e funciona melhor com 4GB, pois executa um servidor de e-mail e um banco de dados antes mesmo de você instalar qualquer app.
• Um domínio e DNS sob seu controle. Tanto o Cloudron quanto o Coolify exigem um domínio real com DNS funcional. O Cloudron prefere acesso via API ao seu provedor de DNS para criar registros e certificados wildcard automaticamente. O CasaOS funciona apenas com IP, mas sem suporte a TLS.
• Portas. Todos os três exigem as portas 80 e 443 abertas para HTTP e HTTPS. O Coolify também disponibiliza seu dashboard na porta 8000, utiliza a 6001 para o canal realtime e a 6002 para o terminal no navegador. Mantenha a porta 22 aberta para SSH em todos eles.

Configure o DNS para o servidor antes de começar. Um painel que não consegue resolver o próprio hostname não consegue solicitar certificados, e você perderá a primeira hora depurando isso em vez de usar o software. Aponte um registro A para o IP do servidor e, para o Coolify, adicione um registro wildcard (*.apps.example.com) para que cada app implantado receba seu próprio subdomínio.

Cloudron: o appliance refinado e opinativo

O que é. O Cloudron é uma plataforma comercial que transforma um servidor inteiro em um appliance gerenciado. Ele executa seu próprio reverse proxy, banco de dados e stack de e-mail, além de uma App Store curada com aplicativos empacotados (Nextcloud, WordPress, Gitea, Mattermost e outros). O foco são usuários que desejam aplicativos gerenciados, com atualizações automáticas, certificados automáticos e backups automáticos, e que estejam dispostos a pagar por isso.

Instalação. O sistema exige um servidor limpo e assume o controle total. Execute este comando em um servidor Ubuntu 24.04 (Noble) recém-instalado e nada mais:

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

O script instala Docker, nginx, um banco de dados e o stack de e-mail, e então reinicia o sistema. Quando o servidor retornar, acesse https://<your-ip>, aceite o certificado temporário autoassinado e finalize a configuração no navegador: aponte para seu domínio, escolha seu provedor de DNS e o sistema provisionará seu próprio dashboard em my.example.com.

Adicionando o primeiro app. No dashboard, abra a App Store, clique (por exemplo) em Nextcloud, escolha o subdomínio files.example.com e pressione Install. O Cloudron cria o registro de DNS, solicita o certificado Let's Encrypt, provisiona o banco de dados, configura o single sign-on e agenda um backup, tudo sem que você precise tocar em um arquivo de configuração. Este é o propósito do produto, e ele cumpre o que promete.

TLS e backups. O ponto mais forte dos três. Cada subdomínio de app recebe um certificado Let's Encrypt automático, renovado automaticamente para você. Os backups são agendados e integrados, com destino a um diretório local, S3 ou outro armazenamento remoto, permitindo restauração por aplicativo e até clonagem de um app para um novo subdomínio com um clique.

Custo e licenciamento, leia isto antes de decidir. O Cloudron é um produto pago com um nível gratuito limitado: o plano gratuito permite dois apps. Se você instalar um terceiro app, encontrará uma barreira de pagamento; uma assinatura paga (Pro ou Max, com cobrança mensal ou anual, ambas com apps ilimitados) libera mais recursos. Este é o fato mais importante sobre o Cloudron. Ele é refinado justamente por ser um negócio, e o nível gratuito é mais um período de teste estendido do que uma solução para uma stack em crescimento.

Modo de falha, a regra do servidor limpo. Se você tentar instalar o Cloudron em um servidor que já executa algum serviço, a configuração será abortada antes de alterar qualquer coisa:

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of it's installation.
Please start with a fresh Ubuntu install and run this script again.

A causa não é exigência desnecessária. O Cloudron fixa versões específicas de nginx, Docker e Node e os integra profundamente, portanto não pode coexistir com suas próprias cópias. A solução é uma imagem limpa do Ubuntu 24.04 e nada mais: sem servidor web, sem Docker, nem mesmo um firewall configurado manualmente. Se você iniciou a imagem errada, a configuração também recusará qualquer sistema que não seja um Ubuntu LTS suportado (22.04 ou 24.04) em x86-64; ARM, LXC e OpenVZ não são suportados.

Segundo modo de falha, certificados wildcard exigem API de DNS. Se você escolher a opção de DNS "Manual" durante a configuração em vez de fornecer um token de API ao Cloudron, ele não poderá criar registros ou um certificado wildcard para você. Cada novo app exigirá que você adicione um registro de DNS manualmente antes que o certificado possa ser emitido, e o dashboard ficará aguardando esse registro. Forneça ao Cloudron acesso de API a um provedor de DNS suportado (Cloudflare, Route 53, DigitalOcean e outros) e todo o fluxo passará a ser de apenas um clique.

CasaOS: o dashboard gratuito para home-lab

O que é. O CasaOS, da IceWhale, é um dashboard gratuito e de código aberto que roda sobre o Docker. Ele oferece uma tela inicial, uma loja de aplicativos e um gerenciador de arquivos. Ele foi desenvolvido para o cenário de home-servers, portanto foca em home-labs: instalação rápida, interface amigável e pouca burocracia. É voltado para entusiastas que desejam uma interface melhor para o Docker sem custos.

Instalação. Um único comando, e não exige um sistema limpo:

curl -fsSL https://get.casaos.io | sudo bash

O instalador adiciona um conjunto de serviços systemd (casaos, casaos-gateway, casaos-app-management e outros). Confirme se o gateway está ativo antes de abrir o navegador:

systemctl status casaos-gateway

Quando estiver rodando, o dashboard estará em http://<your-ip> (HTTP padrão, porta 80). Crie uma conta local para acessar.

Adicionando o primeiro app. Abra a App Store, escolha um app e clique em Install. O CasaOS cria um projeto Docker Compose em segundo plano e expõe o app em uma porta do host, por exemplo http://<your-ip>:8080. Sua loja possui o padrão de home-servers, então um servidor de mídia Jellyfin em um VPS ou uma biblioteca de fotos Immich self-hosted está a poucos cliques de distância. Você também pode importar qualquer docker-compose.yaml de sua preferência, que é o real diferencial: os apps são containers comuns, não um formato proprietário.

TLS e backups, o ponto fraco. É aqui que o termo "gratuito" mostra suas limitações. O CasaOS serve tudo via HTTP padrão por padrão, incluindo seu próprio dashboard. Não há Let's Encrypt integrado, nem agendamento de backup nativo. Seus dados ficam em volumes Docker em /DATA, e o backup é responsabilidade sua (via cron com restic ou tar).

Modo de falha: sem TLS e silencioso. Nenhum erro é exibido. Você instala um app, abre http://<your-ip>:8080 e ele funciona via conexão não criptografada, que o navegador marcará como "Não Seguro". Senhas e cookies de sessão trafegam em texto claro. Pior, o CasaOS já apresentou vulnerabilidades reais de execução remota de código em seu dashboard (CVE-2023-37265 e CVE-2023-37266, um bypass de autenticação que permitia o comprometimento total do host), portanto expor essa porta HTTP diretamente para a internet é um risco real, não uma questão estética. A solução é nunca expor o CasaOS diretamente. Utilize um reverse proxy à frente para encerrar o TLS, como nginx com um certificado Let's Encrypt do Certbot, Caddy ou um Cloudflare Tunnel, e encaminhe para o CasaOS apenas na rede local. Note que o CasaOS já utiliza a porta 80, então seu proxy e o CasaOS entrarão em conflito, a menos que você mude o CasaOS para outra porta primeiro.

Custo. Realmente gratuito, para sempre, sem limite de apps. O custo é operacional: você deve gerenciar o TLS, os backups e o hardening por conta própria.

Coolify: o PaaS self-hosted

O que é. O Coolify é uma plataforma como serviço (PaaS) de código aberto e self-hosted, similar ao Heroku ou Vercel, mas no seu próprio servidor. O conceito principal não é "instalar este app empacotado", mas sim "fazer o deploy deste repositório Git": conecte um repositório, e o Coolify realiza o build (via Nixpacks ou seu próprio Dockerfile) e o deploy, reiniciando o processo a cada push. Ele também possui bancos de dados e serviços de um clique. É focado em desenvolvedores que implantam seu próprio código e desejam o fluxo push-to-deploy sem alugar um PaaS.

Instalação.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

O script instala o Docker e inicia o stack de containers do Coolify. Verifique se eles estão saudáveis antes de prosseguir:

docker ps --format 'table {{.Names}}\t{{.Status}}'

Você deve ver coolify, coolify-db, coolify-redis, coolify-realtime e coolify-proxy todos reportando Up. O dashboard está em http://<your-ip>:8000. Crie sua conta de admin imediatamente, pois a página de registro fica aberta até que a primeira conta seja criada; quem chegar primeiro controla o servidor. Em seguida, defina o domínio da sua instância e aponte um registro DNS wildcard (*.example.com ou *.apps.example.com) para o servidor para que o Coolify possa atribuir um subdomínio para cada app implantado.

Adicionando o primeiro app. Conecte uma fonte Git (GitHub, GitLab ou uma URL de repositório), escolha uma branch, defina o domínio e faça o deploy. O proxy Traefik nativo do Coolify roteia o subdomínio e solicita o certificado. Para softwares prontos, o catálogo de Services realiza o deploy com poucos cliques: o mesmo stack de automação de workflow n8n que você teria que configurar manualmente é apenas uma entrada, assim como o Uptime Kuma para monitoramento de status-page.

TLS e backups. Let's Encrypt automático por app através do Traefik incluso, portanto cada subdomínio implantado recebe um certificado. Os backups priorizam o banco de dados: você pode agendar dumps de Postgres e MySQL para armazenamento compatível com S3. O backup da instância completa (a própria configuração do Coolify, que fica em /data/coolify) é mais manual; portanto, exporte e armazene você mesmo.

Custo e licenciamento. A edição self-hosted é totalmente open-source e gratuita, sem limite de apps. Existe o Coolify Cloud opcional (pago) que hospeda o control plane para você enquanto seus apps continuam rodando em seus próprios servidores; é conveniente, mas não obrigatório.

Falha: o app faz o deploy, mas o domínio não carrega. O dashboard funciona normalmente em http://<ip>:8000 e o build fica verde, mas a URL do app retorna um erro de conexão ou um erro de Traefik 404 page not found. Isso indica um problema no proxy ou no DNS, não no seu app. Duas causas comuns. Primeiro, as portas 80 ou 443 já estavam ocupadas quando o proxy tentou iniciar, fazendo o container morrer com um erro do Docker:

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

Segundo, o registro DNS wildcard está ausente, então o Traefik nunca recebe uma requisição para aquele hostname. Se, em vez disso, o card do servidor no Coolify exibir "Server is not reachable", o erro é diferente: o Coolify não consegue se comunicar com o Docker socket do servidor, geralmente devido ao daemon do Docker parado ou uma chave SSH corrompida. Verifique o motivo real nos logs antes de tentar adivinhar:

docker logs coolify-proxy --tail 100

Corrija pela página do Proxy: clique em Restart Proxy ou resete a configuração do proxy para o padrão e inicie-o novamente; aguarde cerca de dois minutos para a estabilização. Mantenha a porta 8000 acessível apenas pelo seu IP (ou reabra-a temporariamente se o proxy falhar) em vez de deixá-la aberta para o mundo — ela serve o dashboard via HTTP simples, e a própria documentação do Coolify afirma que as portas 8000, 6001 e 6002 podem ser fechadas assim que o dashboard for servido através de seu próprio domínio.

Sobrecarga de recursos na mesma VPS

Medido em idle na mesma máquina de 4GB, antes de implantar qualquer carga de trabalho real. Verifique o seu sistema com free -m e docker stats --no-stream em vez de confiar em um único número, pois o total varia conforme o mix de aplicativos.

• CasaOS é o mais leve. O painel é um pequeno conjunto de serviços em Go; espere uma sobrecarga de aproximadamente 150 a 300 MB além dos containers que você executar.
• Coolify executa vários containers de suporte próprios (o app, um Postgres, um Redis, um serviço realtime e o Traefik), portanto consome cerca de 600 MB a 1 GB em idle antes de você implantar qualquer coisa.
• Cloudron é o mais pesado em repouso, pois executa seu próprio nginx, banco de dados, stack de e-mail e monitoramento, independentemente de você utilizá-los ou não; reserve 1 a 1.5 GB em idle. É por isso que ele exige 2GB no mínimo e opera com mais folga em 4GB.

Em uma VPS pequena de 2GB, o CasaOS deixa mais espaço para aplicativos reais e o Cloudron deixa o menor espaço possível. Se o seu plano é de 2GB e você deseja o Cloudron com o servidor de e-mail rodando, planeje o upgrade da máquina.

Comparativo de atualizações, backups e lock-in

Atualizações. O Cloudron atualiza a plataforma e todos os apps para você seguindo um cronograma de testes: o menor esforço e o maior suporte automatizado. O Coolify atualiza a si mesmo pelo próprio dashboard com um botão. O CasaOS atualiza o painel através do seu script de instalação ou apt, mas a atualização dos apps instalados depende de você para realizar o pull e o restart.

Lock-in, o problema que surge no segundo ano. O CasaOS é o que apresenta menos lock-in: seus apps são projetos Compose comuns, então você pode copiar o docker-compose.yaml e os volumes em /DATA para qualquer outro host e continuar o trabalho. O Coolify está em um nível intermediário: seus deploys utilizam seus próprios Dockerfiles e repositórios, mas a configuração reside no banco de dados do Coolify, portanto, mudar de host exige recriar os projetos no destino. O Cloudron é o que apresenta mais lock-in: os apps são empacotados pelo Cloudron; embora seus dados possam ser exportados facilmente através de seus excelentes backups, o empacotamento não é portátil, exigindo um novo deploy na plataforma de destino. Dados portáteis, infraestrutura não portátil.

Qual escolher

Versão curta, seguida da alternativa. Escolha o Cloudron se você deseja o servidor que exige menos intervenção manual entre os três, pretende rodar vários aplicativos empacotados e aceita pagar uma taxa anual por TLS, backups e atualizações gerenciados. Escolha o CasaOS se este for um home lab atrás da sua própria rede ou um reverse proxy, se você busca uma interface amigável para Docker e não pretende pagar nada. Escolha o Coolify se você faz o deploy do seu próprio código via Git e deseja push-to-deploy com TLS automático, sem o custo de um PaaS hospedado. Se nenhum desses três se aplica ao seu caso, a próxima seção apresenta a resposta real.

Pule todos os três se...

Seja honesto sobre sua escala. Se você roda apenas um ou dois apps, ou se deseja entender e controlar exatamente o que está no seu servidor, pule os painéis. O overhead e o lock-in não valem a pena para uma stack pequena e estável. O caminho DIY consiste em um reverse proxy à frente dos seus próprios arquivos Compose: Traefik com TLS automático à frente de vários apps Docker Compose oferece o equivalente ao HTTPS de um clique sem o peso de um painel, e você faz o backup com um job restic via cron que você realmente entende.

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

Para um único app principal, o caso é ainda mais claro: uma instalação do Nextcloud no Docker com TLS e sua própria rotina de backup é apenas um arquivo Compose e um certificado. Implementar um appliance inteiro para rodá-lo traria apenas custos e nenhum benefício. Se você ainda está decidindo o que rodar antes de decidir como, o guia sobre o que vale a pena hospedar por conta própria em 2026 é o melhor ponto de partida.

FAQ

Eu realmente preciso de um painel de self-hosting?

Apenas se você valoriza as quatro funções que um painel automatiza em diversos apps: instalações com um clique, TLS automático, backups agendados e gerenciamento de usuários. Para um ou dois serviços, o Docker Compose puro com Traefik realiza a mesma função de TLS com muito menos overhead e zero lock-in. Painéis valem a pena quando você roda muitos apps e seu tempo vale mais do que a RAM que eles consomem.

Qual painel é melhor para iniciantes?

Para um home lab onde nada está exposto à internet pública, o CasaOS é o início mais simples: um comando e uma UI amigável, sem custos. Mas você deve configurar um reverse proxy com terminação TLS antes de expor qualquer coisa, pois ele entrega apenas HTTP puro. Se você quer TLS e backups gerenciados e está disposto a pagar por isso, o Cloudron é o que exige menos esforço, dentro do limite gratuito de dois apps.

O Cloudron é gratuito?

Parcialmente. O nível gratuito permite dois apps, o que é suficiente para testes ou setups muito pequenos. Além disso, o Cloudron é uma assinatura paga, com cobrança mensal ou anual, e apps ilimitados nos planos pagos. É um produto comercial com um plano gratuito limitado, não é software livre; reserve orçamento se sua stack for crescer.

Posso rodar esses painéis junto com meus apps atuais?

Cloudron: não. Ele requer um Ubuntu limpo e aborta a instalação se o nginx, Docker ou Node já estiverem instalados, pois ele gerencia a máquina inteira. CasaOS e Coolify são mais flexíveis, pois instalam seu próprio stack Docker e podem compartilhar uma máquina em princípio, mas ambos exigem as portas 80 e 443, o que causa conflito com qualquer servidor web ou proxy que você já utilize. Em uma máquina que já hospeda serviços, um painel geralmente é a ferramenta errada; use Traefik e Compose em vez disso.

Como eu saio de um painel futuramente?

Planeje a saída antes de precisar dela. No CasaOS, copie o docker-compose.yaml do app e seus volumes /DATA para o novo host e reinicie-os. No Coolify, exporte a configuração de cada projeto e aponte para os mesmos repositórios no destino. No Cloudron, restaure os dados dos backups para apps recém-instalados na nova plataforma, pois o empacotamento do Cloudron não é transferível, apenas os dados. Em todos os casos, teste a restauração em uma máquina de teste antes de desativar a antiga.