CapRover e Docker em Nodes Dedicados: Como Gerir a Tua Própria Cloud a 10% do Custo da AWS

A Armadilha da AWS: Porque Uma PaaS Própria Derrota as Margens dos Gigantes da Cloud

Se analisares com atenção as contas de muitas empresas de tecnologia, o alojamento em nuvem é frequentemente a segunda maior fatura mensal a seguir aos salários da equipa. Startups e agências digitais pagam frequentemente entre 2.500€ e 10.000€ todos os meses à Amazon Web Services (AWS), Google Cloud ou Microsoft Azure para correrem cargas de trabalho perfeitamente modestas.

O modelo financeiro destes fornecedores gigantes baseia-se em pequenas taxas acumuladas. Não pagas apenas pela máquina virtual; pagas pelo tráfego de saída por gigabyte (cerca de 0,09$ por cada GB transferido), pagas pelos gateways de tradução de rede (NAT), pagas pelas operações de leitura e escrita nos discos EBS e pagas por cada balanceador de carga. Uma equipa que queira colocar no ar uma API interna e duas aplicações web facilmente gasta 400€ por mês no AWS Elastic Container Service (ECS) antes de receber o primeiro milhar de utilizadores reais.

A TAXA DOS GIGANTES VS. SERVIDOR DEDICADO

• HIPERSCALER (AWS / GCP / AZURE): [ 4 vCPUs virtuais / 16GB RAM ] → ~140 € / mês
• Balanceador Gerido (ALB): ~25 € / mês
• Gateway de Rede NAT: ~35 € / mês + custo por GB
• 1TB Tráfego de Saída: ~90 € / mês
• Base de Dados PostgreSQL: ~180 € / mês
• FATURA TOTAL: ~470 € / mês para capacidade limitada
• SERVIDOR DEDICADO + CAPROVER (HETZNER / OVH / EQUINIX): [ AMD Ryzen 7 / 64GB DDR5 / 2x1TB NVMe / Tráfego Ilimitado ] → ~48 € / mês
• [ Motor de Orquestração CapRover (Código Aberto)
• ] → 0 € / mês
• FATURA TOTAL: ~48 € / mês com o quádruplo do processamento e da memória!

Na Webxtek Studio, rejeitamos a obsessão por complexidade desnecessária. Defendemos uma filosofia clara de Anti-Over-Engineering: escolher a arquitetura mais simples, rápida e económica que resolva o problema do negócio com total fiabilidade.

Ao combinares servidores dedicados com o CapRover e o Docker, constróis a tua própria plataforma privada de alojamento (PaaS). Consegues colocar aplicações em contentores no ar com um simples comando de Git ou um webhook automático—a cerca de 10% do custo cobrado pelos fornecedores de nuvem tradicionais.

Modelo Mental sem Jargão: Como o CapRover Automatiza o Docker Swarm e o Nginx

Para compreenderes o papel do CapRover, imagina-o como o maestro inteligente que coordena uma orquestra inteira de contentores de software.

Se tentares gerir vários contentores Docker manualmente num servidor, tens de fazer todo o trabalho pesado:

1. Escrever ficheiros Dockerfile e compor manifestos complexos com o Docker Compose.
2. Configurar o servidor Nginx à mão para reencaminhar domínios (api.teunegocio.com, app.teunegocio.com) para as portas internas de cada contentor.
3. Instalar o utilitário Certbot para pedir certificados SSL à Let’s Encrypt e agendar tarefas para os renovar antes de caducarem.
4. Alterar as configurações à pressa sempre que um contentor reinicia e ganha um endereço IP interno diferente.

O CapRover elimina esta carga de trabalho manual utilizando as capacidades nativas do Docker Swarm Mode.

ARQUITETURA DE REDE E TRÁFEGO DO CAPROVER Tráfego da Internet (HTTPS :443) Router Principal de Entrada (Nginx OpenResty do CapRover) Trata a segurança SSL com certificados Let’s Encrypt automáticos Reencaminha pedidos consoante o domínio (ex: api.teudominio.com) Rede Interna em Malha (captain-overlay-network)

• srv-captain–api: Backend em Node / Go • Réplicas: 2 contentores
• Réplicas: 2 contentores
• srv-captain–frontend: Aplicação em Astro • Volume Persistente no NVMe
• srv-captain–postgres: Base de Dados PostgreSQL

Vê a estrutura com clareza:

