Cloudron vs CasaOS vs Coolify em um VPS: qual escolher?

O que você está a construir

Você está a escolher uma ferramenta, não apenas a instalar uma. Três painéis prometem transformar um VPS vazio num servidor de aplicações com gestão por apontar e clicar: Cloudron, CasaOS e Coolify. Este guia instala cada um na mesma máquina Ubuntu 24.04 acabada de preparar, instala uma primeira aplicação e analisa os aspetos que raramente aparecem nas capturas de ecrã: TLS, cópias de segurança, atualizações, consumo de memória e a dificuldade de sair da plataforma. No final, saberá qual se adequa ao seu caso, ou se a resposta honesta é "nenhum deles, use apenas Docker Compose".

Nenhum destes painéis é mágico. Por baixo dos três está o mesmo Docker Engine que poderia gerir manualmente. O que um painel lhe fornece, em troca de dinheiro, RAM ou dependência da plataforma, são quatro tarefas: instalação de aplicações com um clique, certificados TLS automáticos, cópias de segurança agendadas e gestão de utilizadores. Se estas quatro funções justificarem o custo adicional, um painel pode ser útil. Se executar um ou dois serviços e quiser saber exatamente o que está na sua máquina, leia primeiro a secção "Ignore os três" e evite trabalho desnecessário.

Pré-requisitos comuns e limitações importantes

Os três pressupõem um VPS com KVM, não virtualização por contentores. O Docker precisa de um kernel real, e o Cloudron recusa explicitamente OpenVZ e LXC. Verifique com systemd-detect-virt: kvm ou qemu são aceitáveis, mas openvz ou lxc não são. Num plano KVM, o comando apresenta kvm; em bare metal, apresenta none. Qualquer um dos dois significa que pode continuar.

A partir daí, os requisitos divergem. Este é o primeiro fator que orienta a escolha.

• RAM. O CasaOS funciona bem com 1GB; foi desenvolvido para hardware Raspberry Pi e continua leve. O Coolify exige 2GB e dois núcleos de CPU como mínimo, e cerca de 600 MB são consumidos pelo próprio Coolify. O Cloudron precisa de 2GB no mínimo e funciona realmente melhor com 4GB, porque executa um servidor de e-mail e uma base de dados antes de instalar uma única aplicação.
• Um domínio e DNS sob o seu controlo. O Cloudron e o Coolify precisam de um domínio real com DNS funcional. Idealmente, o Cloudron precisa de acesso à API do seu fornecedor de DNS para criar registos e certificados wildcard automaticamente. O CasaOS funciona com um IP público, mas nesse caso não terá TLS.
• Portas. Os três precisam das portas 80 e 443 abertas para HTTP e HTTPS. O Coolify também disponibiliza o seu dashboard na porta 8000 e usa a porta 6001 para o canal realtime e a porta 6002 para o terminal no navegador. Mantenha a porta 22 aberta para SSH em todos eles.

Configure o DNS para apontar para o servidor antes de começar. Um painel que não consiga resolver o próprio hostname não consegue solicitar um certificado, e perderá a primeira hora a investigar esse problema em vez de configurar o software. Aponte um registo A para o IP do servidor e, no Coolify, adicione um registo wildcard (*.apps.example.com) para que cada aplicação implementada receba o seu próprio subdomínio.

Cloudron: o appliance completo e opinativo

O que é. Cloudron é uma plataforma comercial que transforma um servidor inteiro num appliance gerido. Executa o seu próprio reverse proxy, base de dados e stack de correio, além de uma App Store selecionada com aplicações empacotadas (Nextcloud, WordPress, Gitea, Mattermost e outras). Destina-se a quem quer as aplicações geridas, com atualizações automáticas, certificados automáticos e backups automáticos, e está disposto a pagar por isso.

Instalação. Exige um sistema limpo e assume o controlo completo dele. Execute isto num servidor Ubuntu 24.04 (Noble) acabado de instalar e não faça mais nada:

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

O script instala Docker, nginx, uma base de dados e a stack de correio, e depois reinicia o sistema. Quando o servidor voltar a estar disponível, abra https://<your-ip>, aceite o certificado temporário autoassinado e conclua a configuração no browser: indique o seu domínio, escolha o fornecedor de DNS e o Cloudron provisiona o seu próprio dashboard em my.example.com.

