Table Of Content (TOC).
- Introduction.
- 1. Storing The .env File.
- 2. Updating a secret config.
- 3. Versioning.
- Why
.envfile? - Securing an .env file?
- Advantages of using an
.envfile. - Problems With Centralized Config Servers.
- Conclusion.
- Bonus For Linux Enjoyers.
๐ Inroduction.
We all know that first impressions are essential. The same goes for the first sentence of an article. In fact, it might be even more critical for an article because the first sentence is what will determine whether or not someone keeps reading.
But, in the case of this article, stating that working with large-scale systems would make you eligible enough to write about the topic is quite funny. This sentence has a psychological effect that makes readers feel like they are stupid and doomed, assuming they are all working on "Hello World" kind of projects.
Needless to say, as a reader, you may start to wonder: "What in the world does he mean when he said he has worked on large-scale systems?" I mean, literally, everyone is doing that nowadays. I don't think it can be used as a unique selling point or anything; nearly everyone has experience working with large-scale enterprise systems.
Even the most junior engineer has likely worked on a system that processes millions of requests/records daily. So what makes working on large-scale systems so unique? What makes you think your experience is worth anything special? You need to show that you have something unique to offer; otherwise, it's just another redundant sentence in your article. But anyway, let's move on.
Let's start by criticizing each point that looks like a problem with .env files when in reality, they are not problems at all but rather misconceptions.
๐ 1. Storing the .env file.
๐ Go To TOC
This section started by:
The problem is well... It's a file.
Well, I don't know about you and which OS you are currently using, but everything in Linux is literally a file. This includes devices, processes, sockets, files, pipes, etc. However, the critical question is: what's wrong with it?
If you think it is not a good idea to make everything in Linux a file, including env vars, then you have to invite Linus for a debate and discuss the drawbacks of this approach. Provide your solution instead.
Additionally, containers are based on Linux cgroups, namespaces, and other components, which means that they are also built around the concept of everything being a file. This makes Linux a very powerful os for running containers, as everything can be easily managed and controlled via files.
Moreover, everything in k8s is also a file, a YAML file. This concept makes k8s extraordinarily flexible and customizable. You can literally configure anything you want, and there are very few restrictions.
As the author is now working at Google, he has the chance to discuss with the brains behind k8s, argue with them about the drawbacks of files, and share his insights with us. We would love to hear his thoughts on this matter!
Besides, the question is: Who is committing an .env file to public repos? Literally, no one with at least two brain cells is willing to commit an env file, as far as I know. Some developers on github, me included, commits only templates of this file to help other understand the env vars used in a particular project. There is a .gitignore file in case you want to ignore that file from being committed; that's the basics, and everyone should be aware of that.
Even if you don't like to include a .gitignore file for each new repo, you can add a new entry in a global ~/.gitignore file, so you don't have to worry about including that file each time when creating a new repo.
Now, you may wonder: well, how to share the .env file with other developers? And the answer goes like this: If you're collaborating with other people on a project, it's essential to keep your .env file private so that only invited collaborators can see it(e.g., create a private repo for the .env file).
๐ 2. Updating a secret config
๐ Go To TOC
I have never had access to updating a database password throughout my years working at companies. This is because there is always someone responsible for managing databases. Having access to update passwords would be a huge responsibility and could potentially lead to security breaches.
So, having someone responsible ensures that passwords are kept up to date and secure. It also means that if there is ever a problem with a password, there is only one person who needs to be contacted to fix it. This system may not be perfect, but it is the best way to protect company data.
All I can get are env names and use them within the app. That's it; Nothing else. This is why having a designated person is so important. Not only does it make life easier for employees, but it also helps keep everyone on the same page, safe, and secure.
๐ 3. Versioning.
๐ Go To TOC
Environment variables are not parts of the app code, so there is no need to version them. I have never used an app that keeps track of password history changes, and I see no reason why this would be necessary. They are just static values and don't change often.
But in any case, if you want to apply versioning to an .env file stored in a private repo, you can release a new version for each value change.
Then the author proceeds to provide a solution to a problem that doesn't exist. What's even funnier is that the solution leads to potential security risks. So basically, let someone else do it for you if you don't want to manage your secrets, not to mention that the party you share with is a centralized place. If it gets compromised, everyone's secrets in the whole damn world will get exposed.
So, everyone would instead have control over their secrets and not depend on third parties, especially in case of sensitive information.
๐ Why .env file?
๐ Go To TOC
We, as developers, use .env files to store environment variables. These files are not meant for use in production and should be removed/ignored from the codebase before deploying it to production. If you have ever worked with containerized apps, you would know that.
The idea of having an .env file in a repo is to have an example or template of the required env vars as a form of documentation that tells which variables are needed for this project. They could have default values, but as we all know, they should never contain plain text credentials. It is like telling other developers that X, Y, and Z are used in this app as env vars. Having an .env template file in a repo sets expectations for other developers and maintains best practices. This would help new developers clone the repo and work with it without any hassle.
The application should then load this template .env and look for other places to override these default values depending on the current environment. This could be a .env.local file on the system, already set system environment variables, or variables from config storage. If you ever used Jenkins or built a DevOps pipeline, you probably encountered that.
We get it; it is not a good idea to use .env files in production because they can contain sensitive information like database passwords, API keys, and other credentials that should not be accessible to others.
However, one thing you can do though is to take additional precautions to keep your .env file or env vars secure and safe.
๐ Securing an .env file?
๐ Go To TOC
An .env file is not secure if it's being used for production purposes. Anyone with access to the machine can view and modify it without permission.
However, you can set permissions for this file. I don't know about you, but you can use the following command to secure your env file:
chmod 0400 .env
Doing so, the .env file can only be read by the owner and no one else. You can use this command in a docker file if you need to copy it into the docker image. But, usually, it is not encouraged to do so. In the case of docker, secrets can be used, which are discussed later in the following sections.
If you have ever worked with laravel, the chances of using the .env file in production are high. And that is ok as long as you keep it secure. The following is a typical security practice used by Laravel developers:
#Disable index view
options -Indexes
#hide a Specific File
<Files .env>
order allow, deny
Deny from all
</Files>
In docker, you can import env variables with docker-compose using the following command:
docker-compose --env-file .env
Or you can specify the env file within the YAML file:
version: "3.8"
services:
frontend:
image: awesome/webapp
env_file:
- .env # path to your .env file
If you want to pass secrets, then you can define a secrets section within the docker-compose.yaml file:
version: "3.8"
services:
frontend:
image: awesome/webapp
secrets:
- server-certificate
secrets:
server-certificate:
file: ./server.cert
If you are building a docker image, you can create an env file to store secrets and mount the file to the container.
PYPI_USER=dev_bro
PYPI_PASS=my_super_duper_secret_token
Now you can load the .env file and give it an id called my_secret. We can use this key in the next step to access the .env file. Then modify your Dockerfile so that it mounts the secrets.
FROM python:3.9-slim-buster
COPY build-script.sh .
RUN --mount=type=secret,id=my_secret . ./build-script.sh
# build-script.sh:
cat /run/secrets/my_secret
Now, you can build and inject the .env file into the container:
export DOCKER_BUILDKIT=1
docker build --progress=plain -t "my_app" --secret id=my_secret,src=.env . --no-cache
Note that these env vars are not logged into the history, so running the following command won't reveal the secrets:
docker history my_app --no-trunc | grep PYPI_PASS
For more info about secrets in docker, you can refer to this piece of docs.
Additionally, if you are using k8s, there are API objects like ConfigMap to store config data and Secrets to store confidential data. Or, you can set env vars within a pod.
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: registry.k8s.io/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
# Define the environment variable
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
# The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
name: special-config
# Specify the key associated with the value
key: special.how
restartPolicy: Never
I have worked on many projects, some of which are open source. In some projects like this one, I used env vars to store my secrets within circleci to publish a new version to PyPi automatically.
Moreover, for security reasons, I have noticed that PyPi has implemented a feature to allow authentication with their servers through using api tokens without the need for passwords anymore. So, now you can store encrypted PyPi credentials within env vars.
If you ever built a pipeline with Azure DevOps, you probably wanted to copy the .env file into the docker image using Copy files task:
steps:
- task: DownloadSecureFile@1
displayName: 'Download secure file'
inputs:
secureFile: .env
- task: CopyFiles@2
displayName: 'Copy Files to: $(System.DefaultWorkingDirectory)'
inputs:
SourceFolder: '$(Agent.TempDirectory)'
Contents: .env
TargetFolder: '$(System.DefaultWorkingDirectory)'
If you are using Jenkins, you can inject env variables using plugins like envinject
So, as you can see, it depends on the type of applications you are dealing with to follow the best practices to securely use an .env file.
๐ Advantages of using an .env file.
๐ Go To TOC
There are so many advantages to using .env files or environment variables, such as:
Ease of management: Having worked on so many backend projects, I find
.envfiles easy to manage because they are self-explanatory and don't require additional documentation.Simplicity:
.envfiles simplify the task of managing different backends because it allows you to configure all the necessary settings for each backend in one place.Debugging and testing: It becomes easier because developers can modify a specific environment for each application.
Sharing:
.envfiles templates like.env.examplecan be added to git repositories, so other developers on the team know what environment variables were used for that project.
๐ Problems With Centralized Config Servers.
๐ Go To TOC
Several potential problems can occur when using a centralized config server for an application. If the server goes offline, the app will not be able to start. If the server updates and renames an environment variable that the app is not expecting, the app may crash on the next restart. Finally, if the app is hosted offline, it will not be able to start without an internet connection to load the env vars from outside.
๐ Conclusion.
๐ Go To TOC
At the end of the day, .env files and environment variables work fine and are simple enough for development purposes, as long as you know how to use these files. However, it is totally up to you to choose the best approach that aligns with your personal preferences, what works best for your particular application or system.
๐ Bonus For Linux Enjoyers.
๐ Go To TOC
On Linux, if you want to print out a specific environment variable, like LOGNAME, of the current process, then run the following command:
strings /proc/$$/environ | grep LOGNAME
And last but not least, remember that everything in Linux is just a file including the command that you have just executed:
cat /usr/bin/strings
Note: This article is not meant to insult anyone by any means; I just wanted to share it with everyone to clarify the situation with .env and give some tips on how to use them.
Have a lovely weekend, folks.
Cover image by Mike Souza, on Flickr.
Oldest comments (119)
Thanks for sharing. Bookmarked! Docker secrets look interesting, never used it before.
When your first 4 paragraphs do nothing but criticize 1 sentence in another post, at least some of your readers will leave without ever getting to whatever technical content your post contains. I read the post you refer to. It was a good read that made good points, and lead to an interesting discussion in the comments.
I clicked on your post because the title implied that it would offer a counterpoint to the other. So I assumed would be just as interesting. But I won't ever know because the attitude of your first 4 paragraphs has sent me away.
It's a bad thing for new readers who stop reading right away, I think, because there is still a counterbalance to the referenced post.
You are correct. The author exaggerated a bit by criticizing this sentence. But I totally agree with him. It is wrong in all 4 directions!
I think that when you say .env should not be used in prod is confusing, because as you said it's totallynormal than docker secrets docker swarm secrets and k8s secres deploy a .env file as a secret with all the secirity needed inside our ontainers.
By saying that manu people can thing that they are doing something wrong when deploy a decret in swarm or k8s and it's not
This is a great article! Thank you for sharing your knowledge.
Excellent rebuttal to a narrow opinion previously shared here.
Recently, I began to use 1Password to store the values I normally hard code in
.envfiles so team members in my organization could more quickly get up and running, I've documented that process hereI donโt know about 1Password. From what I did see, it functions like a vault / centralized configuration utilizing the benefits I mentioned in my article. Iโm proud!!!
I am feeling a sense of irony reading your reply tho. Good job on your solution!
I don't understand what's narrow here lol. I won't talk about how he's contradicting himself
The headline, for starters.
I wonโt deny thereโs valuable content, but the narrative did have an off-putting effect to readers.
FWIW calling your article a narrow opinion is meant to be a constructive point of view. You do bring valid points and reasoning, but I view that .env file as just a tool in the toolbox. You just have to know what makes it the right tool for the job, and there are A BUNCH of situations where the .env file is not the right approach
Solid rebuttal
As a backend developer that had to meddle with the front-end work done in React, I found their use of
dotenvsloppy and basically unacceptable. This is when I created the first version of wj-config. Not only does it do everythingdotenvdoes, but does everythingconfigdoes, and it can be used in the browser or NodeJS without transpiling or anything because I transpiled it to ES modules, something understood in both worlds as-is.So if you asked me which one to use, I'd just say "put
dotenvto rest and move forward with wj-config".Even though I think that you've gone a little bit too hard on the author of the other post I can't shake the feeling that clickbaity posts such as those do more harm than good since they don't elaborate in detail why that approach is lacking.
This is a great rebuttal though and now both sides of the approach can be taken into consideration.
I was sure I sent the first half listing issues and then give solutions? Was I not clear enough? Even then this article doesnโt even counter all the points I made in the original article.
I'll have a thorough read once again in that case, though I'm not for dropping the approach completely. It is a nice discussion, though!
Ayy, thanks for the shout-out! Let me plug my article here.
Stop Using .env Files Now!
Gregory Gaines ใป Sep 19 '22
First let me say I like how your only cons against config servers is that it can go down and it's remote. Wait till you learn about what a database is, you'll probably be using a json file for the rest of your life!
Also what's your obsession with bringing up my file statement? Is the
/usr/bin/strings"file" carrying production data? If not, then I don't have a problem with it.As large as Google's? Lol. Im Jk. Nice burn tho.
Funny enough, internally all secrets / configs must be stored in enterprise stores like HashiCorp Vault or Google KMS.
New people, people who don't know? In-fact, .env files have their own vulnerability listing because of how much it has happened
https://www.acunetix.com/vulnerabilities/web/dotenv-env-file/. So a-lot I assume.One of the benefits of a config server is reproducibility. This won't be an issue. Config servers keep a trail of all configs.
If your database goes down your app can't start. If your hosting platform goes down your app can't start. Anything can go down, doesn't mean it's not viable. You can introduce a cache within your application so it only has to read variables one time.
What if your private repo gets leaked, now everyone has access to all your **** secrets! What is someone downloads the whole repo to their laptop and it gets stolen? Or someones personal laptop has one of these
productionconfigs and someone decides to a take a peek?Just saying with a config server, a stolen laptop means nothing since you have permissions and access management. Someone can't just come along and copy and past a config server.
--
And some points still stands.
โ-
Final note: I should have taken into account that most devs reading probably havenโt operated at the scale to notice the issues my article is addressing. Maybe thatโs one of the major disconnects.
Iโve noticed a lot of I havenโt had these issues therefore it doesnโt exist type replies.
I must side with Gregory here on this one. We at Intel also have to separate secrets and everything.
dotenvdoesn't seem a suitable candidate AT ALL. I removed alldotenvuse from the React projects. wj-config allows me insertion of K8s secrets or config files while maintaining the separation between data source and consumption.Bottom line is: Don't get stuck in the past.
I am curious, what secrets you are keeping in react projects at Intel...
You know, any "secret" the client has is no longer secret to anyone accessing that UI.
The whole story behind wj-config was to make sure it worked in both NodeJS and React. In our particular project yes, we did not have any any secrets in the latter, but we had a URL mess.
A whole lot of time wasted by devops trying to figure out why a deployment is not using the real env var, just to figure out
dotenvis loading some file and shadowing them.Yes I agree,
dotenvis some weird file configuration pretending to be env configuration. That would be pretty good example of how not to use .env file.If you are using a private repository, you can add contributors without sending emails. Just add the GitHub handle to that repo as a collaborator.
Again if you have to edit a file, all the secrets are exposed to the editor.
You hire someone who is responsible for all his/her actions, right?
Commit history?
Why do you need that?
At Google you can be the VP of a project and STILL don't have access to see secrets. Thats just how things work. It's like moving to a safe neighborhood. There's no crime but you still lock your doors.
Wasn't the point of a
.envwas that it goes in the .gitignore?The fact you asked that scares me a little lol. Rotate AWS Secrets, CyberArk Rotate Secrets
As mentioned in his post, you can have a private repository to share the env file with other team members. If someone changes the values of these environment variables, it will be logged into the commit history.
Maybe I'm not being clear enough. No one person SHOULD EVER have access to view any secrets at anytime, unless they are initially adding it (which even then shouldn't be possible but I don't want to increase the scope of this discussion).
It doesn't matter where that .env is. In a repo, the moon, under a volcano, or area-51. The rule above still applies.
I was literally searching for the use case of KMS servers, your points and explaination completely makes sense to me.
One thing, I would like to add:
Both the things have their own use-cases, KMS is better at a scale like Google. .env is better in smaller engineering teams who know what they are doing. Like in my case, one person is responsible to set ENV in production environment. Rest of all, gets only test credentials.
One can move from .env to KMS when project goes so big (people count increases) by Changing all existing secrets.
Well said, still then I'd argue even if you're small scale you should use the best practices.
Fundamentally it's not a matter of scale or not, it's a matter of security.
Even the one person you mention might have a compromised system at any point in future. Better do it now than be sorry later.
I see a little polemic unfolding, lol :)
A practice adopted by Google doesnโt automatically become universally applicable for every project.
At a big tech company it might make sense to reduce security risk by taking layers of precautions. But if itโs just a small personal project, obviously people shouldnโt care too much about setting up a separate config server, or doing credential rotation.
Keeping secrets away from repo is still a common practice. However, the way Gregory presented it just isnโt very helpful. The โI work in Google so I must be right. The audience hasnโt operated at Google scale so they donโt understandโ attitude is simply naive and arrogant.
If I came off as naive or arrogant, I'm sorry I didn't mean to come across that way. The reason I brought up my work experience is to give credibility behind my statements. In fact, people have brought up my Google experience more than I have.
I also did admit to the fact people haven't worked at the huge scale where they experience the problems to makes my article useful and I'v already admitted that myself. Even in my original argument I mention that
.envfiles have their place which people seem to miss.I never said since people haven't worked at Google they don't understand nor have I ever implied that. I only mention scale which you yourself proved in your comment above.
If you need to have to back up your credibility in order to make your point is no good idea. It's basically arguing with authority (you in this case).
Your point should be good independently the speaker is working at google or at some 2 people random startup.
I see it as having a good point and worked in the environment to apply those points. I decided to give a little insight into how I came across those points, not have people take it as a personal attack.
I read a lot of the comments on your article and the common theme seems to be the added dependency. I'm curious about the Google secrets manager now and will give it a spin since I find myself copy & pasting environment variables between environments and two dev machines. The service would allow me to have one central point to manage them (yes, also a single point of failure).
Yes, but only if you need it or it will make development easier.
And wow! someone willing to understand the approach instead of throwing an insult!!
I really can't see why so many people show hate on this approach. This is a good approach for development AND production environments because you have one central point to manage all secrets. I have been using this approach now for a year without being in a big company which is FORCED to do so. I just love how easy it makes every step of development and it removes the possibility where secrets could potentially get leaked. And if you structure all your secrets your life as a developer will become so much easier :)
Thanks for a really good, but misunderstood (?) article! Keep on writing about you experience because I will for sure read them :)
Thank you Tony. Iโll drop more bangers be sure to follow to get notifs.
good
Databases can be hosted locally next to the app and connect to it using Linux socks so essentially you can pull the ethernet cable out and it would work.
Config servers can be hosted on VPCs giving a local host like connection to your application. No internet traversal required.
But if you pulled the Ethernet cable out then how could users connect to your application? Wouldnโt it not be useful at that point? Am I missing something?
You are missing the difference between development environment and production deployment.
You usually run a bunch of services locally on your laptop, while you work on one of them. Your users are not connecting to that.
E.g you could have frontend, backend API, proxy, message broker, db or two, worker services which consume from a queue. And you can be working just on one of these, but you need working setup.
These would need configuration, including secrets shared between services. You don't need to worry about these being secret, because only db or service you can use them for are said services you run locally.
This is what majority of people use .env files for, i.e. keep environment variables for local environment.
Granted, you can have secrets for third party services there, so it's never good idea to commit .env in repo, in case someone adds something actually secret there. Also why it should always be in .dockerignore, so you don't push it to image registry
Your production deployment and configuration are a whole different beast. How you keep your the real secrets depends on your setup. At this stage usually you would separate secrets, and regular env vars and treat them differently. You would not keep your logging level as a secret for example
If one keeps actual production secrets in .env files, that is indeed very very noob move. Then there are things as Laravel which seem to just use .env as some sort of .ini file.
I know the difference between local and production. If you read my article, I say myself
.envvariables are useful for local / development oriented environments and I was specifically talking about production.I knew there was a disconnect! Nice conversation, you seem very passionate.
You are focusing on specific case, i.e. production (or third party access) secrets, as if that's the only use case for .env files, and as if secrets are the only env vars your app needs on production. Are you really going to keep everything in a sealed secret or a vault server of some kind?
To quote you - "What I'm trying to say is don't store valuable secrets in simple files"
Not sure why do you think people do. There is nothing secret or valuable on placeholder password for local development, or most env vars.
Just because I'm focusing on one use-case doesn't mean I'm saying thats the only use-case.
Maybe I'm not being clear? Again, I mention .env are useful for development oriented environments which excludes my points from those environments. Development oriented environments including local.
So with other words, "continue using .env files as usual" i.e. not for keeping production secrets, which you probably don't have access to anyway. Glad we agree, lol
Yeah lol Iโd phrase it as โkeep using .env not for production and only if your using them right as usualโ.
We were going in a big circle. I should have made by target audience clearer which I feel is the biggest issue people have not my article itself.
Nice chat your passionate, glad we could talk!
Offline on-prem self-hosted exists in 2022 btw.
It's a bunch of files
Sure, but adding an unnecessary layer of potential downtime for literally nothing is just stupid.
Reading your comments, you're clearly delusional and I doubt you have any experience. Stop misleading junior-devs.
Lol yโall love taking that files quote. You donโt look at a database and say yea thatโs just files. Itโs a complex storage and retrieval system with permissions and access management like a what?? Drumrollโฆ.. like a config server ๐๐. Your a funny guy ๐คฃ.
Insults with no counter points isnโt very insightful. But maybe since I have no experience like you claim then I probably havenโt learned that it is ๐ค.
Again, I admit most developers have not worked at the scale to experience the problems my article addresses. If Iโm delusion it seem your included in that group.
Plz re-read my article and donโt just free throw. Thanks!
Same for me. i also doubt if he is actually a Google employee or just trolling this platform.
Or maybe I'm just above your level of understanding that just can't comprehend it therefore it feels like trolling lol.
In JK, on a seriously note, I would love if you could give some pointers. Throwing insults isn't interesting. And wow the commenters are more interested in my work than me.
The clickbaity title is enough evidence for trolling.
Nice chat, have a nice day!
I am not quite sure on what you base the assumption that people are using .env files in production. This is why you sort of come up as arrogant. You seem to somehow assume people are clueless.
Your actual deployment secrets would usually come from your, well deployment config, and can come from many places. These can be sealed secrets, gh actions secrets, and the vast majority of devs will not know, or care what and how the production environment does it.
In my experience.env, just as docker-compose are part of your dev setup. There is absolutely nothing secret there. The whole point of having these as env variables, rather than a config file of some sort you read directly, is to replace them later, rotate them and whatnot
It was more of a PSA than a hey you do this assumption. I never claimed anyone did anything so Iโm not sure how I came off as arrogant but Iโll work on it. Also I did not mean to challenge anyoneโs intelligence.
I didnโt mean for anyone to take my article as a personal attack.
It's a big like saying stop using docker compose, is not good for production. Sort of moot since most people know and don't.
Now the funny part is there are many ways to deal with secrets, depending on your deployment, including yes encrypted files you can keep in your repo. And your solution actually will not work, or be redundant in many cases.
As of why you sound arrogant? Well, "I have been driving fast cars on the highway, let me explain to the yokels why pickups suck", lol. Sort of missing the use case.
I think a better comparison is "I've seen 99% of car guys saying you can beat a mustang gt with a pt cruiser and here what to buy to do it" lol. And of-course I see the commenters at the pt cruiser enthusiasts telling me you don't need a new car, just mod your existing one, eventually making it as fast as the gt instead of outright buying the gt.
I put the use case in the first sentences, but i digress. My solution is completely viable, plz re-read if you don't think so because you example has nothing to do with making my solution not viable or redundant. Or can you try connect them better?
Oh boy. The problems you are solving are not problems because people don't use .env files the way you think they do. The world won't end if you know the local postgres container password is "password". So no it does not need encryption, or rotation or whatever the heck, because it's just a placeholder password, for a placeholder db, for placeholder data.
To repeat once more. In vast majority of cases .env is used to manage environment variables for a local container or app, in a development setup. The reason it's shared, or rather an example .env is for people to know what env vars need to be set.
Your production deployment will vary. If you deploy to AWS you will use the AWS secrets manager. If you deploy to GCP you will use the GCP secrets, naturally.
So telling people to not use .env, is rather uninformed as to what people use .env for.
I know .env donโt need those things, Iโm saying they canโt do those thing thatโs why I bought up a config server and heโll out those who might need those things.
And not everyone uses .env files for what they are for which caused the birth of my article. I feel like we are in a circle.
Can we all agree on one thing? That there should definitely be a
.gitignorefile in every repo with atleast this content:From a dev perspective thats the only thing that matters anyways =p
For the sake of argument, not really (though I personally always do, because you don't want your env to be overwritten by the latest pull).
Say you have a frontend repo. If you use any secret stuff in your frontend build, it ends up baked inside your UI, and anybody using your UI can see that "secret" API token you cleverly hid from the repo:D.
If I had a dime for every UI which emits API tokens neatly in every request, but went through the trouble to hide it from every dev but the general public.
If your front requires any secrets - it probably should not.
About which part do you disagree exactly? Putting FE "secrets" (nothing in the FE is ever secret) in a .env doesn't solve the issue of the "secret" getting baked inside the FE during build.
There is no need to hide .env from repo to hide secrets, since they are public
But that's exactly where the risk/problem is... Someone on the team will interpret the .env as something where they can put local secrets (because that's what it is for) and BAM secrets are now leaked into version control and you have a problem. There's no benefit from committing .env to version control so don't do it. If you have FE "secrets" that don't change based on environment, just put them in a json file or return them through a BE api if they should change per environment.
Thank you so much for that ๐๐ค
I work in large enterprise (we're competitors to Google ;) ). Your article makes a lot of great points.
I'm not sure if Google has something similar, but we use AWS Parameter Store to centralize our "env". We have robust permission system that allows only the app to consume the secrets, and certain users to edit the parameters.
In a large enterprise this helps us separate our concerns. Our developers can focus on developing rather than securing an .env file. Our DevOps can focus on secret management. We also frequently rotate values in our "env" which would really annoying to keep all the devs in sync, securely. This central place allows for someone to edit the value Once and All developers now have the latest values.
Additionally, our parameters are fetched at run time vs at build. Meaning we can rotate a value without restarting the services. The services automatically pick up the new values next time it's called.
Unfortunately this method adds a lot of overhead. Unnecessary in small / solo projects. ENV files would probably best. But in enterprise, in large teams, and teams with strict security protocols (separation of concerns) there are alternative solutions that may be better.
Thank you for the points. I couldn't agree anymore.
You two seem like children arguing about technologies, if it is better to use an .env file or to use a centralized configuration server, in the end both have their advantages and disadvantages, neither is better than the other. Don't marry technologies
Actually, I think this was for the best. This was a conversation that needed to happen. I see nothing wrong with stirring the pot now and then if it leads to education or proposing new practices.
That's fine, a normal article that shows the disadvantages of using an .env file and shows an alternative, a centralized configuration server. a normal article that shows the disadvantages of using a centralized configuration server, and advises better to use an .env file. The problem is not that, it is the language that the two use in each of their articles, especially that of this article, absurdly criticizing yours in the first paragraphs. However, you did respond politely, but that's it, why fall into controversy? We are developers, we use technologies, new ones come out every day, but none is better than the previous one, we all use what we think is best and suits to our needs, to the needs of the project, and to our knowledge.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.