Módulo 4 — Self-hosting (alternativa à nuvem) 🟢
Objectivo: alojar em servidor próprio (VPS) quando faz sentido — controlo e custo. O momento aha: percebes que sabes escolher onde uma solução vive, conforme o cliente. Resultado: uma app a correr numa VPS gerida por ti.
1. Quando self-host vs Vercel?
| Vercel | Self-host (VPS + Coolify) | |
|---|---|---|
| Arranque | imediato | requer servidor |
| Custo a escalar | sobe | fixo (a VPS) |
| Controlo | médio | total |
| Quando usar | sites/apps front-end | backend pesado, dados sensíveis, soberania |
2. Coolify — a “Vercel que corres na tua VPS”
O Coolify dá uma interface de deploy por cima de uma VPS: ligas o repositório do GitHub e ele faz build + deploy, com SSL.
3. A topologia típica
Internet → nginx (proxy + SSL) → app / base de dados (Docker)Cada projecto pode ter o seu contentor e subdomínio na mesma VPS.
4. Sinais para fazer upgrade da VPS
- RAM > 80% em média → upgrade.
- CPU > 70% sustentado → upgrade.
- Disco > 70% → expandir/migrar.
🔴 Fora do VSCode
Alugar a VPS e a configuração inicial do servidor (acessos, domínio).
✅ Exercícios
- Decisão — para 3 cenários (landing page · app com pagamentos · dados de saúde), justifica Vercel ou self-host.
- Topologia — desenha o caminho de um pedido desde o navegador até à app numa VPS.
- Capacidade — dada uma VPS de 4 GB, estima quantos projectos Supabase aguenta (idle ≈ 300–500 MB cada).
Resultado esperado: uma decisão fundamentada de hospedagem por cenário.
⚠️ Erros comuns
- Self-host por moda — a Vercel chega quase sempre; só vai para VPS quando há razão.
- VPS sem backups — uma falha e perdes tudo.
- Expor serviços sem SSL/firewall — porta aberta = risco.
- Não monitorizar RAM/CPU/disco — descobres o problema tarde demais.
📋 Checklist do módulo
- Decisão Vercel vs VPS justificada
- SSL activo (proxy)
- Backups configurados
- Monitorização de recursos a funcionar