Env vars are easy and ubiquitous.

1. Bash, Python, C, Java...super easy to access; no libraries needed.

2. They automatically propagate through shell scripts and worker processes.

3. They are also super easy to specify when starting programs, in shell, docker, child process from programming languages, Lambda functions, etc.

4. They can easily exist independently of other env variables on the same system.

5. The model is dead simple. Key-value. Simplicity is a feature.

If you need to specify something complex (e.g. hundreds of tuned timeouts), consider using files or code for the heavy parts and env vars to select parts.

Thanks! I had thought of about 3 of those, but they aren't really wins for most of my deployment environments (and some of the downsides still are major downsides for me; one thing I love about config files is I can provide a readme or schema in the same place to define what all the config params are and what they do).

For #4, what do you mean? If running in a container it's not really an issue, but if I'm loading a couple of different dependencies/apps in the same container, or running without containers, name collisions have always been a concern. Set up a chroot, or start renaming things (i.e., "PORT" conflicts really quickly). Or are you saying supply them in the shell, or...?

> For #4, what do you mean?

I mean that one process can have COLOR=blue and another can have COLOR=red with no conflict.

    PORT=123 COLOR=blue ./myapp
    PORT=456 COLOR=red ./myapp

Yes you can chroot, run in containers, use only relative file paths, etc.

There aren't any irremovable differences between env vars and files; env vars are basically /proc/ files with widespread runtime support.

Env vars are universally supported, globally available, and simple to manage. Files mean yet another deployment artifact that has to be stored somewhere, and now tied to a location.

Sometimes that location is communicated through an env var, and that point why not just set all config that way?

If you have something like k8s it becomes trivial to use files vs end vars.

How so? You still have to edit the file, save it somewhere, then mount it as a volume and agree on a location.

The configuration file can be inline in the yaml, ConfigMaps take care of shuffling bytes around for you, and for a specific app it's config can always be at a fixed path.

As long as your (production) config files are not checked in with the code, then little difference. The challenge then is: where do you store them?

Environment variables had the early upside of being first class in any virtually any deployment strategy - from Bash wrappers, supervisord to Docker and Kubernetes - so it's pretty much plug and play. For example, Docker has config files, but they're mounted to a specific place in your container, so that means your application is now married to that location.