Hospedagem de projetos: comparando estático, serverless, containers e VPS

Escolher hospedagem é escolher um modelo de execução, não uma marca. Site estático, função serverless, container gerenciado e servidor virtual têm perfis distintos de custo, latência e trabalho operacional. Este artigo compara os quatro modelos com números de referência e critérios objetivos para decidir e, quando necessário, migrar.

Os quatro modelos de execução

A diferença principal é quem cuida do que. No estático, você entrega arquivos. No serverless, você entrega funções e a plataforma escala. Em containers, você entrega uma imagem e define recursos. Em VPS, você é responsável por sistema operacional, atualizações, firewall, monitoramento e reinício em falha.

Estático não significa simples demais

Sites gerados em build e servidos por CDN entregam a melhor relação entre desempenho, custo e segurança: não há servidor de aplicação para invadir, a latência é baixa em qualquer região e o custo tende a zero em volumes pequenos. Boa parte dos projetos que começa em servidor completo poderia ser estática com algumas funções isoladas para formulários e integrações.

# Exemplo de build de site estático em CI
name: deploy
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "22", cache: "npm" }
      - run: npm ci
      - run: npm run build
      - name: Publicar diretório dist
        run: npx wrangler pages deploy dist --project-name meu-site
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CF_TOKEN }}

Serverless: escala automática e o problema do cold start

Funções serverless sobem sob demanda e escalam sozinhas, o que é ideal para tráfego imprevisível. O preço é a inicialização a frio quando não há instância quente. A magnitude depende do runtime e do tamanho do pacote.

• Reduza o pacote: dependências não usadas custam milissegundos em toda invocação fria.
• Reaproveite conexões fora do handler para evitar reconectar a cada chamada.
• Cuidado com bancos relacionais: muitas funções simultâneas esgotam conexões; use pooler.
• Tarefas longas não combinam com serverless por causa do tempo máximo de execução.

// Cliente criado no escopo do módulo: reaproveitado entre invocações quentes
import { Pool } from "pg";

const pool = new Pool({
  connectionString: process.env["DATABASE_URL"],
  max: 2, // baixo por instância: muitas instâncias somam conexões
});

export async function handler(req: Request) {
  const { rows } = await pool.query("select id, nome from produtos limit 20");
  return Response.json(rows);
}

Containers: previsibilidade sem administrar servidor

Plataformas de container gerenciado ficam no meio do caminho: o processo permanece vivo, o que elimina cold start e permite conexões persistentes e tarefas em segundo plano, enquanto a plataforma cuida de rede, TLS e reinício em falha. É a escolha natural para APIs com tráfego constante, filas e WebSocket.

# Imagem enxuta com build em múltiplos estágios
FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --omit=dev

FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
USER node
EXPOSE 3000
HEALTHCHECK --interval=30s CMD wget -qO- http://localhost:3000/health || exit 1
CMD ["node", "dist/server.js"]

VPS: controle total e responsabilidade total

Um servidor virtual custa pouco e entrega recursos generosos, mas transfere para você a operação: atualizações de segurança, certificados, firewall, backup, monitoramento e recuperação em falha. Faz sentido quando há necessidade de software específico, custo estável em alto tráfego ou exigência de dados em determinada jurisdição.

Custo real: além do preço de tabela

Checklist antes de colocar no ar

1. HTTPS obrigatório com redirecionamento de HTTP e renovação automática de certificado.
2. Variáveis de ambiente na plataforma, nunca no repositório.
3. Endpoint de saúde e alerta quando ele falhar.
4. Backup automático do banco com restauração testada.
5. Log de erro estruturado com identificador de requisição.
6. Domínio próprio configurado e cabeçalhos de segurança básicos habilitados.
7. Limite de gasto ou alerta de orçamento configurado na plataforma.

Quando migrar de modelo

Migre por sintoma, não por moda. Serverless ficando caro em volume alto e constante indica container. Container ocioso a maior parte do dia indica serverless. VPS consumindo suas noites indica plataforma gerenciada. Para reduzir o custo de mudar, mantenha a aplicação sem dependência forte de recursos proprietários: configuração por variáveis de ambiente, armazenamento compatível com S3 e banco padrão de mercado.

Conclusão

Comece pelo modelo mais simples que atende ao requisito: estático quando não há estado, serverless quando o tráfego é irregular, container quando o processo precisa viver, VPS quando o controle compensa a operação. Documente a decisão, monitore custo e latência e reveja quando algum dos dois sair do esperado.

Perguntas frequentes

Fontes consultadas

• MDN — HTTP caching
• Docker Docs — Multi-stage builds
• Cloudflare Docs — Workers