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

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

Além disso, os requisitos divergem. Este é o primeiro fator que orienta a escolha.

• RAM. O CasaOS funciona bem com 1GB. Foi desenvolvido originalmente para hardware Raspberry Pi e continua leve. O Coolify precisa de 2GB e de dois núcleos de CPU, no mínimo. Cerca de 600 MB desse total são usados pelo próprio Coolify. O Cloudron precisa de 2GB, no mínimo, mas funciona efetivamente melhor com 4GB, porque executa um servidor de correio e uma base de dados antes de instalar qualquer aplicação.
• Um domínio e controlo sobre o DNS. O Cloudron e o Coolify precisam de um domínio real com DNS funcional. Idealmente, o Cloudron também precisa de acesso à API do fornecedor de DNS para criar registos e certificados wildcard automaticamente. O CasaOS funciona com um IP sem domínio, mas nesse caso não terá TLS.
• Portas. O Cloudron e o Coolify precisam das portas 80 e 443 abertas para HTTP e HTTPS. O CasaOS disponibiliza o painel por HTTP simples, por isso precisa apenas da porta 80. O Coolify também disponibiliza o painel na porta 8000 e usa a porta 6001 para o canal realtime e a porta 6002 para o terminal no browser. Mantenha a porta 22 aberta para SSH em todas as opções.

Configure o DNS para apontar para o servidor antes de começar. Um painel que não consegue resolver o próprio hostname não consegue solicitar um certificado. Nesse caso, passará a primeira hora a diagnosticar esse problema em vez de configurar o software. Aponte um registo A para o IP do servidor. No Coolify, adicione também um registo wildcard (*.apps.example.com) para que cada aplicação implementada obtenha 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 suas 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 do servidor. Execute isto num servidor Ubuntu 24.04 (Noble) acabado de instalar e não instale 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 o stack de correio, e depois reinicia o servidor. 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 seu fornecedor de DNS e o Cloudron aprovisiona 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, aprovisiona a base de dados, configura o single sign-on e agenda um backup, tudo sem ter de editar um ficheiro de configuração. Esta é a proposta principal do produto, e funciona.

TLS e backups. É a solução mais completa das três. Cada subdomínio de aplicação recebe um certificado Let's Encrypt automático, que é renovado pelo sistema. Os backups são integrados e agendados, com destino a um diretório local, S3 ou outro armazenamento remoto. Também permitem restaurar cada aplicação individualmente e clonar 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 nível gratuito limitado: o plano gratuito permite duas aplicações. Ao instalar uma terceira aplicação, chega ao paywall; uma subscrição paga (Pro ou Max, faturada mensal ou anualmente, ambas com aplicações ilimitadas) desbloqueia mais funcionalidades. Este é o facto mais importante sobre o Cloudron. O produto é polido precisamente porque é um negócio, e o nível gratuito aproxima-se mais de uma versão de avaliação prolongada do que de uma plataforma para uma stack em crescimento.

Modo de falha, a regra do sistema limpo. Se tentar instalar o Cloudron num servidor onde já existe software em execução, 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 its 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-as profundamente, pelo que não pode coexistir com cópias geridas por si. A solução é uma imagem Ubuntu 24.04 nova e nada mais: sem servidor web, sem Docker e nem sequer uma firewall configurada manualmente. Se iniciou a imagem errada, a configuração também recusa qualquer sistema que não seja uma versão Ubuntu LTS suportada (22.04, 24.04 ou 26.04) em x86-64; ARM, LXC e OpenVZ não são suportados. Desde o Cloudron 10 (setembro de 2026), Ubuntu 26.04 é o sistema predefinido para novas instalações, pelo que é a imagem a escolher se está a começar do zero hoje.

Segundo modo de falha, os certificados wildcard precisam da API de DNS. Se escolher a opção DNS "Manual" durante a configuração em vez de fornecer um token de API ao Cloudron, este não consegue 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 fica à espera desse registo. Se conceder ao Cloudron acesso por API a um fornecedor de DNS suportado (Cloudflare, Route 53, DigitalOcean e outros), todo o processo passa 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 autoalojado

