Why Environment Variables Matter Every app has secrets: API keys, database URLs, admin passwords.
Hardcoding them in source code is a one-way ticket to leaks.
Even if your repo is private, you never know who forks it or what CI logs expose.
Environment variables are the standard way to keep configuration out of code.
But using them safely requires a few habits that go beyond just .
The Basics: Loading and Accessing In Node.js, you read env vars with .
But you should not access them raw everywhere.
Create a central config module that validates and exposes them.
Fail fast at startup.
If a required variable is missing, crash immediately rather than failing later in a confusing way.
Never Commit .env Files Tools like dotenv load variables from a file for local development.
That file must stay out of version control.
Add to your immediately.
Also add , , etc. if you use them.
Instead of committing the actual values, commit a with placeholder or fake values.
This documents what is needed without exposing anything.
Use a Validation Library Manual checks are fine for small projects, but for anything serious use a schema validator like or .
They give you type coercion, defaults, and clear error messages.
This catches missing vars, wrong types, and allows sensible defaults without scattering calls.
Never Log Secrets It is surprisingly easy to log an env var while debugging.
Make a habit of not logging entirely.
If you must log config, redact sensitive fields.
Also be careful with error messages.
Some libraries include connection strings in thrown errors.
Wrap them to strip credentials.
Use Different Values per Environment Don't reuse the same API key in dev and prod.
A leaked dev key might be less critical, but it is still a foothold.
Separate keys per environment make it easier to rotate or revoke one without affecting others.
Use a naming convention: , , or better, use separate files and CI secrets per environment.
Most platforms (Heroku, Vercel, AWS) have built-in secret management.
Use that instead of shipping env vars in code.
Avoid Defaults That Are Real Secrets A common anti-pattern is setting a default like .
That default is a real secret sitting in your source.
Use an empty string or a placeholder that obviously fails if used.
If you need a default for local dev, use a fake value that is clearly not real, and ensure your code fails loudly if it tries to use it.
Rotate and Restrict Treat secrets as perishable.
If you suspect a leak, rotate the key.
Use short-lived credentials where possible.
Many cloud providers offer temporary tokens via IAM roles or service accounts.
Prefer those over long-lived keys.
Also restrict permissions.
The API key used by your app should only have the minimum scope needed.
If it gets leaked, the blast radius is smaller.
Tools and Practices Summary Use a central config module, not raw everywhere.
Validate required vars at startup.
Keep out of git; commit only .
Use a validation library for type safety and defaults.
Redact secrets in logs and errors.
Separate secrets per environment.
No real secrets as defaults.
Rotate keys and use minimal permissions.
These habits take a little discipline but save you from embarrassing and costly leaks.
Start with the config module and the rule; the rest can follow as your project grows.