[CharlesW]

From a project perspective, is this for fun or is it meant to be a production solution? If the latter, what problem(s) are you trying to solve that established solutions like fnox don't? https://github.com/jdx/fnox (I'm an fnox user who's unfamiliar with this space, and am curious what your critiques would be.)

[babawere]

Both, honestly. Fun and production intent. But `production` here is very specific, embedded in a single Go binary, a single *.db not a CLI tool (the cli you see there is just for inspection) for developer or CI.

The problem fnox solves is great, unified access to secrets across dev, CI, prod with cloud backends. That's a different layer of the stack.

Keeper solves a lower-level problem: you have a Go process (a load balancer, a control plane, a daemon) that needs to store secrets inside its own database not in a separate file, not in a cloud vault, not in env vars. Secrets that need per bucket isolation, audit trails, and crash-safe rotation.

Here is my thinking :

- fnox = how your CLI and deploy scripts get secrets

- Keeper = how your running binary stores secrets at rest

Different problems, Could I build Keeper on top of fnox? Probably. But then I'd have a file on disk with secrets that fnox manages which is exactly the problem I wanted to eliminate.