Stop Putting Secrets in .env Files
20 points by gaffneyc
20 points by gaffneyc
I hate that I'm responding to an LLM, but these sorts of secrets shouldn't be on your machine if possible. If you have 1Password on your computer you will inevitably have it set to stay unlocked for as long as possible, because unlocking your password store is annoying.
Yes, the slop is stupid. It'd be polite if they'd put "© Jonathan Hoyt 2026 — built by hand with an LLM" at the top instead of the bottom, because I'm tired of reading things that people can't even be bothered to write.
And you're not going far enough. Nobody's hosting their app on their computer with 1password on it. They're using a server somewhere. Whether that's on a shelf in a room next to their computer, a VPS in a datacenter somewhere, or something a little different than that, nobody is hosting an app on their computer for others to use. So then, since startup needs to be automatic, whatever secret storage thing they use on that server is going to unlock based on the account auth'd to the server that's connecting to start the app. And that'll reduce down to (hopefully, on the best-case path) an ssh key.
All you're gaining here is the possibility that exposure of your .env file is not a "key rotating" kind of event. It still reduces down to the security of your connection to the server. But you're trading it for some secret storage service.
I'd argue that it's kind of worse (for a small operation especially), in that detecting a leak of your .env file is simpler than detecting a leak from one of these secrets management services.
unlocking your password store is annoying
Then goodness on modern hardware we have biometric unlock to soothe over the pain of 35 character unlock phrases. In a lot of setups, one can tie 1P Vault to Okta which requires a browser handshake, and then biometrics for Okta Verify, but otherwise still isn't crazy bad
I hear you that one would not want that invocation in front of go test, but I would suspect that if that truly is the pain then the infamous "another level of abstraction" leading to op run -- bash and then run go test at will
A few weeks ago my friend Harrison and I did our yearly Tesla FSD cruise around the Bay Area — seven hours of letting the car drive while we talk about whatever comes to mind. This was the first year we never had to take over the wheel, which meant even more time for conversation.
why would i take security advice from someone with this sort of threat model?
© Jonathan Hoyt 2026 — built
by handwith an LLM
It's right at the bottom of the page. You're being asked to take advice from a stochastic plagiarism machine, not from a person who rode around on a "Tesla FSD cruise".
Is it possible he just built the site with an LLM or used it to edit his post?
The post reads to me like what you'd get if you gave a short prompt about using 1password instead of .env files to an LLM, but I suppose it's possible. In which case I might amend my statement to: You're being given advice from a stochastic plagiarism machine mixed with advice from a person who rode around on a "Tesla FSD cruise."
My point was that sometimes we complain about the "undisclosed coauthor" around here, but this time the coauthor seems to be pretty well disclosed to me. It'd be nicer if they'd disclose at the top of the post than the bottom, though.
Even worse is committing an .envrc. It’s also supposed to be ignored, configurable, but also it executes code, not just values. This was designed as a tool for to help local developers, but some have twisted it into an org-wide file with hacks as workarounds to try & allow some sort of local modifications to the file instead of just providing an example files, or just making it an optional/up to the dev (you sure as heck shouldn’t be checking in your text editor config, just like you shouldn’t this).
.envrc (and by extension direnv) are just terrible solutions for creating environments. You're invoking a recursive set of bash scripts and hoping everything is above board in some projects since that's all it does: run this bash script and source the variables.
It should really be something that can be declarative and have recipes for creating values that aren't invoking arbitrary script with full user privileges.
A slight correction: direnv does not invoke the envrc files recursively, it only uses the first one it finds.
Since he uses 1Password he could now use the "mounted env" file feature: https://developer.1password.com/docs/environments/local-env-file
This use a named pipe file and prompt for auth when the file is accessed (the first time, then there is a cache for some time).
Oh, that's really cool. I wish something like that existed for Bitwarden. A short search revealed that nothing of the sort exists, at least nothing that's maintained.
The author is missing a key point, .envrc already works as a script, you don't need those wrapper scripts, ./with-keychain.sh or ./with-1password.sh
just source the script and have a silly shell scritpt or function that runs a command to translate a secret name to a secret value.
Is 1pass not an enterprise tool? That’s the only place I’ve used it
if you mean "enterprise" like paid, then yes. If you mean "enterprise" like you need a whole IT team to keep the thing alive, then no. https://1password.com/pricing/password-manager gives the different price points for how many people you need to interact with the secrets. Although if you are currently using it at an enterprise shop, it's very likely you get the home version for free and that relationship between the work 1P and your 1P is only financial -- they have no control or visibility into your home credentials