Secrets, Environment Variables, and Repo Hygiene
Configuration belongs to the environment, not the code — and a leaked secret is a security incident, not a style issue.
The rule
Code and configuration are different things. Code goes in the repo. Configuration — anything that varies by environment or grants access — goes in environment variables, never in committed files.
# .env (gitignored — local only)
DATABASE_URL=postgres://localhost:5432/app_dev
API_KEY=sk-local-abc123
SESSION_SECRET=some-long-random-string
// reading config in Node
const port = process.env.PORT ?? 3000;
Commit a .env.example (keys, no values) so teammates know what to configure. Never import config deep in your modules — read it at the entry point and pass it down; that keeps code testable (module 7).
Why leaks are one-way doors
A secret pushed to a public repo is compromised within minutes — bots scan commits for API keys automatically. Even deleting the file in a later commit doesn't help: history keeps it. If a secret leaks: revoke/rotate it immediately, then clean up. Prevention:
.gitignorefrom project day one (node_modules/,.env,dist/, editor dirs)- Pre-commit secret scanners (
gitleaks,git-secrets) as a team guardrail - Prefer short-lived credentials where possible
Recognizing leaks in diffs
Review eyes should catch:
+ const API_KEY = "sk-live-9f8e7d6c5b4a";
Patterns that scream "secret": long random strings, key|token|secret|password in a name, anything prefixed sk-, AKIA (AWS), ghp_ (GitHub), AIza (Google). A "temporary" hardcoded key is permanent — someone will copy that line into production.
Repo hygiene
- README that earns its keep: what it is, how to run it, how to test it, where config lives. The README is your project's first impression and its recovery manual.
- No committed build artifacts (
dist/,node_modules/) — the lockfile is committed (reproducible installs), the build output is not. - Meaningful history: small conventional commits (previous lesson) make
git bisectand review possible. - Lockfiles and dependency changes: a PR that bumps dependencies says why in its description — dependency drift is a security surface (module 9).
Threat model in miniature
Ask of every config value: who can read this, and what happens if they do? A public repo read = the world. A teammate's machine read = one laptop compromise. Design so the worst case is "rotate one key," not "rebuild the account."