DEV Community

Robin Alex Panicker
Robin Alex Panicker

Posted on

AxKeyStore: A Zero-Trust CLI for Managing Secrets Using GitHub as Your Backend

#security #developers #git #github

Most developers today juggle secrets across multiple environments—API keys, database credentials, tokens, signing keys. The typical solutions fall into three buckets:

  • .env files (simple, but unsafe and unscalable)
  • Cloud secret managers (secure, but expensive and vendor-locked)
  • Password managers (not developer-native)

AxKeyStore introduces a different approach:

Use your own GitHub repository as an encrypted, versioned, zero-trust secret store—fully controlled by you.

This article breaks down how AxKeyStore works, why its architecture matters, and how you can integrate it into your workflow.

AxKeyStore is MIT Licensed Open Source project - https://github.com/basilgregory/axkeystore

The Core Idea

AxKeyStore is a CLI-first secret manager that:

  • Stores secrets in your own private GitHub repo
  • Uses client-side encryption only
  • Treats GitHub as untrusted storage
  • Ensures no plaintext secrets ever leave your machine

This flips the traditional model:

Traditional Secret Manager AxKeyStore
Trust the provider Trust only your machine
Secrets decrypted in cloud Secrets decrypted locally
Vendor-controlled infra Your GitHub repo
Centralized trust Zero-trust

Architecture Overview

AxKeyStore is built on a multi-layer encryption model designed for strict isolation and zero trust.

1. Key Hierarchy

There are two core keys:

Local Master Key (LMK)

  • Generated per profile
  • Stored locally

  • Encrypts:

    • GitHub token
    • Repository configuration

Remote Master Key (RMK)

  • Stored in GitHub (encrypted)
  • Used to encrypt actual secrets

2. Encryption Layers 

Secret → encrypted with RMK
RMK → encrypted with Master Password
Local config → encrypted with LMK
LMK → encrypted with Master Password
Enter fullscreen mode Exit fullscreen mode

This creates a 3-layer protection model:

  1. Secrets are never stored in plaintext
  2. GitHub only sees encrypted blobs
  3. Even local config is encrypted

3. Cryptography Choices

AxKeyStore uses modern primitives:

  • XChaCha20-Poly1305 → authenticated encryption
  • Argon2id → password-based key derivation
  • Client-side encryption only

Implication:

Even if GitHub is compromised, your secrets remain secure.

Why GitHub as a Backend?

This is the most unconventional design decision—and also the most powerful.

Benefits

1. Version Control for Secrets

Every update becomes a commit.

axkeystore history "api-key"
Enter fullscreen mode Exit fullscreen mode

You get:

  • Full audit trail
  • Rollbacks via commit SHA
  • Time-based debugging

2. Free, Reliable Infrastructure

  • No infra to maintain
  • No billing surprises
  • Global availability

3. Ownership & Portability

  • You control the repo
  • No vendor lock-in
  • Works across machines instantly

Developer Experience

AxKeyStore is designed for daily CLI usage, not dashboards.

Setup 

axkeystore login
axkeystore init --repo my-secret-store
Enter fullscreen mode Exit fullscreen mode

Store a Secret 

axkeystore store --key "stripe-api-key" --value "sk_live_..."
Enter fullscreen mode Exit fullscreen mode

Or auto-generate:

axkeystore store --key "jwt-secret"
Enter fullscreen mode Exit fullscreen mode

Retrieve a Secret 

axkeystore get "stripe-api-key"
Enter fullscreen mode Exit fullscreen mode

Organize by Environment 

axkeystore store \
  --key "db-password" \
  --category "prod/database"
Enter fullscreen mode Exit fullscreen mode

This creates structured storage:

prod/database/db-password
Enter fullscreen mode Exit fullscreen mode

List Everything 

axkeystore list
Enter fullscreen mode Exit fullscreen mode

Output:

[prod/database]
  db-password = ****

[api]
  stripe-key = ****
Enter fullscreen mode Exit fullscreen mode

Profiles: Multi-Environment Isolation

AxKeyStore supports multiple profiles, each with:

  • Separate GitHub repo
  • Separate master password
  • Separate keyspace

