Stop Using .env Files Now!

Hello Reader

I've worked on huge enterprise systems and I'm disappointed to see 99% of all JavaScript tutorials tell you to use a .env for production config and secrets which is dumb.

It's time to correct this behavior plaguing the community. Let's explore the problem with .env files and the ultimate solution.

The problem with .env files

1. Storing the .env file

The problem is well... It's a file. You are not supposed to store your "production" file in your repo; where do you put it? Directly in the VM root? What about Docker containers, do you bake your secrets directly in the image? If the image leaks, everyone has access to your secrets.

2. Updating a secret config

What happens if you need to update a database password? Whoever updates the .env will have access to every secret in the file. I don't even have to explain why this is bad. Every time a config has to be updated whoever is updating it can see EVERY secret.

The updater has access to all your secrets

3. Versioning

Let's say you are deploying a new feature that requires updating your config / secret variables, something goes wrong and the application gets rolled back.

Uh-oh does anyone remember the last values we had in the .env? We have no history and the application requires the values we just deleted/overwrote.

Config servers to the rescue

The perfect solution to all these issues is using a config server. A config server is an externalized application for storing configs and secrets. It's considered the central hub for managing secrets across environments.

Multiple cloud services can function as a config server like AWS Parameter Store, Google Secrets Manager, or HashiCorp Vault for my open-source enthusiasts.

Once you create a secret or config, most of the time you are given a URL like https://app.com/config/DB_PASSWORD/v1.

Let's see how a config server solves all the issues with .env files.

Solving: 1. Storage the .env file

With a config server, all the secrets are centralized in one place, encrypted, and can only be accessed by applications and users you approve.

No plain files in sight!

Solving: 2. Updating a secret

With a config server, instead of updating a secret, you create a new version. After creating a new version, you update your secret URL like .../config/DB_PASSWORD/v2 or .../config/DB_PASSWORD/v3.

Adding a new secret version

Solving: 3. Versioning

Like with solution 2, most config servers have automatic versioning. If you need to update a secret, create a new version and update the config URL in the application. If the application gets rolled back, it will automatically use the last config URL you had in place.

This way secrets are protected and your applications can get rolled back with no issues with the previous secrets.

Look at all those secret versions

Final Thoughts

I hope now developers will start using centralized configs for their production services. .env files are unreliable and have no access management, versioning, or safe updates.

I'm not saying .env file don't have a purpose. They can be used for local or development-oriented environments.

What I'm trying to say is don't store valuable secrets in simple files, especially if my data is in your service.

About the Author

I'm Gregory Gaines, a simple software engineer @Google who's trying to write good articles. If you want more content, follow me on Twitter at @GregoryAGaines.

Now go create something great! If you have any questions, hit me up on Twitter (@GregoryAGaines); we can talk about it.

Thanks for reading!