Environment Variables and Secrets

Your code needs API keys, database URLs, and tokens. These must never be committed to your repo. Once a secret is in git history, it is effectively public forever — deleting the line in a later commit does not remove it from history, and bots scrape new public repos for leaked keys within minutes. Two rules carry you a long way:

• Keep secrets in a .env file locally, and make sure .env is in your .gitignore.
• Set the same values as environment variables in your host's dashboard (or via the CLI — the Command-Line Interface, the text-prompt window where you type commands instead of clicking) for production.

# .env  (local only — never commit this)
DATABASE_URL=postgres://localhost:5432/app
STRIPE_SECRET_KEY=sk_test_xxx
SESSION_SECRET=change-me

# Set the production equivalents on the host
wrangler secret put STRIPE_SECRET_KEY
vercel env add STRIPE_SECRET_KEY production

Maintain a committed .env.example listing the names (not values) of every variable, so future-you and the AI both know what the app expects. Note the sk_test_ prefix above — keep your test and live keys clearly distinguishable, and never let a live key sit in a local .env you might paste into a chat. If you ever paste a secret into a chat or commit one by accident, treat it as compromised and rotate it immediately: generate a new key in the provider dashboard, update it everywhere, and revoke the old one. Rotating costs you five minutes; a leaked database URL can cost you everything in the database.