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
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
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.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
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.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.