Table Of Contents

• Hello Reader
• The problem with .env files
• Storing the .env file
• Updating a secret config
• Versioning
• Config servers to the rescue
• Solving: Storing the .env file
• Solving: Updating a secret
• Solving: Versioning
• More Pros of a Config Server
• Automatic Secret Rotation
• VPC Endpoints
• Audit Logs
• About the Author

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.

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. Storing 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.

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.

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.

More Pros of a Config Server ✅

Automatic Secret Rotation

Secrets can become stale which can lead to your systems becoming compromised! A centralized config like AWS provides automatic Secret Rotation.

If you team or org all pull the same config, they will automatically get updated with the latest values. No need to send it over slack, no need to get a "trusted" dev, or having the possibility of forgetting to update one of your .env files. Easy and painless!

VPC Endpoints

A config server is usually hosted on a VPC which provides a localhost like connection for your services. This allows the ability to pull secrets without them ever having to touch the internet (virtually no latency), nor allowing outsiders to query the server.

Audit Logs

Did a secret get leaked? Config servers usually carry audit logs so you can check when or where a secret was accessed.

Does an updated config cause an error? Check when it was last updated and if needed, preform a global update for all your services. No plain text file editing needed.

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!