Servidor & DevOps 36 visualizações

Como configurar variáveis de ambiente diferentes pra produção e desenvolvimento

Ver no WHMCS

Como configurar variáveis de ambiente diferentes para produção e desenvolvimento

Oi! Aqui é a Sensei da GeHost 🧘‍♀️ Hoje vou te ensinar um hábito que separa quem só "sobe o site" de quem cuida do site com carinho: usar variáveis de ambiente diferentes para o ambiente de desenvolvimento (onde você testa e quebra as coisas à vontade) e o ambiente de produção (onde estão seus clientes de verdade). Vamos com calma, passo a passo.

O que são "variáveis de ambiente", afinal?

Pensa assim: seu sistema (site, loja, aplicação) precisa de algumas informações para funcionar — senha do banco de dados, chave de uma API de pagamento, endereço de um serviço externo. Em vez de escrever esses valores fixos dentro do código, a gente guarda eles "do lado de fora", em variáveis de ambiente. Assim o mesmo código funciona em lugares diferentes, só trocando essas variáveis.

Por que separar produção e desenvolvimento?

Porque são realidades diferentes! Em desenvolvimento você quer testar sem medo — pode usar um banco de dados de teste, chaves de API em modo "sandbox", mensagens de erro bem detalhadas. Em produção é o contrário: você quer os dados reais, chaves reais, e o mínimo de informação técnica exposta para não dar dica pra quem tenta invadir.

Dica da Sensei: nunca use as mesmas credenciais (senha de banco, chave de API) em desenvolvimento e produção. Se vazar uma chave de teste, o prejuízo é zero. Se vazar a de produção, é dor de cabeça de verdade.

Passo a passo

  1. Crie arquivos separados para cada ambiente. O mais comum é ter dois arquivos, por exemplo .env.development e .env.production (ou simplesmente um .env diferente em cada ambiente). Cada um guarda os valores que fazem sentido para aquele momento — um aponta pro banco de testes, o outro pro banco real.
  2. Nunca deixe esses arquivos públicos ou versionados no Git. Se você usa controle de versão (Git), adicione os arquivos .env* no seu .gitignore. Esses arquivos têm segredos — senha, chave de API — e não devem ir para nenhum repositório, nem público nem privado.
  3. Edite os arquivos com segurança pelo painel. Você pode acessar e editar esses arquivos direto no Gerenciador de Arquivos do seu cPanel (Painel do Cliente → Gerenciador de Arquivos). Localize a pasta do seu projeto, encontre o arquivo correspondente e edite os valores com cuidado, sem apagar o que já está funcionando. Gerenciador de Arquivos do cPanel mostrando a árvore de pastas e a barra de ações
  4. Diga ao sistema qual ambiente carregar. A maioria das aplicações usa uma variável "mestra" (normalmente chamada de NODE_ENV, APP_ENV ou parecida) para saber se está em development ou production e, a partir disso, decidir qual arquivo de configuração usar. Se você não programou o sistema, converse com quem desenvolveu ou consulte a documentação da sua aplicação — cada tecnologia tem seu jeitinho de ler isso.
  5. Teste sempre em desenvolvimento antes. Faça a alteração, teste no ambiente de desenvolvimento, confirme que está tudo certo, e só depois replique a mudança (com os valores corretos!) em produção. Nunca teste "no ar" direto com dados reais de cliente.
  6. Reinicie a aplicação após mudar as variáveis. Na maioria dos casos, alterar o arquivo de variáveis só tem efeito depois que a aplicação é reiniciada. Se o seu plano tiver acesso a um gerenciador de aplicações (como "Setup Node.js App") ou terminal, use-o para reiniciar. Em caso de dúvida, abra um chamado com nosso suporte que a gente te ajuda.
  7. Confira as permissões do arquivo. Arquivos de variáveis de ambiente não devem ficar com permissão de leitura para "todo mundo". No Gerenciador de Arquivos, clique com o botão direito no arquivo, escolha Permissões e mantenha o acesso restrito ao dono do arquivo.

Boas práticas para guardar na memória

  • Um valor de produção nunca deve "vazar" para o ambiente de desenvolvimento, e vice-versa.
  • Segredos (senhas, chaves, tokens) só existem dentro do arquivo de variáveis — nunca escritos direto no código-fonte.
  • Sempre que trocar uma chave sensível (ex: senha de banco de dados), atualize em todos os lugares que a usam e reinicie a aplicação.
  • Guarde uma cópia de segurança dos seus arquivos de configuração em um lugar seguro fora do servidor — se precisar reinstalar algo, você não quer reconfigurar tudo do zero.
Dica da Sensei: se você não tem certeza de como sua aplicação específica lida com variáveis de ambiente, não tem problema nenhum em perguntar pro nosso suporte ou consultar a documentação da tecnologia que você usa. Configuração de ambiente é justamente aquele tipo de coisa que, feita com calma uma vez, evita muita dor de cabeça depois. 🌱
Precisa de Ajuda?

Nossa equipe está pronta para resolver suas dúvidas.