devsafe vault

Encrypted credential storage for your development environment. Store API keys, tokens, and secrets locally, encrypted with AES-256-GCM. Free to use, no account needed.

Overview

Vault encrypts your secrets at rest using nonce-unique AEAD (AES-256-GCM). Each value gets its own encryption with a fresh nonce, so no two ciphertexts are alike, even for identical values.

How is vault different from lockbox? They solve different problems and work well together.

• Vault encrypts secrets with AES-256-GCM. The data is unreadable without your key. Good for sharing encrypted credentials across machines or with teammates.
• Lockbox stores secrets in a binary format that is invisible to text-based tools (grep, cat, AI code assistants). Good for keeping secrets out of AI context windows on your local machine.

For maximum protection, use both. Vault encrypts. Lockbox hides. Together, your secrets are encrypted at rest and invisible to any tool that reads text.

Usage

$ devsafe vault <subcommand> [options]

Subcommands

vault add

Add a single secret interactively. The value is read from stdin, so it never appears in your terminal history or shell logs.

$ devsafe vault add GITHUB_TOKEN
Enter value for GITHUB_TOKEN: 
✓ stored GITHUB_TOKEN (encrypted, AES-256-GCM)

vault import

Import all key-value pairs from a .env file into the vault. Each secret is encrypted individually.

$ devsafe vault import .env
✓ imported 12 secrets from .env
✓ all values encrypted at rest

vault inject

Replace {{VAULT:KEY}} placeholders in any file with the decrypted values. The original file is updated in place.

$ devsafe vault inject docker-compose.yml
✓ replaced 3 placeholders in docker-compose.yml

vault run

Run any command with all vault secrets injected as environment variables. The secrets exist only in the child process memory. They are never written to disk.

$ devsafe vault run npm start
✓ injected 12 env vars into child process
Server listening on :3000

vault set

Associate a stored credential with a specific MCP server. When that server starts, it receives the credential automatically.

$ devsafe vault set GITHUB_TOKEN --server github
✓ GITHUB_TOKEN bound to server "github"

vault list

Show all stored keys. Values are never displayed.

$ devsafe vault list
KEY                SERVER      ADDED
GITHUB_TOKEN       github      2 days ago
DATABASE_URL       -           5 days ago
RESEND_API_KEY     -           5 days ago
STRIPE_SECRET      stripe      1 day ago

4 secrets stored (values hidden)

vault export

Export all vault secrets in .env format. Useful for migrating to a new machine or sharing with a teammate over an encrypted channel.

$ devsafe vault export > secrets.env
✓ exported 4 secrets to stdout

# delete secrets.env after use

Example workflows

Store and bind a GitHub token

Add a token to the vault, then bind it to your GitHub MCP server so the server receives the token automatically on startup.

# Step 1: store the token (value entered interactively)
$ devsafe vault add GITHUB_TOKEN
Enter value for GITHUB_TOKEN: 
✓ stored GITHUB_TOKEN

# Step 2: bind it to the github MCP server
$ devsafe vault set GITHUB_TOKEN --server github
✓ GITHUB_TOKEN bound to server "github"

Run a build with secrets

Instead of exporting secrets to your shell or writing a .env file, run commands directly through the vault. Secrets live only in the child process.

$ devsafe vault run npm start
✓ injected 12 env vars
Server listening on :3000

# also works with any command
$ devsafe vault run docker compose up
$ devsafe vault run python manage.py runserver

Inject secrets into Docker Compose

Use {{VAULT:KEY}} placeholders in your docker-compose.yml, then inject before running. This keeps secrets out of your compose file in version control.

services:
  api:
    environment:
      - DATABASE_URL={{VAULT:DATABASE_URL}}
      - STRIPE_SECRET={{VAULT:STRIPE_SECRET}}

$ devsafe vault inject docker-compose.yml
✓ replaced 2 placeholders

$ docker compose up

Vault vs. Lockbox

Both tools protect secrets, but they work differently. Here is when to use each one.

• Use vault when you need to share secrets across machines, inject them into running processes, or transfer credentials to a teammate. Vault encrypts data with AES-256-GCM, so it can be safely moved or backed up.
• Use lockbox when your main concern is AI tools reading your secrets during code generation. Lockbox converts text secrets into a binary format that text-based tools (including AI assistants) cannot read.
• Use both for maximum protection. Import secrets into the vault (encrypted at rest), then lockbox the vault storage directory (invisible to text tools). Your secrets are both encrypted and hidden.

How encryption works

Each secret stored in the vault is encrypted individually using AES-256-GCM with a fresh, random nonce (nonce-unique AEAD). This means:

• Every value is encrypted separately, so compromising one does not reveal others.
• Each encryption uses a unique nonce, so the same value encrypted twice produces different ciphertext.
• The authentication tag (part of GCM) detects any tampering. If someone modifies the encrypted file, decryption fails immediately.

For the full technical details, see Encryption model.