Secure

Environment variables are set by who’s responsible for the deployment environment: by developer on local machines, by SRE/Administrator/DevOps in production. With env you won’t compromise your production credentials even if your code’s leaked to the public. It’s also harder for developers to break something in production, because they simply don’t have access to production credentials.

Messing up with envs in the runtime may also be tricky, as you cannot change environment variables for the parent process in *nix systems.

Universal

Environment variables are everywhere! On GNU/Linux, MacOS, Windows. Every production-ready programming language supports envs out of box.

Easy to use

Env is flat. Basically it’s a key-value pair with string value. So loading envs is easy.

There are some bad things about envs too. Envs are:

Unexpressive

The flip side of the “easy” coin is unexpressiveness. Envs are flat key-value strings. You cannot store the whole config as en env. So you need to read envs in your code and then construct some sort of the final configuration, possible overly complex.

Flat env structure also get you into a grey area of bad variable names. Consider the following YAML config:

cluster:
  host_weight:
    node00.example.com: 0.8
    node01.example.com: 0.8
    node02.example.com: 1.0
    node03.example.com: 0.5
db: 1
user: app
password: my_password

It may translate to the following envs to substitute values in the config above:

CLUSTER_HOST_NODE_00=0.8
CLUSTER_HOST_NODE_01=0.8
CLUSTER_HOST_NODE_02=1.0
CLUSTER_HOST_NODE_03=0.5
CLUSTER_DB=1
CLUSTER_USER=app
CLUSTER_PASSWORD=my_password

So, you still store some kind of configuration file in your app’s version control system (VCS). Usually it’s a module in you programming language (e.g. config.py in Python) with some language-specific data structures and even some logic. Values (at least some of them) are stored as envs with quite awkward names. These configs are much less readable as the YAML above.

Need to be stored somewhere eventually

Envrironment variables are stored somewhere eventually: in your admins repository, orchestration system’s manifest files that also checked in the VCS. So even separated from the app’s code repo, envs are still stored in files that potentially could be accessed by more people than they should.

May break release determinism

If you use config files checked into your app’s repository, your config is also a part of the app’s releases. You can effectively rollback to a stable release whenever needed.

In the case of envs your app’s releases are separated from the configs. Ideally environment variables should be versioned too. Both app’s and config’s releases should be synchornized somehow. Otherwise your release determinism may break, rollback to previous versions with zero downtime may become difficult.

Readable

You don’t write config files as program’s module (e.g. config.py in Python). Instead you use some language-agnostic format for humans like YAML. Then you have both readability and (to some extent) separation code and configs.

You write clean, self-sufficient configs. No more ugly things like:

HOSTNAME = os.environ.get('DB_HOSTNAME', 'db.example.com')

Developers often group config files by deployment enviroment: testing.yaml, development.yaml, production.yaml. Sometimes you cannot reach 100% deploy environments parity. So having all configs at hand may help when fixing a bug.

Part of release

As I said earlier, if a config is checked into app’s repository it a part of app release history. It makes your app releases more deterministic allowing to rollback to earlier releases if necessary with no extra efforts.

There are bad things about files too:

Formats hell

XML, YAML, ini, TOML, JSON, you name it! Probably you don’t have a luxuary of having the only one way to do it in your language. Even in JavaScript JSON is not the only configuration format in use. But in popular general-purpose languages like Python it’s even worse.

In a complex project with legacy components you may find all sorts of configuration file formats. It’s annoying.

Insecure

Junior developers, people on probation period, QAs, admins, maybe even developers from other teams and departments may have access to your app’s secrets when they are in the config files checked into a VCS. That’s a huge security problem, even if your network operation center engineers, admins and devops do a great job isolating production services and networks.