Adicionar a primeira aplicação. No dashboard, abra a App Store, clique, por exemplo, em Nextcloud, escolha o subdomínio files.example.com e prima Install. O Cloudron cria o registo DNS, solicita o certificado Let's Encrypt, provisiona a base de dados, configura o single sign-on e agenda um backup, tudo sem editar um ficheiro de configuração. Esta é a proposta principal do produto, e funciona.

TLS e backups. É a opção mais forte das três. Cada subdomínio de aplicação recebe um certificado Let's Encrypt automático, que é renovado pelo Cloudron. Os backups são agendados e integrados, com destino num diretório local, S3 ou outro armazenamento remoto, e incluem o restauro por aplicação e até a clonagem de uma aplicação para um novo subdomínio com um clique.

Custo e licenciamento: leia isto antes de decidir. Cloudron é um produto pago com um plano gratuito limitado: o plano gratuito permite duas aplicações. Ao instalar uma terceira aplicação, atinge um paywall; uma subscrição paga (Pro ou Max, faturada mensal ou anualmente, ambas com aplicações ilimitadas) desbloqueia mais funcionalidades. Esse é o facto mais importante sobre o Cloudron. O produto é polido precisamente porque é um negócio, e o plano gratuito está mais próximo de uma avaliação prolongada do que de uma solução para uma stack em crescimento.

Modo de falha, a regra do sistema limpo. Se tentar instalar o Cloudron num servidor que já executa outros serviços, a configuração é 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 é uma exigência arbitrária. O Cloudron fixa versões específicas de nginx, Docker e Node e integra-se profundamente com esses componentes, pelo que não pode coexistir com cópias instaladas por si. A solução é uma imagem Ubuntu 24.04 nova e sem mais nada: sem servidor Web, sem Docker e até sem uma firewall configurada manualmente. Se tiver iniciado a imagem errada, a configuração também recusa 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, os certificados wildcard exigem a API de DNS. Se escolher a opção "Manual" de DNS durante a configuração em vez de fornecer um token de API ao Cloudron, ele não poderá criar registos nem emitir um certificado wildcard. Para cada nova aplicação, terá de adicionar manualmente um registo DNS antes de o certificado poder ser emitido, e o dashboard ficará à espera desse registo. Dê ao Cloudron acesso à API de um fornecedor de DNS suportado (Cloudflare, Route 53, DigitalOcean e outros) e todo o processo passará a exigir apenas um clique.

CasaOS: o dashboard gratuito para home labs

O que é. O CasaOS, da IceWhale, é um dashboard gratuito e de código aberto que funciona sobre o Docker e disponibiliza uma página inicial, uma loja de aplicações e um gestor de ficheiros. Surgiu no ecossistema de servidores domésticos, por isso foi concebido para home labs: configuração rápida, interface simples e pouca complexidade operacional. Destina-se a utilizadores que querem uma interface mais amigável para o Docker sem pagar por isso.

Instalação. Uma linha é suficiente, e não exige um sistema limpo:

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

O instalador adiciona vários serviços systemd (casaos, casaos-gateway, casaos-app-management e outros). Confirme que o gateway iniciou antes de abrir um navegador:

systemctl status casaos-gateway

Quando estiver em execução, o dashboard estará disponível em http://<your-ip> (HTTP simples, porta 80). Crie uma conta local para começar.

Adicionar a primeira aplicação. Abra a App Store, escolha uma aplicação e clique em Install. O CasaOS cria um projeto Docker Compose em segundo plano e disponibiliza a aplicação numa porta do host, por exemplo http://<your-ip>:8080. A loja inclui as aplicações habituais para servidores domésticos, por isso um servidor multimédia Jellyfin num VPS ou uma biblioteca de fotografias Immich autoalojada fica a poucos cliques de distância. Se ainda não escolheu um servidor de fotografias, vale a pena ler sobre os requisitos mínimos de RAM e as aplicações móveis que distinguem o PhotoPrism do Immich, porque, num sistema CasaOS com 1GB, essa escolha determina se a aplicação funcionará. Também pode importar qualquer docker-compose.yaml que queira. Essa é a principal vantagem: as aplicações são contentores comuns, não um formato proprietário.

