Show HN: AxKeyStore – Zero-trust CLI secrets manager using your own GitHub repo(github.com)
github.com
Show HN: AxKeyStore – Zero-trust CLI secrets manager using your own GitHub repo
https://github.com/basilgregory/axkeystore
1 comments
Cool approach — using a private GitHub repo as encrypted storage is clever for solo devs who want zero external dependencies.
We're building something in the same space with KeyEnv (https://keyenv.dev) but took a different direction: server-side encrypted storage with a CLI that injects secrets as env vars at runtime (`keyenv run -- npm start`). No files written to disk, no .env files to manage.
The trade-off is pretty clear: AxKeyStore gives you full ownership of storage (GitHub repo) at the cost of managing encryption keys yourself. KeyEnv handles the key management server-side but requires trusting our infrastructure (or self-hosting).
For teams, the big differentiator is access control — KeyEnv scopes secrets per project and environment, and tracks who accessed what. Curious if you've thought about multi-user scenarios for AxKeyStore?
We're building something in the same space with KeyEnv (https://keyenv.dev) but took a different direction: server-side encrypted storage with a CLI that injects secrets as env vars at runtime (`keyenv run -- npm start`). No files written to disk, no .env files to manage.
The trade-off is pretty clear: AxKeyStore gives you full ownership of storage (GitHub repo) at the cost of managing encryption keys yourself. KeyEnv handles the key management server-side but requires trusting our infrastructure (or self-hosting).
For teams, the big differentiator is access control — KeyEnv scopes secrets per project and environment, and tracks who accessed what. Curious if you've thought about multi-user scenarios for AxKeyStore?
I built AxKeyStore, an open-source CLI tool for managing secrets that uses your own private GitHub repository as encrypted storage.
The idea is simple: → All encryption happens locally. → Secrets are stored as encrypted blobs in your private repo. → GitHub is treated as untrusted storage. → No plaintext secrets ever leave your machine. → No plaintext secrets are stored on disk.
Most secret managers either require a hosted backend, a self-hosted server, or trusting a SaaS provider. I wanted something that: → Requires zero infrastructure → Uses tooling developers already have → Keeps the threat model simple
AxKeyStore uses a layered approach to security: → Secrets are encrypted with a Remote Master Key (RMK). → The RMK is encrypted with your master password and stored in the repo. → A Local Master Key (LMK) encrypts your local GitHub token and repo config. → The LMK itself is encrypted using Argon2id-derived keys from your master password. → Encryption uses XChaCha20-Poly1305 (AEAD).
GitHub only sees encrypted binary blobs. Even if someone compromises your repository, they still need your master password to decrypt anything.
Why GitHub? Because it gives: → Private repositories → Version history (commit log as audit trail) → Access control → Free storage → Global availability
Instead of building a backend, I’m leveraging an existing, reliable system - but cryptographically isolating it.
Features → Simple CLI workflow → Hierarchical categories (e.g., cloud/aws/prod) → Version history per secret (via commits) → Retrieve specific versions by SHA → Multi-profile support (separate vaults) → Transactional master password reset → Secure random secret generation
Tech → Written in Rust. Uses tokio, clap, argon2, and chacha20poly1305. → There are unit and integration tests (including mocked GitHub API interactions). → Open source - MIT licensed.
I’d appreciate feedback on: → The threat model - what am I missing? → Whether GitHub as encrypted blob storage is a bad assumption → UX improvements for CLI-based secret workflows → Any crypto or key-handling concerns
I’m especially interested in critique from people who’ve built or audited secret management systems.
Thanks.