🧘 Variáveis de ambiente: o segredo pra nunca mais misturar teste com "coisa de verdade"
Oi, aluno(a)! Aqui é a Sensei da GeHost 🥋 e hoje vamos falar de um assunto que separa quem programa "no susto" de quem programa com tranquilidade: variáveis de ambiente.
Se você já teve aquele coração na boca de "será que eu configurei o banco de dados errado e mandei um teste pro site que tá no ar?" — este guia é pra você. Vamos aprender, com calma, a manter o ambiente de desenvolvimento (onde você testa e erra à vontade) bem separadinho do ambiente de produção (o site de verdade, que seus clientes acessam).
🌱 O que são variáveis de ambiente, afinal?
Pense nelas como um "cartãozinho de configuração" que o seu site lê antes de funcionar: qual banco de dados usar, qual chave de API chamar, qual endereço de e-mail enviar notificações, se está em modo "teste" ou "modo real", e por aí vai. Em vez de escrever esses dados fixos dentro do código, você guarda num arquivo separado — geralmente chamado .env — e o sistema lê dali.
A grande sacada é: se você tem um .env pra desenvolvimento e outro .env pra produção, cada ambiente usa suas próprias configurações automaticamente, sem risco de um "vazar" pro outro.
💡 Dica da Sensei: nunca guarde senha, chave de API ou dado sensível direto no código-fonte. Se esse código for parar num lugar público (tipo um repositório do GitHub), qualquer pessoa pode ver. O arquivo .env existe justamente pra manter isso separado e protegido.
🪜 Passo a passo pra organizar seus ambientes
1. Acesse o cPanel da sua hospedagem
Entre no seu cPanel com o usuário e senha que você recebeu no e-mail de boas-vindas (ou pelo painel.gehost.com.br, se preferir acessar por lá).
2. Abra o Gerenciador de Arquivos
No painel inicial, procure o grupo "Arquivos" e clique em Gerenciador de Arquivos. É ali que você vai criar e editar os arquivos de configuração do seu projeto.
3. Crie arquivos .env separados por ambiente
Dentro da pasta do seu projeto, crie dois arquivos:
- .env.development — com as configurações que você usa pra testar (banco de teste, chaves de teste etc.)
- .env.production — com as configurações reais, que o site usa quando está no ar pra valer
Se o seu sistema (framework) exigir um nome específico, como só .env, aí a prática mais comum é manter um .env por ambiente — ou seja, você usa um arquivo enquanto testa localmente/no ambiente de dev, e sobe outro (com os dados de produção) só quando o site vai realmente ao ar. Cada framework tem sua própria forma de indicar qual arquivo carregar — se tiver dúvida de como o seu projeto faz isso, é só chamar nosso suporte que a gente te orienta certinho.
4. Preencha cada arquivo com os dados certos daquele ambiente
Um exemplo simples de conteúdo (os nomes das variáveis dependem do seu sistema):
APP_ENV=development DB_HOST=localhost DB_NAME=meusite_dev DB_USER=usuario_dev DB_PASS=senha_dev
E no arquivo de produção, os dados reais correspondentes (banco de produção, chaves reais de pagamento/API etc.).
5. Considere bancos de dados separados por ambiente
Uma boa prática é ter um banco de dados só pra testes e outro só pra produção, assim você evita que um teste malfeito bagunce dados reais de clientes. Você cria e gerencia isso na seção Bancos de Dados MySQL do cPanel.
6. Proteja o arquivo .env
Isso é importante: o arquivo .env não pode ficar acessível publicamente pelo navegador. Algumas dicas:
- Sempre que possível, guarde o .env fora da pasta pública (public_html), numa pasta acima dela.
- Se o seu sistema exigir que o .env fique dentro do public_html, adicione uma regra no .htaccess bloqueando o acesso direto a arquivos que começam com ponto.
- Nunca envie o .env pra repositórios públicos de código.
7. Rodando uma aplicação Node.js? Use a ferramenta própria do cPanel
Se o seu projeto é em Node.js, o cPanel tem uma seção chamada Setup Node.js App, onde dá pra cadastrar as variáveis de ambiente direto pela interface (sem precisar mexer em arquivo .env manualmente). Assim, cada aplicação criada — uma de desenvolvimento e outra de produção — tem seu próprio conjunto de variáveis, isolado uma da outra.
✅ Checklist final da Sensei
- Arquivo(s) de ambiente criados e nomeados de forma clara (dev x produção)
- Dados sensíveis (senhas, chaves) fora do código-fonte
- .env protegido contra acesso público
- Bancos de dados separados por ambiente, se possível
- Conferido que o site de produção está lendo o .env de produção (não o de teste!)
🌸 Dica final: antes de publicar qualquer mudança grande, dá uma olhadinha se você não está sem querer testando "no ambiente de produção". É um erro comum até entre quem já programa há um tempo — reservar 30 segundos pra conferir isso evita muita dor de cabeça depois.
Ficou com alguma dúvida no meio do caminho? Pode chamar o suporte da GeHost pelo painel.gehost.com.br — a gente te ajuda a configurar certinho pro seu projeto. Bons estudos e até a próxima aula! 🥋