TLS e cópias de segurança: o ponto fraco. É aqui que o conceito de "gratuito" mostra as suas limitações. Por predefinição, o CasaOS disponibiliza tudo através de HTTP simples, incluindo o próprio dashboard. Não inclui Let's Encrypt nem cópias de segurança agendadas. Os seus dados ficam em volumes Docker em /DATA, e a responsabilidade pelas cópias de segurança é sua (um restic ou tar executado pelo cron).

Modo de falha, sem TLS e sem indicação visível. Nada apresenta um erro. Instala uma aplicação, abre http://<your-ip>:8080 e ela funciona através de uma ligação não cifrada que o navegador assinala como "Not Secure." As palavras-passe e os cookies de sessão atravessam a rede em texto simples. Pior ainda, o CasaOS teve vulnerabilidades reais de execução remota de código no dashboard (CVE-2023-37265 e CVE-2023-37266, uma falha de bypass de autenticação que permitia obter controlo total do host), por isso expor diretamente essa porta HTTP à Internet representa um risco real, não uma questão estética. A correção é nunca expor diretamente o CasaOS. Coloque à frente um reverse proxy que termine o TLS, como nginx com um certificado Let's Encrypt obtido pelo Certbot, Caddy ou um Cloudflare Tunnel, e encaminhe as ligações para o CasaOS apenas através da rede local. Tenha em atenção que o CasaOS já está associado à porta 80. O proxy e o CasaOS entrarão em conflito nessa porta, a menos que altere primeiro a porta do CasaOS.

Custo. É verdadeiramente gratuito, para sempre e sem limite de aplicações. O custo está na operação: é responsável pelo TLS, pelas cópias de segurança e pelo reforço da segurança.

Coolify: o PaaS auto-hospedado

O que é. Coolify é uma plataforma open source e auto-hospedada como serviço, semelhante ao Heroku ou ao Vercel no seu próprio servidor. A unidade nativa não é "instalar esta aplicação empacotada", mas "fazer o deploy deste repositório Git": ligue um repositório, e o Coolify compila-o, através do Nixpacks ou do seu próprio Dockerfile, e faz o deploy, repetindo-o a cada push. Também inclui bases de dados e serviços com instalação através de um clique. Destina-se a developers que fazem o deploy do seu próprio código e querem fazer deploy a partir de um push sem contratar um PaaS.

Instalação.

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

O script instala o Docker e inicia a própria stack de containers do Coolify. Confirme que estão saudáveis antes de continuar:

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

Deverá ver coolify, coolify-db, coolify-redis, coolify-realtime e coolify-proxy, todos com o estado Up. O dashboard está em http://<your-ip>:8000. Crie imediatamente a sua conta de administrador, porque a página de registo fica aberta até ser criada a primeira conta, e quem a aceder primeiro controla o servidor. Em seguida, defina o domínio da sua instância e aponte um registo DNS wildcard (*.example.com ou *.apps.example.com) para o servidor, para que o Coolify possa atribuir o seu próprio subdomínio a cada aplicação publicada.

Adicionar a primeira aplicação. Ligue uma fonte Git (GitHub, GitLab ou um URL de repositório simples), escolha uma branch, defina o domínio e faça o deploy. O proxy Traefik integrado no Coolify encaminha o subdomínio e solicita o certificado. Para software pronto a utilizar, o catálogo Services publica vários componentes em poucos cliques: a mesma stack de automação de workflows n8n que poderia configurar manualmente é uma entrada, e o Uptime Kuma para monitorização de páginas de estado também.

TLS e backups. O Let's Encrypt automático é configurado por aplicação através do Traefik incluído, pelo que cada subdomínio publicado recebe um certificado. Os backups são centrados nas bases de dados: pode agendar dumps de Postgres e MySQL para armazenamento compatível com S3. O backup de toda a instância, incluindo a configuração do Coolify, que fica em /data/coolify, é mais manual. Exporte-a e armazene-a por sua conta.

Custo e licenciamento. A edição auto-hospedada é totalmente open source e gratuita, sem limite de aplicações. Existe um Coolify Cloud opcional e pago que aloja o control plane por si, enquanto as aplicações continuam a executar nos seus próprios servidores. É conveniente, mas não é obrigatório.

