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 (290)
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. :)
You should use Infisical for that. Solves all the mentioned problems and it is end-to-end encrypted.
whole post is good, but you missed the last step - to show how to use those secrets in code :(
Definitely some good points.
I've seen so many people forget a simple and extremely important security tip:
cycling keys and secrets after an employee has left/no longer works for the company.
Making a process to re-create secrets and keys every so often is important.
⤜(ⱺ ʖ̯ⱺ)⤏
So what's worse: plain text password storage in 2022 or overused secrets and keys?
Add to the discussion
First of all: This is really good advice! And I find it good when Googlers take the opportunity to help spreading good practises.
But ...
it is muddied behind bad communication skills.
I think if you dial down the paternalistic tone a bit it would not make you sound like you are selling snake oil.
There are simple scenarios where a .env file may be okay and a centralized solution might be a bit over the top. And there are many scenarios where this may be the appropriate solution but people do not use it for whatever reason.
If your intention is really to help people you may want to hold back a bit of your ego which may turn people off from evaluating your idea and instead evaluate you. That is countrary to your intention.
Thanks for the criticism, a lot of people took this as a personal attack which was not my intention.