Table Of Content (TOC).
Introduction.
1. Storing The .env File.
2. Updating a secret config.
3. Versioning.
Why .env file?
Securing an...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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
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 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.
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 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.
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.
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 for the points. I couldn't agree anymore.
I see a little polemic unfolding, lol :)
Thank you so much for that 💗🤠
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.
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!
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!
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.
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!
Same for me!
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.
Thanks for sharing. Bookmarked! Docker secrets look interesting, never used it before.
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!
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
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.
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!
This is a great article! Thank you for sharing your knowledge.
While this article eventually has some somewhat interesting content, it is pathetic that the author has chosen to criticize another post in such a childlike manner. The other post did not come at you personally, yet you took it that way. It's sad, honestly. @gregorygaines may be right or he may be wrong, but he has posted an article with good reasoning and points and has been very respectful in his replies. You, however, picked a fight for no reason and are now reminding everyone of their annoying little sibling. Grow up and leave the toxicity behind. One can debate interesting topics and still maintain a demeanor of respect. Good Lord.
What do you mean? The article was so formal and highly professional. Did you ever consider reading it? Or just cowardly assumptions?
I did read it, including the very beginning part, It may have some well-written parts (note where I said 'While this article eventually has some somewhat interesting content'), but it also has a an intro and several parts that sound like a snotty-nosed child said them.
Here is the thing: let's imagine you are having a good dinner at MacDonald, and out of the blue, a guy comes up to your table and tells you: "Stop Eating Tacos, or whatever, Now.". Would you be offended? Probably not. But what if they said it in an insulting, aggressive way? Then you might be offended.
This post is clearly not a personal attack or an assault on the other author. But instead of getting mad at this post, take a moment to appreciate the author's time and effort in writing such a response. This person has written nothing but facts, and it takes guts to write something like this. So kudos to him for having the courage to speak his mind.
1) I can genuinely say I don't think I understand your first paragraph.
2) Sure, it takes some guts to say anything, I suppose. Although, I don't think it takes that much guts to type something on the Internet. That aside, the post would have been great if it had just been to the point, but instead it included a level of toxicity that wasn't necessary to make the point. That is what I commented on. I love sharing ideas and learning new things - I really do, but I can also do without the toxicity that is already so prevalent elsewhere on the Internet. It'd be nice if people as smart as software developers could get rid of the ape mind and just have an academic discussion or debate without taking pot shots that don't add anything.
So that's why so many of google's applications are being taken down 😂 jkjk.
Anyway here are my two cents:
I agree with most of it. And focus on the word "most" of it. Just the part where you make one person responsible of all the secrets and then try that person if a breach (of contract; its implied in an NDA right?) happens. But in any case, forget for a few mins you are dealing with a corporate giant who has literally an army of lawyers in their pocket to fight for them, if it were a startup or a company transitioning from startup to a medium sized company/firm/org, their reputation would've already passed through the shredder by the time they wake up and realize what has happened.
You just need to be bit by a snake to really grasp the intensity of the poison. Maybe you haven't been bitten by that snake yet.
But yes, if we forget the above point that one person is responsible for every secret, your explanation is pretty constructive and there's a lot it leaves to debate over.
A good article indeed.
And hot damn i didn't know a soldier boy has already posted an anti to this article 😂 this community is golden!
We get taken down but at-least we not getting secrets leaked. Sounds like a win in my opinion lol.
Yes. But honestly, think about what I said. The person in charge of secrets at your corporation is afraid of life ruining legal repercussions and that's only because your legal side is so damn strong. A small to medium software house doesn't enjoy the same level of legal assurances.
Like I said, your article opens up discussions of a whole other kind. I can make a podcast on it and you'll see we'll make dozens of episode just exploring the true details behind the scenes. Over the top, .env seems a simple enough issue. The more you delve into its dark depths the more you realize.... It's really just a subjective decision by whoever makes it.
I have no hate against megacorporations. I just know for sure by experience, when you start to discuss "what they do and people should do exactly", these megacorporations are almost always years behind in the most unusal of places. And for your google, this .env can be that if you don't think everyone is criticizing you and look at both the sides of this coin.
Seems like all the better reason why this conversation needed to happen. And it’s a deep topic which is why I opened the door. I admit most people haven’t worked at the scale to notice the issues my article addresses.
No no. My dear good Sir, everyone sane, and I mean roughly 70-80% developers, even the juniors included know this issue. They ask about this shenanigan.
I literally had a trainee who asked me this question about two days ago, and why I was so excited to see your post was that I found yin and yang's of this conversation right in a single thread and gave her these articles to read and better reflect on it herself.
Like her and most others (about 6/7), they chose to stick with .env files but acknowledge the exact issues you gentlemen have laid infront of us.
This means either this thing is so well established that no matter how many better solutions you think of, they won't be enough. OR... the correct implementation of the thing is yet to be seen.
Either way, I agree with you my dude. It's not just criticism. I understand your point of reference, and I understand how you revolve around it. Im just saying that... This is a coin. And it has two very different sides with their own identity. Whether one likes it or not.
But like I said, good article. Many points to ponder over in future. This will be in my shower thoughts I promise you :p
Well put, there isn't one lie in your comment! I completely understand, I guess the rapid back-and-forth and constant insults thrown at me has had me on the defensive and for that I apologize.
I'm glad we had a chance to talk and I wish you much success.
Thanks!
You sir. Are a gem. Keep on rocking!
"all criticism is good criticism if one has the appetite for it". Let's close on this. And bid farewell until we talk again in another one of your posts ^^ /
Exactly!
Definitely a bigger fan of .env, but don't really enjoy either article because I think this is a stupid debate.
IMO do whatever is more efficient for your team. If there is actually a benefit to using the cloud vs .env files then use the cloud.
However, on my "small scale" projects, the time/costs required to implement a config server are not worth it. For me, it is more efficient to use a .env file.
I don't think the debate can be qualified as "stupid." It's a real concern. A major issue is unencrypted secrets in
.env, which happens all the time.Cybercriminals exploit vulnerable instances to get credentials and progress through the different layers. It's a credible scenario.
Encryption does not equal security. Encryption equals obscurity. No matter how you encrypt your data, or where you store it, there must be a master password to decrypt everything. What happens if someone disregards other security measures? A hacker will obtain the master password. This is why passwords should be hashed instead of encrypted (but that is a whole other conversation).
BTW most hacks do not occur through code, they occur through social engineering. (yet another conversion)
What I'm getting at is, .env files are not insecure, it's your instance, server, application, or place of work that is insecure. As a dev, here are some things you should know (study cyber security for more mitigation):
Also, if you are handing your secrets over to a third party, how do you know they won't get hacked? You don't.
I beg to differ. Encryption is a layer of security. Encrypting is not like hiding something somewhere as is, hoping nobody will find it.
Does not mean anything, to me, as it does happen, just subscribe to exploitdb. So you want to take the risk just because another technique seems more popular? It does not look like a solid approach, to me.
Right, you don't. Nobody said it would fix all problems. Still better than unencrypted/hardcoded credentials.
I like how your
Problems With Centralized Config Serversis mainly around it can go down and needs internet. Ufff.Your database can go down, your docker servers can go down. Everything can go down. Should we stop using internet now and go back to DVDs ? Even DVDs can go down.
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".What is the debate here?
There's not really any debate to be had about good security practices. Those are well-known and easy to discover and learn.
The benefits of externalized configs are also understood at this point. They've also found their way into every language ecosystem.
I also think that any points about the scale of an application as it relates to the need for good security practices are weak on their merits. Whether the application has many users or a few, security is orthogonal. An application could be used by a single user to store a million dollars of bitcoin and you can bet that security is a primary consideration.
So what is the debate here?
Usually, it's better to listen and try to understand, rather than to debate.
Exactly. It looks like the other guy is struggling to learn the basics of .env files. He started to act like he was the genius in the room, knew everything, and generalized google's practice, especially for junior devs.
Generalizing Google's practices is not helpful. What works for one company may not work for another. Each company has their own way of doing things, and it's important to respect that.
Actually, judging by your comments Scott he's talking about people like you. If you werent so quick to antagonize you would have noticed lol. You literal first instint is to insult, you are hilarious.
Not one comment you made hasn't been rude. I have never shown any ago and I've made ammends with others who felt that way. Why can't we? Did I hurt you in some way? Insecure? OP's alt account?
I was expecting solid counter arguments. Disappointed what I get is an unnecessarily sharp criticism to the other author and in my opinion, several rather weak points that don’t answer some critical use cases and concerns presented in the other article and its discussion section.
Grow up kid.
Solid rebuttal
The point here is that a
.envfile is in fact a (rudeimentary) database (key-value-store).And as such there are scenarios where the use of a configuration server might be more viable e.g. in terms of security than to use a simple file.
I guess the reason why so many tutorials rely on
.envfiles is because the people writing the tutorials have other needs than Google.Here's my $0.02 on the whole conversation.
Problems of huge enterprises such as Google, may not be the same as problems of another Company. At the end of the day, we are engineers and our job is to find the right solution for a given problem. Solutions that work at Google aren't necessarily the best solutions for a startup. So, IMO whether or not you use a secrets management server should depend on the requirements of your specific project
I personally have trouble believing Gregory's claims that a large number of projects use
.envfiles in Production deployments. Like Gregory, I do not have data to back up my beliefs either; anecdotally, I've been working with production systems for almost 9 years now, worked with a variety of stacks and deployment environments all the way fromindex.phpon Apache on a 5$ DO VPS to many Node/Go microservices on a massive K8s cluster. Save for a few junior devs erroneously committing.envfiles into the source repo, I don't remember anyone ever usingdotenvfor setting environment variables in Production. That said, I don't doubt that there is probably someone out there thinking using.envfiles in a public-facing system is an okay thing to do (in a very small number of cases, it might even be okay); IMO this says more about someone's lack of knowledge on the matter than the merits of a system..envfiles are supposed to represent Environment Variables, on a production system these are supposed to come from the OS/Environment.A big portion of Mahmoud's post is just arguing the point about files... While I agree that files in and of themselves aren't a problem, the post fails to even acknowledge the supposed problems proposed by Greg in his post. I agree with other commenters that a blog post should be more about your content rather than just arguing against someone else's.
Lastly, both authors (Mahmoud and Gregory) come off really defensive and somewhat arrogant. A little humility goes a long way, fellas; you don't have to be right every time, and even if you are right it doesn't hurt to see things from the other person's perspective.
I kind of like both approaches. I tend to use
.envfiles to store application-global settings, or something that I might need to change without having to do any coding - like the maximun attachment size an email can have or how many seconds do the backend can wait before it times out.Now, as for secrets like API keys/tokens, I usually hand this to the server OS - which is Linux 99% of the time. I set the secrets on the
/etc/environmentfile and load it in apache/nginx as needed. For the projects I worked on the past, this combo worked wonderfully, albeit it requires a bit more of handwork in the case that some secret needs to be changed, but it doesn't require any other party knowing those secrets. Its so effective that, if the server with the secrets go down, I don't have to worry - everything will be offline, so the secrets will be the last thing I have to deal with!It's funny to see two grown up people bashing on each others' articles instead of accepting that there are different ways to do stuff and none of them are inherently wrong depending on it's use. Oh the internet.
The response we needed. Thanks!
This is one of the biggest sterile discussions I've read in a ton of time.
I'm surprised that from an interesting discussion this turned out into a fight of egos, with someone saying "I work at Google" and other "Yeah, and what?" Lol.
I agree with your comment. For the last part, never in a discussing have I used my employment at Google as a way to downplay anyone. In-fact, commenters have brought up Google more than I have! They love my job more than me.
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.
+1 for the .env files.
Its practical, company can have total control over it. I am absolutely agains all my company infrastructure secrets to be kept by people i dont know personally, centralised on one place, relying on other company well-being and professionalism.
For one thing to be relieble, it does not have to be modern, complex, cloud based or centralised.
Me personaly - i am sick of "modern", "hype" , "new" ways , which in the end only happen to be backed-up by some big corporation, trying to sell their next service. Only to be more centralised, more complex, usually paid (more expensive, than the good old working technology)
How about an app with a simple database, does it require internet connection to work locally? Also, there is a major issue with privacy that the author didn't point out. Allowing a third party to manage your credentials would be an issue with privacy. Doing it yourself is even better.
I did. I mention multiple third party and self hosted solutions. I’m under the impression you did not read my article as your just shooting free throws in the comments.
Excellent!!! Thanks bro
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
Can you please cite the source from where this statistic is taken? Or is it just based on gut feelings? Can you please stop being rude and posting nonsensical information?
It is tough to take your comment seriously when you make claims without backing them up with sources. If you cannot provide a reference for this information, I must assume it is false. In addition, your tone is very off-putting and makes it difficult for me to take your comment seriously. I suggest you take a more respectful and professional approach in your writing if you want people to take your words seriously.
One statistic is the comments themselves lol. But seriously I’ll get back to this comment soon. I never meant to come off as rude or arrogant, I was trying to get my point across quickly sorry if it came off that way.
And if my comments are nonsensical I don’t know what to tell you. I’ve gotten accolades from many companies and other devs. Maybe give my article another read if that’s your conclusion without emotional prejudice because every interaction I’ve had with you has been negative or insulting. Can we try this interaction again being respectful?
Absolute nonsense.
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?
panoramacharter.ltd
19216811.bid
All of this just because a guy in the internet said that you should not use
.envfiles. People really loves to be right over help othersFucking love this guy. Perfectly executed!
I miss quiet a lot types with the very efficient .env
Quoting the bible, absolute faxx.
Loved this! This hit hard.
Should I have multiple .env files? get your love back in 24 hours
The silver bullet doesn't exist, if it's useful use it, otherwise write a post on dev.to and take it easy :D