@vaultproof/init

One command to protect every API key in your .env. Zero code changes.

npx @vaultproof/init

That's it. Scan, split, upload, rewrite. Your OpenAI, Stripe, Anthropic, and other keys are now replaced by a single VAULTPROOF_PROJECT_ID in your .env. Your application code doesn't change.

What it does

1. Scans your .env, .env.local, .env.production, and .env.development files for API keys.
2. Identifies each key by shape against a catalog of 15+ providers (OpenAI, Anthropic, Stripe, Groq, Mistral, Together, Fireworks, DeepSeek, xAI, OpenRouter, Resend, SendGrid, Linear, Notion, GitHub).
3. Splits each key into two Shamir secret shares, locally in your terminal — the plaintext key is never sent to VaultProof.
4. Uploads the two encrypted shares to the VaultProof init worker.
5. Rewrites your .env with a single VAULTPROOF_PROJECT_ID identifier and per-provider *_BASE_URL lines pointing at the VaultProof proxy.
6. Backs up your original .env with a timestamp before touching anything.

The project ID is not a secret. It can live safely in your .env, in commit history, and in browser devtools. The actual API keys live only as split shares until the VaultProof proxy reconstructs them for the duration of a single API call.

Example

Before:

# .env
OPENAI_API_KEY=sk-proj-abc123xyz...
STRIPE_SECRET_KEY=sk_live_4xT7...
ANTHROPIC_API_KEY=sk-ant-api03-...
DATABASE_URL=postgres://user:pw@host/db

After:

# .env
# ── VaultProof ──────────────────────────────────────────────
# One project ID for every protected key. Safe to commit.
# Generated by `npx @vaultproof/init` — do not hand-edit values.
VAULTPROOF_PROJECT_ID=vp-proj-abc123
OPENAI_BASE_URL=https://init.vaultproof.dev/p/openai/v1
STRIPE_BASE_URL=https://init.vaultproof.dev/p/stripe/v1
ANTHROPIC_BASE_URL=https://init.vaultproof.dev/p/anthropic
# ───────────────────────────────────────────────────────────
OPENAI_API_KEY=vp-proj-abc123
STRIPE_SECRET_KEY=vp-proj-abc123
ANTHROPIC_API_KEY=vp-proj-abc123
DATABASE_URL=postgres://user:pw@host/db

Your code doesn't change. Your OpenAI SDK still reads OPENAI_API_KEY and OPENAI_BASE_URL from the environment. Requests go through the VaultProof proxy, which reconstructs the real key in memory for ~0.03ms per call, forwards to OpenAI, and zeroes the key afterwards.

Usage

# Interactive (recommended)
npx @vaultproof/init

# Skip confirmation
npx @vaultproof/init --yes

# Scan only, don't upload or rewrite
npx @vaultproof/init --dry-run

# Audit and migrate from the legacy vp_live_ system
npx @vaultproof/init --check-legacy

# Verify auth, worker, and proxy connectivity
npx @vaultproof/init doctor

Prerequisites

• Node.js 18 or newer (uses built-in fetch)
• A VaultProof account. Sign in at vaultproof.dev to create one — free tier includes 10,000 proxied calls / month.
• Your plaintext API keys in a .env file. If your keys aren't in .env yet (rotated but not re-saved), put them there first.

Authentication

The CLI reads your Supabase session from ~/.vaultproof/config.json or the VAULTPROOF_JWT environment variable. If no valid JWT is present, @vaultproof/init opens a browser-based login flow automatically and saves the session for later runs.

How the security works

VaultProof uses Shamir's Secret Sharing to split each API key into two mathematically independent shares. Individual shares are useless — knowing one share reveals zero information about the key. Both shares must be combined to reconstruct the original.

• Share 1 is encrypted with AES-256-GCM (HKDF-SHA256 key derivation) and stored in Supabase.
• Share 2 is stored separately in Supabase as a base64 blob.
• The shares are combined only inside the VaultProof proxy worker, in memory, for the ~0.03ms it takes to make one API call. The reconstructed key is zeroed immediately after the request is issued.
• The plaintext key never exists on your machine after init runs. It never appears in process memory, logs, or any network request that leaves the VaultProof proxy.

See vaultproof.dev/docs for the full architecture, including the SSRF hardening applied to user-declared upstreams.

Supported providers

Detection is driven by providers.json which is fetched at runtime (with a bundled fallback). Today's catalog:

| Provider | Key pattern | Env var rewrite | |---|---|---| | OpenAI | sk-proj-... / sk-... | OPENAI_BASE_URL | | Anthropic | sk-ant-api03-... | ANTHROPIC_BASE_URL | | Stripe | sk_live_... / sk_test_... | STRIPE_BASE_URL | | Groq | gsk_... | GROQ_BASE_URL | | xAI (Grok) | xai-... | XAI_BASE_URL | | OpenRouter | sk-or-v1-... | OPENROUTER_BASE_URL | | DeepSeek | sk-... (with DEEPSEEK in var name) | DEEPSEEK_BASE_URL | | Mistral | 32-char (with MISTRAL in var name) | MISTRAL_BASE_URL | | Together AI | 64-char hex (with TOGETHER in var name) | TOGETHER_BASE_URL | | Fireworks AI | fw_... | FIREWORKS_BASE_URL | | Resend | re_... | (client-side base URL) | | SendGrid | SG.xxx.yyy | (client-side base URL) | | Linear | lin_api_... | (client-side base URL) | | Notion | secret_... / ntn_... | (client-side base URL) | | GitHub | ghp_... / github_pat_... | (client-side base URL) |

Need a provider we don't support yet? Open an issue or PR on github.com/windsurftemplate/vaultproof.

Migrating from the legacy vp_live_ system

If you were using an earlier version of VaultProof with vp_live_ developer keys, run:

npx @vaultproof/init --check-legacy

This lists every key stored in the legacy system and walks you through migrating each one. Plaintext values are not recoverable from the legacy system — that's by design. You'll need to rotate each key in the provider dashboard and paste the fresh value when prompted.

The migration is strictly read-only against the legacy system. Nothing is deleted. You can keep both systems running in parallel until you're ready to flip over.

Security model

• Project IDs are public. Safe to commit. A leaked project ID lets an attacker consume your proxy rate limit (60 calls / 60s), but cannot reveal or recover the protected keys.
• Shares at rest. Share 1 is AES-256-GCM encrypted server-side. Share 2 is stored separately. Either share alone is mathematically useless.
• SSRF hardened. User-declared upstream URLs pass through 85-test-case validation: https-only, no IP literals, no loopback/metadata/cloud-internal hosts, no punycode, no embedded credentials, no unexpected ports.
• Rate limited. Per-project proxy quota, per-user creation quota, per-IP failed-auth quota, all backed by strongly-consistent Durable Objects.

Full security policy: SECURITY.md

License

MIT. See LICENSE.

Links

• Docs: vaultproof.dev/docs
• Dashboard: vaultproof.dev/app
• Blog: vaultproof.dev/blog
• Security: [email protected]
• Issues: github.com/windsurftemplate/vaultproof/issues