Does dotenv contradict the Twelve-Factor App?

Question

I have read about the Twelve Factor App's Config - Section III and searched for a way to do it in NodeJS. It seems that most people recommend dotenv to store configs in environment variables.

However, it seems that dotenv contradicts the Twelve-Factor App, as states:

Another approach to config is the use of config files which are not checked into revision control, such as config/database.yml in Rails. This is a huge improvement over using constants which are checked into the code repo, but still has weaknesses: it’s easy to mistakenly check in a config file to the repo; there is a tendency for config files to be scattered about in different places and different formats, making it hard to see and manage all the config in one place. Further, these formats tend to be language- or framework-specific.

The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

Making sense of this statement, it seems that using dotenv, you will create a config file .env which will then export them as environment variables.

Wouldn't this violate the Twelve-Factor App, since the .env file can get accidentally checked into the code repo?

Ial

technical note: .env files do not export env vars in any way, some libraries just let you use a .env file to extend process.env without having to set up a virtual environment or put only-relevant-to-this-app values in your global environment when not working in a container/VM – Sophia

Answer 1

12factor is not violated until somebody actually commits and pushes the .env ;)

The .env file can also be stored outside the repo itself, since a library or app is still has to read the .env file and push the variables into the environment. Depending on your implementation, this can be as simple as changing the path from ".env" to "../.env".

Using .env files can be a good compromise to allow developers to manage environments easily, but still be compatible with better environment practices during deployment. I might have 30-40 12factor-flavored apps running in a virtual machine, and having to manage each environment separately is daunting without a "shim" like .env.

Fend

Answer 2

The OP asked a well-thought-out question.

I would say the dotenv contradict the 12-factor, section 3, for 2 reasons.

1. By definition, i.e. this paragraph: "Another approach to config is the use of config files which are not checked into revision control, ... still has weaknesses: it’s easy to mistakenly check in a config file to the repo; ... (therefore the 12-factor app uses a different approach as) stores config in environment variables", now you see, just because an .env file could/should be declared inside a .gitignore, does not make dotenv exempt from that "easy to mistakenly check in a config file to the repo" scrutiny.

2. An app could otherwise be fully complied with 12-factor, section 3, if it read config from and only from env var. But a dotenv feature is to allow the app to automatically pickup ./.env if it is available. In that sense, the .env file - despite its deceptive name - IS a config file, through and through. Again, this falls into the config approach category that the 12-factor explicitly avoids.

That being said, dotenv is still one of the viable option. Other options include: managing env vars in docker layer; or in a unix user's .*rc file; or in web server config; or in /etc/profile (quoted from this another SO post). dotenv offers one of the most universal file format (fwiw, docker env_file is equally straightforward although their specs are different), however dotenv is the only solution that "polutes" the target app's code base with one more dependency.

Bottom line, dotenv is fine, it is also funny that many dotenv implementation inherit the claim that it started from the 12-factor app tenet, but only few admits that its .env approach deviates from 12-factor app.

Vermicular

Answer 3

Most version control systems have ways of ignoring certain files.

Git has the .gitignore

SVN has "Special Ignores"

As a side note, these techniques are similarly used to ignore the node_modules directory to avoid needlessly copying files.

Hukill