> The human element in manually managing .env files across environments and different cloud providers can easily lead to typos and misconfiguration errors, posi

> The human element in manually managing .env files across environments and different cloud providers can easily lead to typos and misconfiguration errors, posing a risk to production stability. I doubt your other or any other system is going to be immune to operator error. How are env files particularly bad? > 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. I like having a config.js file that also does some self validation. Another major win for maintenance is to have two .env files- a user .env and a .env-defaults, which load in that order. Basic config can all go into the .env-defaults and get checked in, then if the developer is doing any customization, they have their own .env to do it in. It's made maintaining .env files not a problem for us. As for the security & sharing problems, these are real enough.