• Docker Swarm: Cria uma rede interna privada (captain-overlay-network) onde os teus contentores comunicam entre si apenas através dos respetivos nomes de serviço, sem precisares de expor portas internas à internet.
• Porta de Entrada com Nginx: Funciona como o segurança às portas 80 e 443. Quando crias uma nova aplicação no painel visual, o CapRover escreve as regras do Nginx sozinho, pede o certificado SSL e direciona o tráfego para a tua aplicação em fração de segundo.
• Volumes de Armazenamento Persistentes: Garantem que as tuas bases de dados (PostgreSQL, MariaDB, Redis) guardam os dados reais nas pastas físicas dos discos NVMe do servidor, mantendo as informações seguras mesmo quando o contentor é reiniciado ou atualizado.

Ficas com toda a conveniência de uma cloud moderna sem perderes a soberania sobre o teu servidor Linux.

Deploys sem Paragens e Automatização de Código via Webhooks de Git

Numa aplicação de produção que esteja a faturar e a atender clientes, atualizar uma versão do código nunca pode mandar o site abaixo ou fazer com que alguém perca uma transação de pagamento a meio. Se a cada atualização a aplicação ficar 15 segundos desligada enquanto a nova versão arranca, os clientes deparam-se com erros de servidor.

O CapRover resolve esta questão aplicando o mecanismo de atualização gradual (rolling update) do Docker Swarm:

FLUXO DE ATUALIZAÇÃO SEM INTERRUPÇÕES

• PASSO 1: ESTADO ATUAL EM PRODUÇÃO Nginx → [Contentor Versão 1.0 (Ativo)] (A responder aos utilizadores)
• PASSO 2: O GITHUB ATIVA O WEBHOOK
• GitHub → O CapRover recebe a notificação de novo código
• O CapRover compila a imagem Versão 1.1 no servidor local
• O Docker Swarm arranca o [Contentor Versão 1.1] ao lado da Versão 1.0
• PASSO 3: VERIFICAÇÃO DE SAÚDE O Swarm testa o endereço /health do [Contentor Versão 1.1]
• A aplicação responde com HTTP 200 OK (Pronta para trabalhar!)
• PASSO 4: TROCA TRANQUILA DE TRÁFEGO
• O Nginx passa a entregar os novos visitantes ao [Contentor Versão 1.1]
• O Swarm aguarda que o [Contentor Versão 1.0] termine os pedidos em curso
• O contentor antigo é desligado de forma limpa. Zero erros de ligação!

Como Configurar a Instalação Automática a Partir do Teu Repositório

Podes definir as regras de compilação da tua aplicação criando um pequeno ficheiro chamado captain-definition na raiz do teu projeto:

{
  "schemaVersion": 2,
  "dockerfilePath": "./Dockerfile"
}

Se o teu projeto for uma aplicação estática sem necessidade de compilar imagens personalizadas, podes usar um modelo pré-definido:

{
  "schemaVersion": 2,
  "templateId": "node/20"
}

No teu repositório de código no GitHub, adicionas uma ação simples no ficheiro .github/workflows/deploy.yml:

name: Deploy Automático para o Servidor

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Enviar para o Nó CapRover
        uses: caprover/deploy-from-github@v1.1.2
        with:
          server: 'https://captain.teudominio.com'
          app: 'minha-api-producao'
          token: ${{ secrets.CAPROVER_APP_TOKEN }}

Sempre que a tua equipa junta código novo ao ramo principal (main), o GitHub avisa o teu CapRover. O teu servidor descarrega as alterações, constrói a imagem localmente, valida que não há falhas e substitui a aplicação em produção sem que nenhum utilizador repare na transição.

Se queres focar-te em desenvolver o teu negócio em vez de passares os fins de semana a monitorizar servidores, recorrer a serviços profissionais de Alojamento Gerido dá-te a tranquilidade de teres esta infraestrutura montada e protegida com apoio de especialistas.

Evitar Desastres: Resolver o Enchimento do Disco em /overlay2 e Limitar Logs do Docker

Qualquer pessoa que trabalhe com Docker há algum tempo já viveu o pesadelo da notificação a meio da noite: No space left on device (disco 100% cheio).

Quando entras no servidor com o comando df -h, percebes que a partição principal / está completamente esgotada. O serviço do Docker deixa de conseguir gravar ficheiros de estado, o Nginx não consegue criar ficheiros temporários para entregar imagens e todas as aplicações param de repente.

Quase sempre, este desastre acontece devido a dois comportamentos que vêm por omissão no Docker:

1. Ficheiros de Registo Ilimitados: De fábrica, o Docker guarda tudo o que a tua aplicação escreve no terminal (stdout e stderr) em ficheiros JSON na pasta /var/lib/docker/containers/ sem qualquer limite de tamanho. Uma aplicação com uma pequena anomalia que escreva linhas repetidas consegue gerar 50GB de texto em poucas semanas.
2. Camadas de Imagens Órfãs em /overlay2: A cada nova versão que compilas, o Docker guarda camadas intermediárias de ficheiros no disco. Se não limpares o sistema com frequência, essas camadas antigas nunca são apagadas.

