我见过太多团队的密钥管理了。AWS SSM 存着基础设施凭证，1Password 放着团队共享的密钥，Vault 里塞满了服务令牌。每个开发者的机器上，都趴着一个拼凑出来的 .env 文件，内容大同小异，却又谁也不敢保证完全一致。新来的工程师第一天就在问，这个变量从哪儿取，那个密钥在哪个后端。离职的时候，又得照着一张没人完全信任的手工清单，逐项检查权限回收。想从 AWS SSM 迁移到 Vault？那得把每个仓库的配置都翻一遍。
这还不算最糟的。真正麻烦的是，几乎所有现存的密钥管理工具，都默认自己是唯一的后端。可现实是，一个团队往往有三四个。
secretenv 做的事情很简单。它运行任何命令时，把密钥作为环境变量注入进去，而这些密钥来自你团队已经在用的那些后端——不管是一个还是三四个。它自己不存储、不加密、不管理任何密钥，只是个传递者。密钥在运行时获取，注入到子进程里，进程结束就消失。什么也没写到磁盘上。
这听起来像是在说，它只是层油漆。如果墙不结实，油漆也没用。墙就是你的后端。
secretenv 把两件事分开了。第一，一个项目需要哪些密钥——这些用别名写在 secretenv.toml 里，提交到每个仓库。第二，这些别名对应后端里的什么位置——这个写在注册表里，通常放在团队共享的位置。你想知道一个项目需要哪些密钥，看仓库里的 secretenv.toml 就够了。你想知道某个别名在开发环境对应什么，看注册表。
它支持的后端不少。AWS SSM、1Password、Vault、Azure Key Vault、Cloudflare Workers KV、Bitwarden Secrets Manager，还有 Infisical 和 AWS Secrets Manager。每个后端都有自己的认证方式，secretenv 不替你处理认证，它只是在你已经通过认证的前提下，去取那些密钥。
用法也直白。secretenv run – npm start，密钥就会注入到 npm 进程的环境变量里。secretenv run --registry staging – docker compose up，用的是 staging 注册表里的配置。你可以在不同的注册表之间切换，开发、测试、生产，各有一套。
它的设计有个前提，就是你的团队已经有一套密钥后端了，而且这套后端本身是安全的。secretenv 不替代它们，只是让它们变得好用一点。它也不解决密钥轮换、访问控制、审计日志这些问题——那些是后端自己的责任。它解决的是，当你的团队已经在用三四个后端时，如何让开发者不用手工拼凑 .env 文件。
我总觉得，工具的价值在于它不做什么。secretenv 不做 SaaS，不做二次加密，不做锁定，也不做 .env 文件。它只是把密钥从后端搬到进程里，然后消失。这种克制，反倒让它显得可靠。
https://github.com/TechAlchemistX/secretenv
