- Hello Reader
- The problem with .env files
- Config servers to the rescue
- More Pros of a Config Server
- About the Author
.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 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.
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.
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.
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.
Once you create a secret or config, most of the time you are given a URL like
Let's see how a config server solves all the issues with
With a config server, all the secrets are centralized in one place, encrypted, and can only be accessed by applications and users you approve.
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
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.
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!
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.
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.
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.
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!