Como configurar variáveis de ambiente diferentes para staging e produção no mesmo VPS

Oi! Aqui é a Sensei da GeHost 🧘‍♀️ Hoje vou te ensinar uma coisa que separa o "desenvolvedor tranquilo" do "desenvolvedor que apaga incêndio às 2h da manhã": como manter staging (seu ambiente de testes) e produção (o ambiente que o cliente final usa) rodando no mesmo servidor, cada um com suas próprias configurações, sem que um bagunce o outro.

Se você já teve o azar de testar uma funcionalidade nova e, sem querer, ela mexer com o banco de dados real da sua aplicação — este guia é exatamente pra você.

Por que isso importa? Staging e produção quase sempre usam credenciais diferentes (banco de dados, chaves de API, e-mail, pagamento). Se os dois ambientes acidentalmente lerem a mesma variável de ambiente, você corre o risco de testar algo em cima de dados reais. Isolar isso é uma das práticas mais básicas — e mais importantes — de DevOps.

1. Organize as pastas do projeto

Primeiro passo: cada ambiente precisa da sua própria pasta, separada fisicamente no servidor. Por exemplo:

/home/seuusuario/producao/ — aqui fica o código que está no ar, valendo pro público.
/home/seuusuario/staging/ — aqui fica a cópia de testes, isolada.

Cada pasta terá seu próprio código-fonte (pode ser o mesmo repositório, em branches ou cópias diferentes) e, principalmente, seu próprio arquivo de variáveis de ambiente.

2. Use um arquivo `.env` por ambiente

A forma mais comum e segura de guardar variáveis de ambiente é em um arquivo de texto chamado .env, que fica na raiz de cada pasta do projeto. Ele guarda coisas como:

Dados de conexão com o banco de dados;
Chaves de API (pagamento, e-mail, integrações);
Uma variável indicando qual ambiente é aquele, por exemplo APP_ENV=staging ou APP_ENV=production.

Assim, dentro de /producao/.env você tem os dados REAIS, e dentro de /staging/.env você tem dados de TESTE (idealmente um banco de dados separado, só pra staging).

Dica de ouro: nunca, jamais, use as mesmas credenciais de banco de dados nos dois ambientes. Crie um banco separado só pra staging — se algo quebrar durante um teste, o estrago fica isolado ali, longe do seu cliente final.

3. Proteja o arquivo `.env`

Esse arquivo guarda informação sensível, então alguns cuidados são essenciais:

Nunca suba o .env para o controle de versão (Git). Adicione a linha .env no seu arquivo .gitignore logo no início do projeto.
Ajuste a permissão do arquivo para que só o dono consiga ler (normalmente 600), evitando que outros usuários do servidor tenham acesso.
Se precisar compartilhar as variáveis com sua equipe, use um cofre de senhas ou envie por um canal seguro — nunca por e-mail ou chat aberto.

4. Carregue as variáveis certas na aplicação

A maioria das linguagens e frameworks modernos já tem uma biblioteca pronta para ler o arquivo .env (por exemplo, bibliotecas do tipo "dotenv", disponíveis em Node.js, Python, PHP, Ruby, etc.). O segredo é garantir que, ao iniciar a aplicação, ela aponte para o .env da pasta certa — a de staging quando rodar em staging, a de produção quando rodar em produção.

Uma boa prática é fazer sua aplicação ler a variável APP_ENV (ou similar) para se comportar de forma diferente dependendo do ambiente — por exemplo, exibindo um aviso visual de "AMBIENTE DE TESTES" no staging, pra ninguém confundir as telas.

5. Separe também os domínios/subdomínios

Para não misturar tudo na mesma URL, o ideal é ter:

Produção: seudominio.com.br
Staging: staging.seudominio.com.br (um subdomínio, apontando para a pasta de testes)

Assim, cada subdomínio "enxerga" apenas a sua própria pasta e o seu próprio .env, sem chance de cruzamento. A criação de subdomínios e o apontamento de pastas você configura direto no seu painel de hospedagem — se tiver dúvida em algum campo, é só chamar o suporte que a gente te orienta.

6. Se usar um gerenciador de processos (Node.js, Python, etc.)

Quando a aplicação roda como um processo em segundo plano (comum em Node.js, Python ou apps mais robustas), use arquivos de configuração separados para cada ambiente — um para staging e outro para produção — cada um apontando para a pasta e o .env corretos. Isso evita que os dois processos concorram pela mesma porta ou pelas mesmas variáveis.

7. Teste antes de confiar

Depois de configurar tudo, faça um teste simples: acesse o ambiente de staging e confira se ele está realmente lendo as variáveis de teste (por exemplo, exibindo um banco de dados de teste, não o real). Só depois disso considere o ambiente "seguro" para uso do dia a dia.

Checklist rápido da Sensei:

✅ Pastas separadas para staging e produção

✅ Um .env para cada ambiente, com credenciais diferentes

✅ .env fora do Git e com permissão restrita

✅ Subdomínio próprio para staging

✅ Teste feito confirmando que cada ambiente lê os dados certos

Se durante essa configuração você travar em algum ponto — seja criar o subdomínio, ajustar permissões ou organizar as pastas —, é só chamar a gente pelo painel.gehost.com.br. Lembrando que todo serviço entregue pela GeHost já vem com 30 dias de suporte gratuito após a entrega, então aproveita esse período pra tirar qualquer dúvida com a equipe. 💙

Como configurar variáveis de ambiente diferentes para staging e produção no mesmo VPS