We definitely had environment variables before 2012, and . files have been around for decades. Maybe they weren't called .env, but the concept isn't new. I'm go

We definitely had environment variables before 2012, and . files have been around for decades. Maybe they weren't called .env, but the concept isn't new. I'm gobsmacked someone could think they are a recent invention, like we've been deploying software with blunt sticks and some rocks until 2012? Otherwise it's a good article. > Local development environments constantly break when required updates to an .env file aren't proactively communicated, e.g. a new secret required after merging a pull request. Somewhat solved with a .env.example file and code that has sane defaults, but that doesn't get you secrets so certainly that could be handled better. > The inconsistent environment variable syntax between languages and platforms can easily cause issues, e.g. Docker and GitHub require values to be unquoted while Python and Node.js dotenv packages work with quoted or unquoted values. Is that really an issue? It's not like you expect project .envs to be portable. > As .env files are stored in plain-text (not just environment variables in memory), they are at risk of being read by unauthorized users with no audit trail in terms of access and changes made. True, but I think complicating the situation further by making a secrets manager a dependency increases your attack surface, not reduces it.