> Dedicated configuration files only make sense if you assume a writable file system is there. I disagree. It's pretty typical in containerized environments (i

> Dedicated configuration files only make sense if you assume a writable file system is there. I disagree. It's pretty typical in containerized environments (in my experience) to pass in (eg. mount) a config generated by whatever configuration management system into a container for it to load its configuration from. This has the following advantages over env var configs: - support for more complex expressions than string -> string maps (eg., configuring an IP blocklist) - less chance of mistakes stemming from typos (eg., 'FOO_LODGIR' instead of a 'FOO_LOGDIR' in an environment variable will likely be silently ignored by a service, while a 'lodgir' key in a config file will cause an error in most serious config parsers that I've seen) - working against a schema - if you use something like openapi, json-schema or protobuf/prototext to define your config format, you can use this schema to check/generate the config from other code, and even use it as an automatic source of documentation for the configuration format - hot reloads of configs - once started with env vars, the env vars cannot be (easily) changed, while files can easily be changed (on mutable FS, or from an external source like ConfigMaps/Secrets in k8s), watched and reloaded from, or even used as a signal that the software should restart