Modo de falha: a aplicação é publicada, mas o domínio não carrega. O dashboard funciona corretamente em http://<ip>:8000, o build termina com sucesso, mas o URL da aplicação devolve um erro de ligação ou um erro 404 page not found do Traefik. Isso aponta para o proxy ou para o DNS, não para a aplicação. Existem duas causas comuns. Primeiro, as portas 80 ou 443 já estavam ocupadas quando o proxy tentou iniciar, e o seu container terminou 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, falta o registo DNS wildcard, pelo que o Traefik nunca recebe um pedido para esse hostname. Se, em vez disso, o cartão do servidor no Coolify mostrar "Server is not reachable", trata-se de uma falha diferente: o Coolify não consegue comunicar de todo com o socket Docker do servidor, normalmente porque o daemon do Docker está parado ou porque uma chave SSH está inválida. Consulte a causa real nos logs antes de tirar conclusões:

docker logs coolify-proxy --tail 100

Corrija o problema na página Proxy: prima Restart Proxy ou reponha a configuração do proxy para os valores predefinidos e inicie-o novamente. Depois, aguarde cerca de dois minutos para que estabilize. Mantenha a porta 8000 acessível apenas a partir do seu próprio IP, ou reabra-a temporariamente quando o proxy apresentar problemas, em vez de a deixar aberta para toda a Internet. Essa porta disponibiliza o dashboard através de HTTP simples. A documentação do Coolify indica que as portas 8000, 6001 e 6002 podem ser fechadas quando o dashboard é servido através do seu próprio domínio.

Sobrecarga de recursos no mesmo VPS

Medido em estado ocioso no mesmo servidor de 4GB, antes de implementar qualquer carga de trabalho real. Verifique o seu com free -m e docker stats --no-stream em vez de confiar num único valor, porque o total varia conforme a combinação das suas aplicações.

• CasaOS é a opção mais leve. O painel é composto por um pequeno conjunto de serviços Go; espere cerca de 150 a 300 MB de sobrecarga, além dos contentores que executar.
• Coolify executa vários contentores de suporte próprios (a aplicação, um Postgres, um Redis, um serviço realtime e o Traefik), por isso utiliza cerca de 600 MB a 1 GB em estado ocioso antes de implementar qualquer coisa.
• Cloudron é o mais pesado em estado ocioso, porque executa o seu próprio nginx, base de dados, stack de correio e monitorização, quer os utilize quer não; reserve 1 a 1.5 GB em estado ocioso. É por isso que requer 2GB no mínimo e funciona com mais folga com 4GB.

Num VPS pequeno de 2GB, o CasaOS deixa mais espaço para aplicações reais e o Cloudron deixa menos. Se o seu plano tiver 2GB e quiser executar o Cloudron com o servidor de correio ativo, planeie aumentar os recursos do servidor.

Atualizações, backups e lock-in em comparação

Atualizações. O Cloudron atualiza a plataforma e todas as aplicações por si, segundo uma agenda testada: exige menos esforço e oferece mais assistência. O Coolify atualiza-se a partir do próprio dashboard, com um botão. O CasaOS atualiza o painel através do script de instalação ou de apt, mas as aplicações instaladas são da sua responsabilidade: tem de as obter e reiniciar.

Lock-in, o problema que pesa no segundo ano. O CasaOS é o que cria menos dependência: as aplicações são projetos Compose comuns, por isso pode copiar docker-compose.yaml e os volumes em /DATA para qualquer outro host e continuar a utilizá-los. O Coolify fica a meio: os seus deploys usam os seus próprios Dockerfiles e repositórios, mas a configuração fica na base de dados do Coolify, por isso mudar de host implica recriar os projetos no novo ambiente. O Cloudron é o que cria mais dependência: as aplicações são empacotadas para o Cloudron e, embora os seus dados possam ser transferidos sem problemas através dos excelentes backups, o empacotamento não pode, pelo que tem de fazer um novo deploy na plataforma de destino. Dados portáveis, infraestrutura de suporte não portável.

Qual escolher

