A zero-knowledge secrets manager for developers

Why .env is not a secrets manager

A .env file is plaintext on disk: it sneaks into commits, gets pasted into Slack, lives duplicated on every laptop, and has no rotation, no audit trail, no revocation. The moment you have a second developer or a deployment, .env is a leak waiting for a date.

AI coding assistants (Claude Code, Cursor, Copilot) multiplied the problem: the #1 security failure in AI-generated code is exposed secrets — hardcoded keys and .env files pushed to repos.

A secrets manager fixes this by centralizing encrypted values and serving them only to consumers that should read them, with every access logged.

How Koove works: encrypt locally, upload only the envelope

With Koove, a secret is encrypted ON YOUR MACHINE before it leaves it (envelope encryption: AES-256-GCM for the value, X25519 + HKDF to seal the key per recipient). The server stores ciphertext only — it holds no private keys, so it cannot read anything. That's real zero-knowledge, and it's verifiable: the primitives are open source.

Migrating takes one command: import your whole .env and every key ends up encrypted for your authorized consumers.

# Install the CLI (Node.js >= 22)
npm install -g @koove/secrets-cli

# Create your app: controller identity + BIP39 recovery code
koove app-init

# Store a secret (encrypted locally; only the envelope is uploaded)
koove set DATABASE_URL "postgres://..." --env prod

# Or migrate your entire .env at once
koove import .env --env prod

Only verified consumers decrypt

On the mobile edge, a device becomes a recipient only after passing real cryptographic attestation — Apple App Attest (verified end-to-end on a physical device) or Google Play Integrity — and local decryption is gated by biometrics. On backend and CI/CD, authorized consumers with their own identity.

The server decides WHICH public keys are eligible (attestation gates), but it never wraps or sees the data key. The writer encrypts directly for the authorized set.

Full lifecycle, with honest limits

Zero-downtime key rotation, per-device revocation with a cryptographic kill (strips the revoked device from every envelope), a 24-word BIP39 recovery code for the worst day, server-side anomaly detection, and canary tokens that turn a theft into a confirmed alert.

And the limit others won't tell you: no system can "un-deliver" a secret a device already decrypted and cached. For a total kill, you rotate the value. We say it in the CLI, in the docs, and here.

Koove or a generalist manager?

Frequently asked questions