4 ms·

The Triumph and Tragedy of .env Files

15 points by kiyanwang 5y ago

rogual 5y ago
Why are tech people always "embracing" things? We embrace a lot of things but we particularly enjoy embracing evolutionary shifts, sea changes and modern workflows. The call to embrace a new thing often comes from the people who made the thing. Embrace Doppler. It's not a complicated new dependency to think about. It just wants a hug. Sometimes the request for embracement comes from the community. Embrace Rust. Embrace us. Group hug. It's difficult to say you don't want to embrace something. It's not like saying you don't want to use it. Not wanting to use it is a dispassionate technical decision. Not wanting to embrace it, though; that's very cold of you. Were you not hugged as a child? Why won't you join the embrace?
- scrollaway 5y ago
  Embracing may be a buzzword but it's different from "using". It has the connotation that you don't merely try the thing, you try to fully adhere to its design, follow its ideologies, etc.
- drewcoo 5y ago
  Because we all just want hugs. What? Just me?
- pinephoneguy 5y ago
  Tech people should embrace rejection.
- gjvc 5y ago
  because people are suckers for the new thing, but new does not always mean improved.
- thatjoeoverthr 5y ago
  “You cannot hug a child with nuclear arms!”
- ehnto 5y ago
  I think many people in tech are quite ideological about their tooling, with some people being almost sacred about their tooling convictions. I imagine that's why we get a lot of this emotional veneer in tooling discussions from. Sometimes it makes sense, FP versus OOP for example are really core differences in beliefs about what is the "right" way to write software. But then you get the same language and being used for asinine tooling like, which CSS pre-processor is best, or articles like "React Considered Harmful".
- sdoering 5y ago
  Because a significant amount of people are neophiles. The need New stuff. The long for things that pierce the dull known. That are slightly risky. And that promise klout once the neophile embraces it to then talk about it and gain status as someone knowing new stuff. These are the embracers. The first movers. The ones talking the thing up. Pushed by clever marketing the are the voices that make us laggards already having heard the terms and 'code words' so many times, that once it targets the general audience we already by virtue of repetition feel it being around long enough to be trusted. We feel it is people like us use things like these and don't 'fesr' the new anymore. So it crosses the chasm.
AitchEmArsey 5y ago
Literally never seen instructions directing me to use an .env file; seems like a pretty weak straw-man to enable shilling yet another "startup serving other startups" unicorn wannabe.
mnd999 5y ago
Lots about the problems with .env files but they forgot to write about how their product is better. If you’re going to write a blog like this at least give some technical details on how your product solves the problem.
Canada 5y ago
The other problem with them, as opposed to config files that are merely read and loaded into memory, is that the data does get loaded into the process environment. Or at least it does in node. I make a point to revome them from environment where possible after the secret has been used.
ehnto 5y ago
We definitely had environment variables before 2012, and . files have been around for decades. Maybe they weren't called .env, but the concept isn't new. I'm gobsmacked someone could think they are a recent invention, like we've been deploying software with blunt sticks and some rocks until 2012? Otherwise it's a good article. > Local development environments constantly break when required updates to an .env file aren't proactively communicated, e.g. a new secret required after merging a pull request. Somewhat solved with a .env.example file and code that has sane defaults, but that doesn't get you secrets so certainly that could be handled better. > The inconsistent environment variable syntax between languages and platforms can easily cause issues, e.g. Docker and GitHub require values to be unquoted while Python and Node.js dotenv packages work with quoted or unquoted values. Is that really an issue? It's not like you expect project .envs to be portable. > As .env files are stored in plain-text (not just environment variables in memory), they are at risk of being read by unauthorized users with no audit trail in terms of access and changes made. True, but I think complicating the situation further by making a secrets manager a dependency increases your attack surface, not reduces it.
stratosgear 5y ago
Regardless of how eloquently they describe the .envs "problem" I was completely thrown off by their "we're doing it better" conclusion at the end. And with zero explanations on how their service is any better. I left the article questioning myself the validity of their previous claims, knowing that all along I was reading a self promotion piece. Left a sour taste in my mouth. A disclaimer at the top would have been the proper thing to do... [edit]: horrible phone autocorrections
- D13Fd 5y ago
  Exactly. This is an ad. I actually agree that .env files are very bad, if only for the simple reason that it’s always bad to have secret information sitting unencrypted on a disk. But I was expecting a suggestion to fix this, not an ad (with next to no description of what their product does, even)
rektide 5y ago
> The human element in manually managing .env files across environments and different cloud providers can easily lead to typos and misconfiguration errors, posing a risk to production stability. I doubt your other or any other system is going to be immune to operator error. How are env files particularly bad? > Local development environments constantly break when required updates to an .env file aren't proactively communicated, e.g. a new secret required after merging a pull request. I like having a config.js file that also does some self validation. Another major win for maintenance is to have two .env files- a user .env and a .env-defaults, which load in that order. Basic config can all go into the .env-defaults and get checked in, then if the developer is doing any customization, they have their own .env to do it in. It's made maintaining .env files not a problem for us. As for the security & sharing problems, these are real enough.