Versão curta, seguida da alternativa. Escolha Cloudron se quiser o servidor que exige menos intervenção dos três, pretender executar várias aplicações empacotadas e aceitar pagar uma taxa anual por TLS gerido, backups e atualizações. Escolha CasaOS se isto for um laboratório doméstico na sua própria rede ou atrás de um reverse proxy, se quiser uma interface simples para Docker e se não aceitar pagar nada. Escolha Coolify se fizer deploy do seu próprio código a partir do Git e quiser fazer push-to-deploy com TLS automático, sem pagar o preço de um PaaS alojado. Se nenhuma destas três opções se adequar ao seu caso, a secção seguinte apresenta a resposta honesta.

Ignore as três se...

Seja honesto quanto à sua escala. Se executar apenas uma ou duas aplicações, ou se quiser compreender e controlar exatamente o que está no seu servidor, ignore os painéis. A sobrecarga e o aprisionamento ao fornecedor não compensam numa stack pequena e estável. A opção DIY é colocar um reverse proxy à frente dos seus próprios ficheiros Compose: Traefik com TLS automático à frente de várias aplicações Docker Compose fornece HTTPS equivalente a um clique, sem a sobrecarga do painel, e pode fazer cópias de segurança com um job restic agendado no cron que realmente compreende.

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 uma única aplicação principal, o argumento é ainda mais claro: uma instalação do Nextcloud no Docker com TLS e a sua própria rotina de cópias de segurança consiste num ficheiro Compose e num certificado. Configurar um appliance inteiro para a executar teria apenas custos, sem benefícios. Se ainda estiver a decidir o que executar antes de decidir como, o guia sobre o que vale a pena alojar autonomamente em 2026 é um melhor ponto de partida.

FAQ

Preciso mesmo de um painel de self-hosting?

Apenas se valoriza as quatro tarefas que um painel automatiza em várias aplicações: instalações com um clique, TLS automático, backups agendados e gestão de utilizadores. Para um ou dois serviços, o Docker Compose simples atrás do Traefik faz o mesmo trabalho de TLS, com muito menos sobrecarga e sem lock-in. Os painéis compensam quando executa muitas aplicações e o seu tempo vale mais do que a RAM que consomem.

Qual é o melhor painel para um principiante?

Para um laboratório doméstico onde nada está exposto à Internet hostil, o CasaOS é o início mais simples: um comando e uma interface amigável, sem custos. Mas tem de colocar um reverse proxy com terminação TLS à frente antes de expor qualquer serviço, porque o produto disponibiliza HTTP simples. Se pretende que o TLS e os backups sejam geridos automaticamente e aceita pagar por isso, o Cloudron é a opção que mais acompanha o utilizador, dentro do limite gratuito de duas aplicações.

O Cloudron é gratuito?

Parcialmente. O nível gratuito permite duas aplicações, o que é suficiente para experimentar o produto ou para uma configuração muito pequena. A partir daí, o Cloudron é uma subscrição paga, faturada mensal ou anualmente, com aplicações ilimitadas nos níveis pagos. É um produto comercial com um plano gratuito limitado, não software livre, por isso inclua esse custo no orçamento se a sua stack for crescer.

Posso executar estes painéis juntamente com as aplicações que já tenho?

Cloudron: não. Exige um sistema Ubuntu limpo e aborta se nginx, Docker ou Node já estiverem instalados, porque gere toda a máquina. O CasaOS e o Coolify são mais flexíveis, pois instalam a sua própria stack Docker e, em princípio, podem partilhar um sistema, mas ambos precisam das portas 80 e 443, entrando em conflito com qualquer servidor web ou proxy que já esteja a executar. Num sistema que já aloja outros serviços, um painel costuma ser a ferramenta errada; use antes Traefik e Compose.

Como posso deixar de usar um painel mais tarde?

Planeie a saída antes de precisar dela. No CasaOS, copie o docker-compose.yaml da aplicação e os respetivos volumes /DATA para o novo host e inicie-os novamente. No Coolify, exporte a configuração de cada projeto e aponte-a para os mesmos repositórios no destino. No Cloudron, restaure os dados a partir dos backups para aplicações instaladas de novo na nova plataforma, porque o empacotamento do Cloudron não é transferível; apenas os dados são. Em todos os casos, teste a restauração num sistema descartável antes de desativar o sistema antigo.