Example:

axkeystore profile create work
axkeystore profile switch work
Enter fullscreen mode Exit fullscreen mode

Use cases:

  • Personal vs Work
  • Dev vs Prod
  • Multi-tenant SaaS ops

Security Model Deep Dive

Let’s break down the threat model.

What if GitHub is compromised?

Attacker sees:

  • Encrypted blobs
  • Encrypted RMK

They cannot decrypt:

  • RMK (needs master password)
  • Secrets (needs RMK)

What if local machine is compromised?

Attacker sees:

  • Encrypted LMK
  • Encrypted token

Still needs:

  • Master password

What if both are compromised?

Only then:

  • System becomes vulnerable

This is consistent with zero-trust design principles.

How It Compares

vs .env Files

Feature .env AxKeyStore
Encryption ❌ ✅
Versioning ❌ ✅
Sharing Manual GitHub-native
Security Weak Strong

vs Cloud Secret Managers

Feature Cloud (AWS/GCP) AxKeyStore
Cost $$$ Free
Setup Complex Simple
Lock-in High None
Control Limited Full

vs Vault (HashiCorp)

Feature Vault AxKeyStore
Infra required Yes No
Ops overhead High Zero
Dev UX Moderate CLI-native

Where AxKeyStore Fits Best

AxKeyStore is ideal for:

1. Indie Hackers / Startups

  • No infra overhead
  • Free secret storage
  • Works instantly

2. CLI-first Engineers

  • No dashboards
  • Scriptable
  • Fast workflows

3. Multi-Repo Developers

  • Secrets tied to GitHub repos
  • Natural workflow integration

Where It May Not Fit

  • Enterprises needing:

    • RBAC policies
    • Secret rotation automation
    • Compliance (SOC2, etc.)

  • Real-time secret injection into runtime (no agent model yet)

Advanced Use Cases

1. CI/CD Integration

You can pull secrets during pipeline execution:

SECRET=$(axkeystore get "api-key")
Enter fullscreen mode Exit fullscreen mode

2. Version Debugging

Roll back to a previous secret:

axkeystore get "api-key" --version <SHA>
Enter fullscreen mode Exit fullscreen mode

3. Secret Generation

Let AxKeyStore generate secure values:

axkeystore store --key "jwt-secret"
Enter fullscreen mode Exit fullscreen mode

Internal Design Insights (For Builders)

AxKeyStore is implemented in:

  • Rust
  • Async via tokio
  • CLI via clap

Key design decisions:

1. GitHub as API Layer

  • Uses GitHub Contents API
  • Stores secrets as files
  • Leverages commit history

2. Profile Isolation via Filesystem

Each profile has its own config:

~/.config/com.ax.axkeystore/
Enter fullscreen mode Exit fullscreen mode

3. No Plaintext Persistence

  • Everything encrypted at rest
  • No caching of decrypted values

Strategic Insight

AxKeyStore represents a broader shift:

Decoupling infrastructure from trust

Instead of:

  • Trusting AWS / Vault / providers

You:

  • Trust cryptography
  • Own storage
  • Control access

This pattern will likely expand into:

  • Logs
  • Analytics
  • Observability (similar to what tools like Appxiom are doing)

Final Thoughts

AxKeyStore is not trying to replace enterprise secret managers.

It’s targeting a different segment:

Developers who want control, simplicity, and strong security without infrastructure overhead

If your current workflow involves:

  • .env files
  • Copy-pasting secrets
  • Manual sharing

Then AxKeyStore is a meaningful upgrade.

Get Started 

curl -sSL https://raw.githubusercontent.com/basilgregory/axkeystore/main/install.sh | bash
Enter fullscreen mode Exit fullscreen mode

Then:

axkeystore login
axkeystore init --repo my-secret-store
Enter fullscreen mode Exit fullscreen mode

If you’re building developer tools or care about security architecture, AxKeyStore is worth studying—not just using.

It’s a clean example of:

  • Zero trust
  • Client-side encryption
  • Leveraging existing infra (GitHub) in unconventional ways

Top comments (0)