Variáveis de Ambiente e Segredos

Seu código precisa de chaves de API, URLs de banco de dados e tokens. Isso nunca pode ser commitado no seu repositório. Uma vez que um segredo entra no histórico do git, ele é efetivamente público para sempre — apagar a linha em um commit posterior não o remove do histórico, e bots vasculham repositórios públicos novos em busca de chaves vazadas em minutos. Duas regras te levam longe:

• Mantenha os segredos em um arquivo .env local, e garanta que .env esteja no seu .gitignore.
• Configure os mesmos valores como variáveis de ambiente no painel do seu host (ou via CLI — Command-Line Interface, interface de linha de comando, a janela de prompt de texto onde você digita comandos em vez de clicar) para produção.

# .env  (apenas local — nunca faça commit disso)
DATABASE_URL=postgres://localhost:5432/app
STRIPE_SECRET_KEY=sk_test_xxx
SESSION_SECRET=change-me

# Configure os equivalentes de produção no host
wrangler secret put STRIPE_SECRET_KEY
vercel env add STRIPE_SECRET_KEY production

Mantenha um .env.example commitado listando os nomes (não os valores) de cada variável, para que você-do-futuro e a IA saibam o que o app espera. Note o prefixo sk_test_ acima — mantenha suas chaves de teste e de produção claramente distinguíveis, e nunca deixe uma chave de produção parada em um .env local que você poderia colar em um chat sem querer. Se você alguma vez colar um segredo em um chat ou commitar um por acidente, trate-o como comprometido e rotacione-o imediatamente: gere uma nova chave no painel do provedor, atualize-a em todos os lugares, e revogue a antiga. Rotacionar custa cinco minutos; uma URL de banco de dados vazada pode custar tudo o que está no banco.