O PERIGO DO DISCO ESGOTADO NO DOCKER

• SERVIDOR COM DEFINIÇÕES PADRÃO (SEM MANUTENÇÃO):
• Código e Bases (10G) — Registos / Logs (45G) — Imagens Órfãs no /overlay2 → 100% DISCO CHEIO!
• (O servidor bloqueia por completo • As bases de dados arriscam corromper-se)
• SERVIDOR PROTEGIDO E LIMPO:
• Código e Bases (10G) — Logs Travados (30MB) — Limpeza Semanal Automática → 85% DISCO LIVRE!

1. Limitar os Registos em /etc/docker/daemon.json

Precisas de obrigar o Docker a rodar e limitar o tamanho dos ficheiros de registo de todos os contentores. Cria ou edita o ficheiro /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "storage-driver": "overlay2"
}

Esta regra simples impede que qualquer contentor gaste mais do que 30MB em ficheiros de registo (três ficheiros de 10MB no máximo). Quando o limite é atingido, o Docker descarta as linhas mais antigas sozinho.

Reinicia o serviço para ativares a nova política:

sudo systemctl daemon-reload
sudo systemctl restart docker

2. Agendar a Limpeza Automática do Sistema

Não fiques dependente da memória humana para fazeres limpezas periódicas. Cria uma tarefa no agendador de tarefas do sistema (cron) para remover imagens órfãs e camadas antigas todas as semanas:

# Abre o agendador de tarefas do utilizador root
sudo crontab -e

# Adiciona esta limpeza semanal todos os domingos às 03:00 da manhã:
0 3 * * 0 /usr/bin/docker system prune -af --volumes=false >> /var/log/docker-prune.log 2>&1

A opção --volumes=false é fundamental: garante que as pastas onde guardas os dados reais das tuas bases de dados nunca são tocadas, enquanto apaga dezenas de gigabytes de imagens antigas e restos de compilações que já não estão a ser usados.

Escalar de um VPS Único para Clusters Swarm em Servidores Dedicados

Uma das maiores forças do CapRover é não te prender a uma única máquina. Por funcionar com base no Docker Swarm nativo, passar de uma máquina virtual modesta para um conjunto de servidores dedicados em centros de dados diferentes não te obriga a reescrever nenhuma das tuas aplicações.

Quando o volume de acessos ao teu projeto crescer, só precisas de encomendar um novo servidor dedicado e juntá-lo ao teu cluster com um único comando gerado pelo painel:

# No teu novo servidor físico secundário (Nó 2):
docker swarm join --token SWMTKN-1-49nj1... 195.23.45.67:2377

CLUSTER MULTI-NODE CAPROVER EM HARDWARE DEDICADO [Proteção e Distribuição de Tráfego CDN / Cloudflare] HTTPS :443 NÓ PRINCIPAL (Router Nginx + Painel de Controlo Central do CapRover) Servidor Dedicado: AMD EPYC com 128GB de RAM

• Rede Interna Encriptada via WireGuard: NÓ SECUNDÁRIO 1 (Processamento Web) • Executa: Réplicas de APIs e Aplicações • Escala contentores conforme a procura
• NÓ SECUNDÁRIO 2 (Armazenamento de Dados): Executa: PostgreSQL Principal e Redis • Discos NVMe dedicados em RAID 10

Com esta organização em malha:

• Nó Principal: Trata dos certificados SSL, encaminha os pedidos dos visitantes e gere as tarefas de atualização.
• Nós Secundários de Processamento: Correm as aplicações web (em Astro, Node.js ou Python). Se o número de acessos aumentar, basta aumentares o número de réplicas no painel e o CapRover distribui a carga imediatamente entre as máquinas.
• Nó de Armazenamento: Dedica todo o poder dos discos NVMe e da memória RAM para responder a consultas de bases de dados sem sofrer interferências de outras tarefas.

Consegues toda a resiliência e elasticidade de uma infraestrutura em Kubernetes sem teres de lidar com montanhas de ficheiros YAML incompreensíveis ou pagar pequenas fortunas a empresas de computação na nuvem.

Se queres estruturar a tua infraestrutura com esta clareza e sem gastos excessivos, a nossa Consultoria Técnica apoia a tua equipa em cada passo da instalação, segurança e monitorização contínua.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como especialistas em devops e arquitetura cloud e saas empresarial b2b. Quando alinhas a tua estrutura através de alojamento gerido para websites e aplicações e anti-over-engineering, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.