Secure store for your keys and passwords using your GitHub Private Repo as untrusted storage. Encryption happens at client side and no data pass through the wire unencrypted. It's just You and Your GitHub Private Repo.
GitHub-as-untrusted-storage with XChaCha20 is clever, but 1Password and Vault already own secrets.
Solo developers, small teams, self-hosted infrastructure operators
Vault (HashiCorp) · 1Password · Passbolt
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.
Gives you org-level operations that you'd otherwise script: auth, list orgs, repo sorting (stars/activity/staleness), stale-repo finder, cross-org issues and a dashboard — with JSON output for easy automation. Nothing revolutionary here, but the focused command set, XDG-config support and explicit token scopes make it a practical, scriptable tool for keeping repo hygiene under control.
GitHub sync for Claude Code configs with secret scanning before commit.
First multi-GPU TEE stack for training trillion-parameter models with under 10% overhead.
Encrypted .env replacement, but pass and sops already cover this.
Temporary decryption with ctg run deletes plaintext after command, unlike sops or git-crypt.
GitHub Gists as a database means zero backend costs and full portability.
