Rodando Docker em um VPS econômico

Por que Docker em um VPS pequeno, afinal

O argumento a favor do Docker não tem nada a ver com o tamanho da máquina. Deploys reproduzíveis significam que a imagem testada é, byte a byte, a imagem que roda em produção; rollback é apenas iniciar a tag anterior; e o contêiner que funciona no seu notebook funciona de forma idêntica em produção.

Em um VPS pequeno, essas propriedades importam mais, não menos. Com recursos apertados, você não pode se dar ao luxo de um mistério — depurar no estilo 'na minha máquina funciona' consome exatamente o tempo e a memória que você não tem. Uma imagem, em todo lugar, elimina essa classe de problemas.

A memória é o orçamento

Em um VPS econômico, a RAM é o recurso que acaba primeiro, e o Docker deixará alegremente um contêiner esfomear os demais, a menos que você diga o contrário. Defina um limite de memória explícito em cada contêiner, para que um vazamento vire um serviço reiniciado em vez de um servidor congelado.

Adicione um arquivo de swap modesto como rede de segurança — não para viver dele, mas para sobreviver a picos breves sem que o kernel mate processos ao acaso. E prefira imagens slim ou alpine: uma base menor significa menos memória, downloads mais rápidos e uma superfície de ataque menor.

• Definir limites --memory por contêiner
• Usar imagens base enxutas
• Um processo por contêiner

Compose para a stack inteira

Um único docker-compose.yml descrevendo seu app e o reverse proxy transforma a stack inteira em um arquivo que você pode ler, versionar e reproduzir. Reerguer o servidor do zero passa a ser um único comando, em vez de um ritual lembrado pela metade.

Mantenha o arquivo entediante e explícito: tags de imagem fixadas, políticas de restart, limites de memória. Tudo o que o servidor executa deve estar visível nesse arquivo — se não está no Compose, não existe.

services:
  app:
    image: ghcr.io/you/app:latest
    restart: unless-stopped
    mem_limit: 512m

Mantenha o banco de dados fora do contêiner

Rodar PostgreSQL ou MySQL dentro do Docker em uma máquina pequena é onde os setups econômicos vão morrer. Bancos de dados querem memória estável, armazenamento cuidadoso e backups de verdade — exatamente o que um VPS pequeno, com contêineres disputando RAM, não pode prometer. Um OOM kill no meio de uma escrita e você estará restaurando na base da esperança.

Use um banco de dados gerenciado e deixe o VPS fazer o que faz bem: rodar seu app sem estado. O estado pertence a outro lugar — na Anested Cloud, PostgreSQL, MySQL e MongoDB gerenciados começam de graça, e seus contêineres recebem apenas uma string de conexão.

Atualizações sem drama de indisponibilidade

A rotina de atualização é curta: puxar a nova imagem, reiniciar o serviço e deixar um health check confirmar que o novo contêiner realmente responde antes de você seguir em frente. Se não responder, reiniciar a tag anterior é o seu rollback — segundos, não uma noite inteira.

Antes de mudanças maiores — novas versões major, reescrita do arquivo Compose — tire primeiro um snapshot do VPS. É o seguro mais barato que existe: se a atualização der errado, você restaura a máquina inteira para o momento exato antes de mexer nela.