15 points by kiyanwang 5y ago

Why are tech people always "embracing" things? We embrace a lot of things but we particularly enjoy embracing evolutionary shifts, sea changes and modern workflows. The call to embrace a new thing often comes from the people who made the thing. Embrace Doppler. It's not a complicated new dependency to think about. It just wants a hug. Sometimes the request for embracement comes from the community. Embrace Rust. Embrace us. Group hug. It's difficult to say you don't want to embrace something. It's not like saying you don't want to use it. Not wanting to use it is a dispassionate technical decision. Not wanting to embrace it, though; that's very cold of you. Were you not hugged as a child? Why won't you join the embrace?

scrollaway 5y ago
Embracing may be a buzzword but it's different from "using". It has the connotation that you don't merely try the thing, you try to fully adhere to its design, follow its ideologies, etc.
drewcoo 5y ago
Because we all just want hugs. What? Just me?
pinephoneguy 5y ago
Tech people should embrace rejection.
gjvc 5y ago
because people are suckers for the new thing, but new does not always mean improved.
thatjoeoverthr 5y ago
“You cannot hug a child with nuclear arms!”
ehnto 5y ago
I think many people in tech are quite ideological about their tooling, with some people being almost sacred about their tooling convictions. I imagine that's why we get a lot of this emotional veneer in tooling discussions from. Sometimes it makes sense, FP versus OOP for example are really core differences in beliefs about what is the "right" way to write software. But then you get the same language and being used for asinine tooling like, which CSS pre-processor is best, or articles like "React Considered Harmful".
sdoering 5y ago
Because a significant amount of people are neophiles. The need New stuff. The long for things that pierce the dull known. That are slightly risky. And that promise klout once the neophile embraces it to then talk about it and gain status as someone knowing new stuff. These are the embracers. The first movers. The ones talking the thing up. Pushed by clever marketing the are the voices that make us laggards already having heard the terms and 'code words' so many times, that once it targets the general audience we already by virtue of repetition feel it being around long enough to be trusted. We feel it is people like us use things like these and don't 'fesr' the new anymore. So it crosses the chasm.

AitchEmArsey 5y ago

Literally never seen instructions directing me to use an .env file; seems like a pretty weak straw-man to enable shilling yet another "startup serving other startups" unicorn wannabe.

mnd999 5y ago

Lots about the problems with .env files but they forgot to write about how their product is better. If you’re going to write a blog like this at least give some technical details on how your product solves the problem.

Canada 5y ago

The other problem with them, as opposed to config files that are merely read and loaded into memory, is that the data does get loaded into the process environment. Or at least it does in node. I make a point to revome them from environment where possible after the secret has been used.

ehnto 5y ago

We definitely had environment variables before 2012, and . files have been around for decades. Maybe they weren't called .env, but the concept isn't new. I'm gobsmacked someone could think they are a recent invention, like we've been deploying software with blunt sticks and some rocks until 2012? Otherwise it's a good article. > Local development environments constantly break when required updates to an .env file aren't proactively communicated, e.g. a new secret required after merging a pull request. Somewhat solved with a .env.example file and code that has sane defaults, but that doesn't get you secrets so certainly that could be handled better. > The inconsistent environment variable syntax between languages and platforms can easily cause issues, e.g. Docker and GitHub require values to be unquoted while Python and Node.js dotenv packages work with quoted or unquoted values. Is that really an issue? It's not like you expect project .envs to be portable. > As .env files are stored in plain-text (not just environment variables in memory), they are at risk of being read by unauthorized users with no audit trail in terms of access and changes made. True, but I think complicating the situation further by making a secrets manager a dependency increases your attack surface, not reduces it.

stratosgear 5y ago

Regardless of how eloquently they describe the .envs "problem" I was completely thrown off by their "we're doing it better" conclusion at the end. And with zero explanations on how their service is any better. I left the article questioning myself the validity of their previous claims, knowing that all along I was reading a self promotion piece. Left a sour taste in my mouth. A disclaimer at the top would have been the proper thing to do... [edit]: horrible phone autocorrections

D13Fd 5y ago
Exactly. This is an ad. I actually agree that .env files are very bad, if only for the simple reason that it’s always bad to have secret information sitting unencrypted on a disk. But I was expecting a suggestion to fix this, not an ad (with next to no description of what their product does, even)

rektide 5y ago

> The human element in manually managing .env files across environments and different cloud providers can easily lead to typos and misconfiguration errors, posing a risk to production stability. I doubt your other or any other system is going to be immune to operator error. How are env files particularly bad? > Local development environments constantly break when required updates to an .env file aren't proactively communicated, e.g. a new secret required after merging a pull request. I like having a config.js file that also does some self validation. Another major win for maintenance is to have two .env files- a user .env and a .env-defaults, which load in that order. Basic config can all go into the .env-defaults and get checked in, then if the developer is doing any customization, they have their own .env to do it in. It's made maintaining .env files not a problem for us. As for the security & sharing problems, these are real enough.