🔐 Segredos: a chave nunca viaja no bolso do código

Novo aqui? Um arquivo .env (lê-se "dot env", de "environment", ambiente) é um arquivo de texto simples, que vive só na sua máquina, guardando variáveis de ambiente — pares de nome e valor que a sua automação lê na hora de rodar, sem que esses valores fiquem escritos dentro do código em si. É nesse arquivo que moram as senhas e chaves de acesso que a automação precisa.

Pense num caderno de senhas de papel, daqueles que ficam numa gaveta em casa. Você anota ali a senha do banco, do e-mail, do wi-fi. Faz sentido esse caderno viajar com você pro trabalho? Não — ele fica em casa, só você (e quem mora com você) tem acesso. O .env é exatamente esse caderno: ele mora no seu computador e nunca vai junto quando você manda o código pro repositório (o "cofre compartilhado" onde o código fica guardado e versionado — vimos isso no módulo 4.2, é o GitHub).

Novo aqui? O .gitignore é um arquivo de texto, dentro do seu projeto, com uma lista de nomes de arquivos e pastas que o git (o programa que controla o que sobe pro repositório — módulo 4.2) deve ignorar completamente. Se um arquivo está nessa lista, o git finge que ele não existe: nunca aparece pra ser enviado, mesmo que você digite o comando errado tentando mandar tudo de uma vez.

É o porteiro que fica plantado na porta de casa com a lista de quem não pode sair. Mesmo que você, distraído, tente levar o caderno de senhas junto com a mochila do trabalho, o porteiro barra na porta. O .env deve estar sempre nessa lista — na prática, quase todo projeto novo já vem com essa linha pronta, mas vale a pena conferir.

Legenda: código e chave viajam por caminhos separados. O código passa pelo porteiro e chega ao repositório; a chave nunca passa por ali — você a digita direto no painel da plataforma, e só lá dentro, na nuvem, os dois se encontram de novo.

Não precisa confiar de olhos fechados — dá pra conferir com poucos passos que o seu .env está de fato fora da lista de envio. O objetivo aqui é simples: criar um .env de exemplo, confirmar que ele está listado no .gitignore, e usar um comando do git pra ver, com os próprios olhos, que ele não aparece como algo a ser enviado.

Objetivo: ter um .env com placeholders (nunca uma chave real), protegido pelo .gitignore, e confirmar isso rodando git status.

# conteúdo de exemplo do arquivo .env (na raiz do projeto)
API_KEY=SUA_CHAVE_AQUI
OUTRO_SERVICO_TOKEN=SEU_TOKEN_AQUI

# conteúdo do .gitignore que garante que o .env nunca suba
.env
node_modules/
dist/

# comando para checar o que o git está prestes a enviar
git status

Como verificar: depois de rodar git status, o arquivo .env não deve aparecer em nenhuma lista — nem em "arquivos modificados", nem em "arquivos não rastreados". Se ele aparecer, é sinal de que a linha .env não está no .gitignore (ou está escrita errado) — corrija antes de continuar.

Novo aqui? O Trigger.dev é a plataforma de execução que citamos no módulo 4.2 — o serviço que roda de fato a sua automação na nuvem, 24 horas por dia. Quando sua automação precisa falar com outro serviço (enviar e-mail, ler uma planilha, consultar uma IA), a chave desse serviço não fica no código: ela é cadastrada manualmente, uma vez, dentro do painel do Trigger.dev. Veja o fluxo completo de ponta a ponta:

Assim como o módulo 4.3 mostrou dois "mundos" separados (dev e produção) rodando a mesma automação, as chaves seguem essa mesma separação: o painel do Trigger.dev guarda uma variável de ambiente por ambiente. Isso significa que a chave usada nos seus testes não é obrigatoriamente a mesma usada quando a automação está de fato atendendo usuários reais.

Vazamento acontece — o importante é reagir rápido. Se uma chave real acabou aparecendo onde não devia (um commit por engano, uma mensagem, um print), o passo não é "apagar" o rastro — em muitos casos isso não é suficiente, porque a chave já pode ter sido copiada por alguém ou por algum sistema automático que varre a internet atrás delas. O passo certo é ir até o painel do provedor do serviço e revogar (cancelar) aquela chave, gerando uma nova em seguida.

Com o segredo protegido, o próximo módulo (4.5) trata de outro tipo de risco: o que fazer quando uma etapa da automação falha no meio do caminho — como reagir sem duplicar nada.