Table Of Contents
- Hello Reader
- The problem with .env files
- Config servers to the rescue
- More Pros of a Config Server
- 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!
Latest comments (287)
Sometimes, you have to get some difference. For example, when you send automatically an email each month, or depending on any event, you have to run a different setup on dev mode to run tests, to try several emails during the next hour, seeing your email directly on the console. Another example, you could need to call another api on dev mode than on prod...
Perhaps a better title for the article can be ".env file alternatives for enterprise systems". You must understand that not everyone is involved in developing enterprise systems.
I can give another reason to avoid .env files.
.env file (or .env.prod + .env.dev + ...) are predefined files by definition. Literally, an application dictates you what your environments should be.
It is totally Ok, if you can negotiate it with devops guys. But what if they use ephemeral environments with a backend URL like "bugfix-123.example.com" for a short time being?
Would you dynamically generate .env and rebuild docker for that for each branch?
Remember: an application SHOULD BE environment agnostic!
Otherwise it is as weird as a library dictating to a wrapping framework what to do. Management should be directed in opposite direction: from complex to atomic.
Call me when you come up with a solution that doesn't require a couple dozen fetches form an external service per request handled.
If you need to fetch a couple dozen configuration vars on every request, then you have a bigger problem that's beyond my article.
Most real-life problems are "bigger problems".
“It’s time to correct this behavior plaguing the community” - yikes! That’s not the way to start any discussion
I use Kubernetes Config Map.
How do you think?
An amazing git-based resource to control that your secrets are not exposed in the codebase is GitGuardian! With this tool you can also check if there is a secret in the pre-commit event thanks to git hooks.
An amazing git-based resource to control that your secrets are not exposed in the codebase is GitGuardian ! With this tool you can also check if there is a secret in the pre-commit event thanks to git hooks .
Kind of a red herring argument. I've been programming for businesses of all sizes and I never saw anyone storing passwords as plain text in files. If the target audience for your post is the very few misguided souls who are doing that then it's good advice. But for the rest of us the .env file is where we store things that are not secrets, like server names, URLs, numeric values, etc. Very easy to maintain, very easy to access, zero downtime. Can you say the same thing about a config server?
Yes:
Store configs like server names, urls, numeric, and so forth.
Easy to maintain, yes a global config access system with permissions and audit logs.
Easy, access. Some have a UI that you can access with a hierarchy.
Zero downtime? Only if that cloud hoster goes down, in that case your whole app is down.
Bottom line. Yes!
Has it happened? yes
Does it happen? yes
Is the problem having environment files with credentials? no
The problem is always people setting those files up wrong, and not securing them adequately.
That's literally where i was going with my original comment and everyone on here decided i was saying "we should all willy nilly throw env files everywhere! woooo!!!!"
I've got 16 years experience, worked on over 400 different customer sites/applications. Trust me, i've seen plenty of hacked systems, broken systems, badly programmed systems and well frankly there is no system that doesn't have holes, they don't exist. Oh and corporations are the worst, no one takes responsibility for anything and no one knows anything further than the tip of their own nose, which is often why different tools and systems conflict or rules in one place cause something in another place to break. I see that last part damn near every day, so when it comes to the credentials being the problem, that's the problem maybe 0.1% of the time. 90% of the time it's some non-tech person edited something they shouldn't have and broke it. the other 9.9% are the myriad of infinitely complex complications that may or may not happen at any given time. :)