Case study · Security Engineering
Rune
A secrets manager whose key never touches disk
A self-hosted vault in a single Go binary — encrypted at rest, sealed by default, with the key held only in memory.
- Go
- AES-256-GCM
- Argon2id
- BoltDB
What it is
A minimal secrets manager for developers and small teams who want their credentials on infrastructure they control. A CLI and an HTTP server in one binary, with no cloud services, no agents and no external dependencies.
The problem
Every serious secrets manager assumes you already have cloud infrastructure and someone to operate it. For a solo developer or a team of four, that is a great deal of machinery to protect a handful of credentials.
So the credentials stay in a .env file, in plain text, copied between machines over chat — which is the outcome the machinery existed to prevent.
What we built
Three decisions that shaped it.
Sealed until you open it
The vault starts locked and nothing is readable until it is unsealed with a passphrase. Argon2id derives the key, so guessing it is expensive in memory as well as time.
The key lives in memory only
Once unsealed, the encryption key exists in the running process and is never written to disk. Seal the vault and it is gone until someone types the passphrase again.
Encrypted per secret, not per file
AES-256-GCM with a unique nonce for every secret, so the storage file gives away nothing — not even which entries changed. Tokens are hashed before they are stored.
What it does
Six things, plainly.
Starts locked. Unsealing is deliberate.
Never written to disk, gone on seal.
Unique nonce per secret.
Memory-hard, resists GPU attacks.
Isolated containers for separate work.
Created, listed and revoked; never stored raw.
Built with
- Language
- Go
- Encryption
- AES-256-GCM
- Key derivation
- Argon2id
- Storage
- BoltDB, embedded
- Interfaces
- CLIHTTP API
What came out of it
The outcome.
A vault that is one binary, on hardware you already own.
It protects against an attacker with your disk. That boundary is written down rather than implied.
Few enough moving parts that a solo developer can understand what protects them.
Built in-house by our engineers, and the tool we use on our own work.
Have a problem shaped like this one?
Describe the situation and a senior engineer will tell you what it needs.