Como configurar variáveis secretas (secrets) sem deixá-las expostas no repositório Git

Como configurar variáveis secretas (secrets) sem deixá-las expostas no seu repositório Git

Oi! Aqui é a Sensei da GeHost 🥋 Hoje vou te ensinar algo que separa um projeto seguro de uma dor de cabeça: como guardar senhas, chaves de API e tokens (as famosas secrets) sem deixar elas "vazarem" junto com o código no Git. Vem comigo que é mais simples do que parece!

O que são "secrets" e por que elas são perigosas fora de hora

Secrets são qualquer informação sensível que seu sistema precisa pra funcionar, mas que NINGUÉM de fora deveria ver: senha de banco de dados, chave de API (Stripe, PayPal, e-mail, etc.), token de acesso, string de conexão. O problema é que o Git guarda histórico completo — se você commitar uma secret, ela fica registrada para sempre nos commits antigos, mesmo que você apague o arquivo depois. E se o repositório for público (ou vazar), qualquer pessoa pode pegar essa chave e usar em seu nome.

💡 Dica da Sensei: se uma secret já foi commitada, o problema não é "apagar o arquivo" — é trocar a chave. Depois de exposta, considere ela queimada e gere uma nova no serviço de origem.

Passo a passo: mantendo as secrets fora do Git

1. Crie um arquivo separado só para as configurações sensíveis, geralmente chamado .env. Nele ficam as chaves no formato NOME_DA_VARIAVEL=valor, uma por linha. Esse arquivo NUNCA deve ser enviado ao Git.
2. Adicione esse arquivo ao .gitignore — um arquivo de texto na raiz do projeto que diz ao Git "ignore isso, não acompanhe essas mudanças". Basta ter uma linha assim:
   • .env
   Assim, mesmo que você rode git add ., o arquivo de secrets fica de fora automaticamente.
3. No código, leia os valores a partir das variáveis de ambiente, nunca escreva a senha "na mão" dentro do código-fonte. A maioria das linguagens/frameworks tem uma forma de ler variáveis de ambiente (ex.: bibliotecas de "dotenv" para carregar o .env localmente).
4. No servidor de produção, configure as mesmas variáveis diretamente no ambiente de hospedagem (não é preciso subir o arquivo .env para lá). Se o seu projeto usa um arquivo de configuração de ambiente dentro do cPanel (por exemplo, ao configurar uma aplicação Node.js), você pode editar e criar esses arquivos de forma segura pelo Gerenciador de Arquivos do painel — e claro, mantendo essa pasta fora da área pública e fora do controle de versão.

Boas práticas extras (recomendadas pela Sensei)

• Crie um arquivo de exemplo, tipo .env.example, com os nomes das variáveis mas sem os valores reais (ex.: API_KEY=). Esse pode ir pro Git tranquilamente — ajuda quem for configurar o projeto a saber o que precisa preencher.
• Nunca cole secrets em issues, prints, chats ou tickets de suporte. Se precisar mostrar um erro, apague/oculte o valor da chave antes.
• Revise antes de commitar. Um "olhar rápido" no que vai ser enviado (git status / git diff) evita que um arquivo sensível suba por descuido.
• Use permissões restritas nos arquivos de configuração no servidor, para que só o próprio usuário/aplicação consiga ler.

Já commitei uma secret sem querer, e agora?

1. Troque a chave/senha imediatamente no serviço de origem (banco de dados, provedor de e-mail, gateway de pagamento etc.) — considere a antiga comprometida.
2. Remova o arquivo do repositório e adicione ao .gitignore para não repetir o erro.
3. Se o repositório for privado e o vazamento foi só interno, ainda assim é mais seguro trocar a chave do que confiar que ninguém viu.
4. Ficou em dúvida de como reorganizar isso no seu ambiente de hospedagem? Abra um chamado pelo painel.gehost.com.br que a equipe te orienta.

🌱 Resumindo: secret fica separada do código, o .gitignore é seu escudo, e as configurações de verdade moram só no ambiente (local e produção) — nunca dentro do histórico do Git. Seguindo esses passos, seu projeto fica muito mais seguro!