O que é. Coolify é uma plataforma open source, autoalojada, 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 sim "fazer deploy deste repositório Git": ligue um repositório e o Coolify compila-o (através de 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 deploy do seu próprio código e querem fazer push-to-deploy sem alugar uma 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 contentores 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á disponível 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 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 implementada.

Adicionar a primeira aplicação. Ligue uma origem 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 usar, o catálogo Services implementa serviços com alguns cliques: a mesma stack de automatização de workflows n8n que poderia configurar manualmente é uma das entradas, tal como o Uptime Kuma para monitorização de páginas de estado.

TLS e backups. O Traefik integrado obtém automaticamente certificados Let's Encrypt para cada aplicação, pelo que todos os subdomínios implementados recebem um certificado. Os backups dão prioridade às bases de dados: pode agendar dumps de Postgres e MySQL para armazenamento compatível com S3. O backup de toda a instância (a própria configuração do Coolify, que reside em /data/coolify) é mais manual, por isso exporte-a e armazene-a por sua conta.

Custos e licenciamento. A edição autoalojada é totalmente open source e gratuita, sem limite de aplicações. Existe um Coolify Cloud opcional (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 é implementada, mas o domínio não carrega. O dashboard funciona normalmente em http://<ip>:8000, o build termina com sucesso, mas o URL da aplicação devolve um erro de ligação ou um 404 page not found do Traefik. Isto aponta para o proxy ou para o DNS, não para a aplicação. Há duas causas comuns. Primeiro, as portas 80 ou 443 já estavam ocupadas quando o proxy tentou iniciar, pelo que o contentor 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, o hostname não resolve para o servidor: ou a aplicação usa um subdomínio gerado por wildcard e falta o registo DNS wildcard, ou usa um domínio personalizado sem um registo DNS próprio apontado para o servidor. Nesse caso, o Traefik nunca recebe um pedido para esse hostname. Se, em vez disso, o cartão de todo o servidor no Coolify apresentar "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 Docker está parado ou porque uma chave SSH está danificada. Consulte o motivo 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 volte a abri-la temporariamente quando o proxy apresentar problemas), em vez de a deixar aberta para toda a Internet. Essa porta serve o dashboard através de HTTP simples, e 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?

Só se valorizar as quatro tarefas que um painel automatiza em várias aplicações: instalações com um clique, TLS automático, cópias de segurança agendadas e gestão de utilizadores. Para um ou dois serviços, Docker Compose simples atrás do Traefik faz o mesmo trabalho de TLS, com muito menos sobrecarga e sem qualquer dependência do fornecedor. Os painéis compensam quando executa muitas aplicações e o seu tempo vale mais do que a RAM que eles consomem.

Qual é o melhor painel para principiantes?

Num 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 deve colocar um reverse proxy com terminação TLS à frente dele antes de expor qualquer serviço, porque o CasaOS fornece HTTP simples. Se quiser TLS gerido e cópias de segurança tratadas automaticamente, e estiver disposto a pagar, o Cloudron é o mais orientado para principiantes, dentro do limite gratuito de duas aplicações.

O Cloudron é gratuito?

Em parte. O nível gratuito permite duas aplicações, o que é suficiente para experimentar ou para uma configuração muito pequena. Acima desse limite, 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. Tenha isso em conta 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. CasaOS e Coolify são mais flexíveis, pois instalam a sua própria stack Docker e, em princípio, podem partilhar um sistema. No entanto, o CasaOS quer a porta 80 para o seu dashboard e o proxy do Coolify quer as portas 80 e 443. Por isso, cada um entra em conflito com qualquer servidor Web ou proxy que já esteja a utilizar essas portas. Num sistema que já aloja serviços, um painel costuma ser a ferramenta errada. Prefira Traefik e Compose.

Como posso deixar de usar um painel mais tarde?

Planeie a migração antes de precisar dela. No CasaOS, copie o docker-compose.yaml da aplicação e os seus volumes /DATA para o novo host e inicie-os novamente. No Coolify, exporte a configuração de cada projeto e aponte-o para os mesmos repositórios no destino. No Cloudron, restaure os dados a partir das respetivas cópias de segurança para aplicações recém-instaladas na nova plataforma, porque o empacotamento do Cloudron não é transferível. Apenas os dados são transferidos. Em todos os casos, teste a restauração num sistema descartável antes de remover o sistema antigo.