SecretSpec: Declarative Secrets Management

It's a standalone tool with YAML configuration, simple to use.

Basically the way it works:

- You create the secret in GCP/AWS/etc Secrets Manager service, and put the secret data there.

- Refer to the secret by its name in Teller.

- Whenever you run `$ teller run ...` it fetches the data from the remote service, and makes it available to your process.

One key issue is that splitting general config from secrets is practically extremely difficult because once the variables are accessible to a running code base most languages and code bases don't actually have a way differentiate between them internally.

I skipped the hard part of trying to integrate transparently with actual encrypted secret stores. The architecture leaves open the ability to write a new backend, but I have found that for most things, even in production, the more important security boundaries (for my use cases) mean that putting plaintext secrets in a file on disk adds minuscule risk compared to the additional complexity of adding encryption and screwing something up in the implementation. The reason is that most of those secrets can be rotated quickly because there will be bigger things to worry about if they leak from a prod or even a dev system.

The challenge with a standard for something like this is that the devil is always in the details, and I sort of trust the code I wrote because I wrote it. Even then I assume I screwed something up, which is part of why I don't shared it around (the others are because there are still some missing features and architecture cleanup, and I don't want people depending on something I don't fully trust).

There is a reason I put a bunch of warnings at the top of the readme. Other people shouldn't trust it without extensive review.

Glad to see work in the space trying to solve the problem, because a good solution will need lots of community buy-in to build quality and trust.

0. https://github.com/tgbugs/orthauth

Maybe I haven't worked at enough places, but... when has this ever been allowed/encouraged/normalized?

edit: it’s not covered in the post, but it is on the launch and doc site: https://secretspec.dev/providers/onepassword/

          cat > .env << EOF
          DATABASE_URL=${{ secrets.TEST_DATABASE_URL }}
          STRIPE_API_KEY=${{ secrets.STRIPE_TEST_KEY }}
          EOF

[1] https://devenv.sh/blog/2025/07/21/announcing-secretspec-decl...

Realistically, why would your different environments have different ways of consuming secrets from different locations? Yes, you wouldn't use AWS Secrets Manager in your local testing, maybe... but giving each developer control and management of their own secrets, in their own locations, is just begging for trouble. How do you handle sharing of common secrets? How do you handle scenarios where some parts are shared (e.g. a shared api key for a dev third party API) but others aren't (local instance of test db)? How do you make sure that api key that everyone uses in dev is actually rotated from times to times, and nobody has stored it in clear text .env because once they had issues with OnePassword's service being down, and left it at that? How do you make sure that nobody is using an insecure secrets manager (e.g. LastPass)?

It's just adding the risk of having the impression that there is proper secrets management, but actually having a mess of everyone doing whatever they feel like with secrets, with no control over who has access to what, and what secret is used where and by whom and why. Which is kind of like a good ~70% of the point of secrets management.

Centralised secrets management or bust, IMO. Ideally with a secrets scanner checking your code doesn't have a secret in clear text left by mistake/lazyness. Vault/OpenBao isn't that complicated to set up, but if really is, your platform probably has something already.

Disclaimer: I work at HashiCorp, but opinions my own, I've been a part of the team implementing Vault at my past job for centralised secrets management and 100% believe it's the way things should be done to minimise the risk of mishandling secrets.