For developers · Secrets Manager

Your keys, everywhere they're needed. Exposed nowhere.

One encrypted vault on your machine fans every secret out to the exact repos and environments that need it — as ready-to-use .env files. Your CLI and your AI agents can deploy those secrets. Not one of them can read a value back out.

Want it now? Browse the source on GitHub →

The status quo

Every repo wants the same keys.
Keeping them in sync — and safe is the tax.

You add a key once and then maintain it everywhere, forever. Today that means one of three bad trades.

Drift
Thirty copies of the truth
Ten repos × three environments is thirty .env files going stale. Rotate one key and you're hunting down the other twenty-nine.
Exposure
Plaintext on demand
General vaults hand a full plaintext value to anything that calls their CLI — including an agent one prompt-injection away from leaking it.
Agents
Pasted into the prompt
Sooner or later your coding agent asks you to paste a key into a shell, a file, or the context window — and now it lives somewhere you can't audit.
What you get

One vault. Every repo.
Zero exposure.

Add a secret once, scope it where it belongs, and let your tools take it from there — without ever handing one a way to read it.

  • ✓One encrypted vault on your machine — local-first, no cloud, no account.
  • ✓Fan any secret out to any (repo × environment) as a ready-to-use encrypted .env.
  • ✓An AI-safe CLI (sm) your agents can drive — to add and deploy, never to reveal.
  • ✓A three-pane GUI for when you'd rather click than type. Your machine, your keys, your call.
$ sm add OPENAI_API_KEY # value entered out-of-band, encrypted at rest ✓ stored — value never echoed   $ sm deploy --repo api --env prod ✓ wrote api/.env.prod — 4 secrets, all encrypted   $ sm reveal OPENAI_API_KEY ✗ unknown command 'reveal' — this CLI cannot print a secret
The CLI an agent can run safely — because reveal doesn't exist.

General-purpose vaults expose plaintext to anything that asks. Per-repo .env files drift into dozens of unsynced copies. Cloud secret managers are built for orgs, not the developer who owns the machine. Secrets Manager is the only one that's local-first, opinionated about (repo × env) deploy, and safe to hand an AI agent — because it has no way to reveal a secret.

Why you can trust it

Safe to share a machine with — even with your agents.

The guarantees aren't policy. They're the way the tool is built.

Local-first
Your vault lives on your disk, encrypted at rest. No cloud, no account — nothing to breach but the machine you already control.
No reveal verb
The CLI can structure and deploy secrets. It physically cannot print a plaintext value. Prompt-inject all you like — there's nothing to exfiltrate.
One source of truth
Add or rotate a key once; every repo and environment that uses it updates from the same vault. The thirty-copy drift just stops.
Open source
Read every line — the crypto, the CLI, the daemon. Free for single-developer use, and yours to audit before you trust it with a single key.
Who it's for

Built for the way you
actually work now.

Shaped around developers running many repos — and, increasingly, many agents — on a machine they own.

AI-assisted dev
Coding with agents
You run Claude Code, Cursor, or Codex across a stack of repos. Give them what they need to ship — without ever giving them a way to read your keys.
Many repos · many envs
Juggling environments
Dev, staging, prod across project after project. Define each secret once and deploy it precisely where it belongs — no copy-paste, no drift.

Free and open-source for single-developer use. Team sharing and cloud-backed vaults are on the roadmap — tell us if you'd want them.

Keep your keys to yourself.

Drop your email and we'll send install instructions and the occasional update. Want to dive in now? It's open source on GitHub.

Or go straight to the code: github.com/JigSpec →

Get it →