Docker em produção: boas práticas na sua VPS

Subir um contêiner Docker para testar é fácil. Mantê-lo rodando em produção — sobrevivendo a reinícios, com dados que não se perdem e sem consumir a VPS inteira — exige alguns cuidados. Se você já domina o básico de Docker e Docker Compose, este guia mostra o que muda quando o contêiner precisa ficar de pé "pra valer".

1. Restart policy: contêiner que volta sozinho

Se a VPS reiniciar (update, queda de energia no data center), seus contêineres precisam subir de novo automaticamente. Sem isso, o serviço fica fora do ar até você notar. Sempre defina uma política de reinício:

services:
  app:
    image: minha-imagem:1.2.3
    restart: unless-stopped

unless-stopped é a escolha certa para produção: reinicia sempre, menos quando você parou de propósito.

2. Dados sempre em volumes (nunca dentro do contêiner)

Contêiner é descartável — ao atualizar, ele é recriado, e tudo que estava só nele some. Dados que precisam sobreviver (banco, uploads, configs) vão em volumes:

services:
  db:
    image: postgres:16
    volumes:
      - db_data:/var/lib/postgresql/data
volumes:
  db_data:

Regra de ouro: se doeria perder, está num volume — e o volume entra no seu backup.

3. Fixe as versões das imagens (evite :latest)

:latest parece prático, mas em produção é uma armadilha: um dia a imagem muda, quebra algo, e você não sabe o que mudou. Fixe a versão (postgres:16, nginx:1.27) para deploys reproduzíveis. Você atualiza quando decide, não por acidente.

4. Limite recursos (não deixe um contêiner derrubar a VPS)

Sem limites, um contêiner com vazamento de memória ou pico de uso pode consumir toda a RAM/CPU e derrubar os outros serviços junto. Defina tetos:

services:
  app:
    deploy:
      resources:
        limits:
          memory: 512M

Isso isola o impacto: se um contêiner sair do controle, ele bate no próprio teto em vez de afogar a VPS.

5. Segredos fora do compose

Nunca coloque senhas direto no docker-compose.yml versionado. Use um arquivo .env (fora do Git) ou Docker secrets:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}   # vem do .env

6. Controle os logs (eles crescem)

Logs de contêiner podem encher o disco silenciosamente até a VPS parar. Limite o tamanho:

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

7. HTTPS via proxy reverso

Não exponha cada contêiner direto na internet. Coloque um proxy reverso na frente (Nginx Proxy Manager, Traefik, Caddy) para centralizar o HTTPS e rotear vários apps por um IP. Veja Nginx como proxy reverso.

8. Atualizações previsíveis

Atualizar um serviço em contêiner é limpo:

docker compose pull       # baixa as versões novas fixadas
docker compose up -d      # recria só o que mudou
docker image prune -f     # limpa imagens antigas

Como os dados estão em volumes e as versões são fixas, o processo é seguro e reversível (basta voltar a tag anterior).

Checklist de Docker em produção

• [ ] restart: unless-stopped em todos os serviços
• [ ] Dados persistentes em volumes (e no backup)
• [ ] Imagens com versão fixa, não :latest
• [ ] Limites de memória/CPU por contêiner
• [ ] Segredos em .env/secrets, fora do Git
• [ ] Logs com rotação (max-size)
• [ ] Proxy reverso com HTTPS na frente
• [ ] Firewall só com as portas necessárias abertas

Docker de verdade roda numa VPS com root

Contêineres em produção precisam de root e controle do sistema — só a VPS entrega. A VittHost oferece VPS com root, boa RAM e IP dedicado, no Brasil e no Canadá:

👉 Ver planos de VPS

Vários contêineres num IP só? O próximo passo é o proxy reverso com Nginx.