Isolando ambiente de Desenvolvimento e Produção com Docker no seu VPS
Oi! Aqui é a Sensei, e hoje eu quero te ensinar uma prática que separa os "amadores" dos times que dormem tranquilos: nunca testar coisa nova direto onde o cliente de verdade está navegando. 😌
Se você tem um site, uma loja ou um sistema rodando, é quase certeza que, em algum momento, vai precisar testar uma mudança — um novo recurso, uma atualização, um ajuste visual — antes de colocar pro mundo ver. É exatamente aí que entra a separação entre ambiente de desenvolvimento (dev) e ambiente de produção (prod), e o Docker é uma ferramenta ótima pra isso.
Importante antes de começar: este guia vale pra quem tem um VPS próprio (um servidor com acesso de administrador contratado à parte). Se o seu site está na nossa hospedagem compartilhada em cPanel, esse fluxo de Docker não se aplica diretamente ao seu plano — mas não se preocupe: fale com o nosso suporte pelo painel.gehost.com.br que a gente te orienta na melhor forma de organizar teste e produção dentro do que o seu plano oferece.
Por que separar dev e prod?
Pensa assim: seu ambiente de produção é a "vitrine da loja" — é o que o cliente final vê e usa. Já o ambiente de desenvolvimento é o "fundo da loja", onde você mexe, quebra, testa e corrige sem que ninguém de fora perceba. Misturar os dois é como trocar a vitrine enquanto o cliente está comprando — mais cedo ou mais tarde, algo vai dar errado na frente dele.
O Docker ajuda porque ele "empacota" sua aplicação (código + dependências + configurações) dentro de containers isolados. Assim, dá pra ter uma cópia de teste rodando ao lado da versão real, sem uma interferir na outra.
Passo 1 — Organize duas pastas (ou dois arquivos de configuração)
A forma mais simples de começar é manter arquivos separados para cada ambiente, por exemplo:
docker-compose.dev.yml— configuração para testesdocker-compose.prod.yml— configuração para produção
Cada um desses arquivos define os containers, portas e volumes daquele ambiente específico. Assim você nunca corre o risco de "subir sem querer" a configuração errada.
Passo 2 — Use variáveis de ambiente (.env) diferentes
Nunca deixe senhas, chaves de API ou endereços de banco de dados "fixos" dentro do código. Em vez disso, use um arquivo .env próprio para cada ambiente:
.env.dev— com dados de teste (banco de teste, chaves de sandbox, etc.).env.prod— com os dados reais de produção
Dica da Sensei: nunca use os mesmos dados de acesso (senha de banco, chave de pagamento etc.) nos dois ambientes. Se o ambiente de teste vazar ou tiver uma falha, o de produção continua protegido.
Passo 3 — Nunca compartilhe o mesmo banco de dados
Esse é um dos erros mais comuns: usar o banco de dados de produção para "testar rapidinho" no ambiente de desenvolvimento. Um comando errado ali pode apagar ou corromper dados reais de clientes.
Configure um container de banco de dados próprio para o dev (por exemplo, um MySQL ou PostgreSQL rodando isolado, com dados fictícios ou uma cópia antiga), separado do container do banco de produção.
Passo 4 — Use redes (networks) e volumes isolados
No Docker, você pode criar redes internas diferentes para cada ambiente, evitando que um container de teste "converse" acidentalmente com um container de produção. O mesmo vale para volumes (onde ficam os arquivos e dados persistentes): mantenha volumes distintos e nomeados claramente, como volume_dev e volume_prod.
Passo 5 — Use portas diferentes para não confundir
Defina portas separadas para cada ambiente (por exemplo, uma porta para acessar a versão de teste e outra para a versão real). Isso evita aquele susto de abrir o navegador e não saber se está vendo o site de teste ou o site real.
Passo 6 — Sempre teste antes de subir para produção
Antes de aplicar qualquer mudança no ambiente real, rode e valide tudo no ambiente de desenvolvimento primeiro. Só depois de confirmar que está tudo funcionando, replique a mudança (ou suba a nova imagem) no ambiente de produção.
Dica da Sensei: mantenha sempre um backup atualizado do ambiente de produção antes de qualquer atualização. Assim, se algo sair do previsto, dá pra voltar rapidinho pro estado anterior.
Resumindo
- Arquivos de configuração separados para dev e prod
- Variáveis de ambiente (
.env) diferentes, com credenciais distintas - Bancos de dados isolados — nunca testar no banco real
- Redes e volumes próprios para cada ambiente
- Portas diferentes para não misturar o que é teste e o que é real
- Backup sempre antes de qualquer mudança em produção
Se você tiver dúvida na hora de organizar isso no seu VPS, ou quiser uma orientação mais de perto pro seu caso específico, é só chamar a gente pelo painel.gehost.com.br — lembrando que todo serviço contratado já vem com suporte gratuito por 30 dias após a entrega. 🙏
Bora manter a casa organizada — separando teste de realidade, dorme-se muito mais tranquilo! 😊
