The whole idea of using environment variables for configuration information is good, but ultimately flawed, and we are way past the point where this should cont

The whole idea of using environment variables for configuration information is good, but ultimately flawed, and we are way past the point where this should continue to be the status quo. Environment variables are great for configuration because: - you can inherit them from a previous application or application(s) - you can override them in each environment you run your app in - you can pass them on to other applications - they are globals that can be loaded by libraries - they're not hardcoded in the code, so easier to change things without rebuilding, easier to reuse in different ways/environments/configurations - the OS has primitives for them - they're simple Environment variables are bad for configuration: - because (by default) when set in application, they are passed on to all future applications/forks/execs - they are often dumped as part of troubleshooting and aren't considered confidential - they can often be viewed by external processes/users - there are restrictions on key names and values and size depending on the platform - typical "dotenv" solution doesn't necessarily handle things like multi-line strings, has no formal specification - no types, schemas What we actually need that environment variables are being used for: - configuration information passed at execution time that can change per environment - loading or passing secret values - development environments - production environments So what would be a good alternative? - an application library ("libconfig") that can load configuration of various types from various sources in various ways - support for configuration types: key-value, file/blob, integer/float - support for confidentiality (require specific function to unseal secret values; in programming languages the intent would be you can't just print a stringified version of the variable without an unseal function) - support for schema (application defines schema, throws exception if value does not match) - support allowing a configuration to be overloaded by different sources/hierarchies - support passing a configuration on to other applications - support tracing, verbose logging - truly cross-platform and cross-language with one specification, behavior for all How would it work? - devs can create a .env file if they want - devs load 'libconfig' into app, use it to load their configuration values during development. library can have default sources, and even set env vars or an object internally, so no code needs to be written to use it - in production, same code causes libconfig to look at cloud-native and other sources for configuration - when debugging, secret confidentiality is maintained, tracing communicates sources of configuration, what was loaded, from where, etc