10 Things Nobody Tells You About process.env

10 Things Nobody Tells You About process.env I've burned myself on most of these so you don't have to. Here's what I wish someone had told me early on. 1. Keys are case-sensitive on Linux, case-insensitive on Windows process . env . PORT = " 3000 " console . log ( process . env . port ) // undefined on Linux, "3000" on Windows This one got me during a "works on my machine" incident. My Windows dev box ran fine. The Linux CI server crashed because a teammate typed env.port instead of env.PORT . Your CI runs Linux. Your dev box probably runs macOS or Windows. Case-sensitivity differences will bite you. How to handle it : Use a validation layer that throws on missing keys. A simple getEnv("PORT") will catch typos at startup. 2. Values are always strings console . log ( typeof process . env . PORT ) // "string" even if you set PORT=3000 Number(process.env.PORT) can return NaN without throwing. Boolean values like "false" are truthy strings. How to handle it : Always parse. If you use a schema library like CtroEnv, it coerces types and throws on invalid input. 3. process.env is NOT the same as .env This confused me for way too long. process.env is whatever the shell gave the process. A .env file is just a text file dotenv reads to populate process.env . Node doesn't touch .env files on its own. // This won't read .env automatically console . log ( process . env . MY_VAR ) // undefined How to handle it : Call dotenv.config() at entry, or use @ctroenv/node which loads .env files automatically. 4. You can set env vars per-command PORT = 4000 node app.js This sets PORT only for that single process. It doesn't pollute your shell session. Super useful for one-off runs or testing different configurations without editing files. console . log ( process . env . PORT ) // "4000" 5. process.env is mutable at runtime process . env . DATABASE_URL = " postgres://hacker:gotme@evil.com/db " I've seen code that modifies process.env to "fix" config at runtime. Don't do this. If something i