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?

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.