Is module dotenv for development ONLY?

Question

I am looking for a production solution to store ENV_VARIABLE for a Node.js project and have come across dotenv, which is a Node.js module to read a .env and make its variables available in process.env. But I’ve also come across another post which states that dotenv should ONLY be used for development.

Should dotenv only be used for development? If yes, then what is a production solution for env variables?

Answer 1

tl;dr - Yes, dotenv is really recommended for development only, but you can use it for production as well, if you are careful and understand the implications.

To understand why dotenv is recommended fo development only, let's take a look at the things people generally put into their .env files.

The usual suspects people put into their .env files are:

• current execution environment (NODE_ENV)
• Database URLs (POSTGRES_URL, MONGODB_URL etc.)
• AWS credentials
• JWT signing keys
• Various custom configuration options for easy tweaking without affecting source code (ie REQUEST_TIMEOUT, MAX_BODY_SIZE etc.)

As you may see, most of these things contain sensitive information (credentials, passwords etc.). Normally, when actually deploying your application, these values are stored directly in your server's environment and are not part of the source code. The reasoning is that committing sensitive data to a git repository (even if it is private) is highly not recommended because it might eventually leak - either by making the repository public or by accidentally giving access to someone else than intended, or for a myriad of other reasons.

Therefore, these sensitive values are stored directly on the target deployment server where only a handful of people can see them and it is easy to replace them in case of an accidental leak.

On the other hand, .env files are generally not part of the source code and only exist on individual users' machines. The developers will provide their own, unique security keys, passwords and other sensitive information which will most frequently only work on their own machine, so it's unlikely a leak would cause much harm.

Another big reason why it is generally not recommended to commit .env files is that its purpose is to allow individual developers to customise the configuration for their own machine and/or development process. Sharing the same .env file defeats this purpose.

And yet another important reason why this is not recommended is that when doing more complex deployments you will most likely not have only production - you will also have staging, beta, and perhaps even more deployment environments, each with a different level of stability or for different review group. Environment variables are a great way of customising/configuring your application for that specific purpose. However, if you only manage your configuration through a single .env file you are giving up this flexibility, because you only have one single set of these environment variables.

Ok, but I still want to deploy my .env file!

If

• you do not plan on using .env for sensitive data
• do not use .env files as a way to customise the application on a per-developer and/or per-deployment basis

then you need not worry - go ahead, use dotenv on production, if you like!

If you plan on using it for sensitive data storage, then the only "safe" way is to encrypt this file before committing it to git and only decrypting the file on the actual server.

Still, while this approach of managing the production environment might trigger an "Ooooh, nice" reaction even with experienced developers, specifically using dotenv for this purpose would most likely reward you with a "WTF?!", at best, because most skilled developers would expect dotenv to be the place where they can put their own, per-machine configuration for the thing they are working on.