Skip to content

Local-first secrets for developers and agents

Your vault stays local. Your agents stay useful.

TinyVault is one Go binary that encrypts developer secrets in a local vault and lets tools use them without routinely exposing values to the model. No account, hosted service, or control plane.

1
Go binary
1
local vault database
MCP
agent tool surface
0
hosted backends
tinyvault
local
tvault init
created ~/.tvault/vault.db
tvault set STRIPE_KEY --from-env .env
Secret 'STRIPE_KEY' set successfully
tvault run -- npm run deploy
secret injected into the child, not the parent shell

A smaller trust boundary

Let the secret reach the process—not the conversation.

TinyVault’s agent tools are shaped around outcomes. Search returns metadata. Generation returns non-secret metadata. Export returns a file path. Execution injects values into a child process and can redact literal values in captured output when policy enables it. A raw read exists, but it is the explicit exception.

Redaction reduces accidental leaks; it is not a sandbox. The threat model explains the boundary in full.

One vault, three surfaces

Use the interface that fits the caller.

The CLI, terminal studio, and MCP server all use the same storage, encryption, project boundaries, and audit trail. There is no sync layer to drift and no second database to secure.

Beyond set and get

A complete local secrets workflow.

Replace the loose collection of plaintext files, one-off scripts, and copied credentials with one inspectable tool.

Explore the guides
01

Tame .env sprawl

Import without shell expansion, detect drift, sync in either direction, or keep commit-safe placeholders in the repo.

Dotenv workflows →
02

Share without sharing a passphrase

Wrap a project key to X25519 recipients. Removing one re-keys the updated live vault; retained snapshots remain readable.

Recipient sharing →
03

Commit ciphertext, not credentials

Use standalone encrypted env files, Kubernetes-shaped sealed manifests, or transparent Git clean/smudge filters.

Committable secrets →
04

Recover from a bad rotation

Every overwrite archives the prior encrypted value. Inspect metadata and roll back non-destructively to a new version.

Versioning and rollback →
05

Model environments explicitly

Group development, staging, and production projects; compare drift, inherit defaults, pin overrides, and promote deliberately.

Environment groups →

Inspectable security

No mystery service between you and your keys.

The encryption path is compact enough to audit: Argon2id derives a key-encryption key, each project gets its own data-encryption key, and AES-256-GCM authenticates every encrypted value.

Read the architecture
01
You rememberPassphrase
Argon2id
02
Held in memoryKEK
AES-GCM wrap
03
One per projectDEK
AES-GCM encrypt
04
Authenticated ciphertextSecret values

An intentionally narrow product

Know when TinyVault fits—and when it does not.

Use TinyVault when

  • You want local development secrets without a hosted account.
  • You need to inject values into any process that reads environment variables.
  • You want an agent to act on secrets while minimizing value exposure.
  • You prefer one portable binary and one local database with encrypted secret values.

Choose another tool when

  • You need managed team sync, centralized RBAC, or an admin console.
  • You require dynamic credentials, cloud KMS, HSMs, or high availability.
  • You need account recovery or escrow if the passphrase is lost.
  • You need isolation from another malicious process running as the same OS user.
Read the full threat model before trusting TinyVault with anything important

Local by default

Build with secrets.
Keep the values out of the way.

Install the binary, create a vault, and inject your first secret in a few minutes.

Open the quickstart

Released under the MIT License.