API bank & secret vault

Methods

• Email + password, or one click with GitHub / Google.
• Enroll two-factor after sign-up: scan the QR code with any authenticator app and save the backup codes somewhere safe.
• Later sign-ins ask for the six-digit code — an OTP challenge before the session is granted.
• Lost phone? A backup code gets you back in; then re-enroll.

Admin board

Admins get a board for user and role management. The very first admin is seeded server-side (see the seeding section below) — never through the UI, never with credentials in the repo.

Open sign-in on the main site ↗

Creating a secret

• Name — e.g. OPENAI_API_KEY.
• Value — encrypted before it rests in the database.
• Allowed hosts — comma-separated (api.openai.com); required for proxying, and the proxy refuses anything else.
• Inject as — header sends an Authorization Bearer header, body adds the secret to a JSON body field instead.
• Description — optional plaintext note saying what the key is for (never the value itself, max 500 chars).

Living with secrets

• Masked list — every row shows a preview, never the value; filter it client-side by name, description, or host.
• Reveal on demand — one click fetches the plaintext into memory only; hide it when done.
• Proxy test — each row has a built-in panel that fires a real request through POST /api/proxy/:id so you can verify a key without ever seeing it.

Open the vault on the main site ↗

Duplicates are handled on demand only — nothing is checked on write. The /vault page's Find duplicates button (and site-vault dedupe [--prune]) scans for exact copies and near-matches server-side with masked previews only: prune deletes exact copies keeping the oldest, while near-matches are always merged manually via Edit/Delete and are never auto-deleted.

Calling the API

curl -H "Authorization: Bearer <key>" \
  https://your-app.vercel.app/api/vault

Only key metadata is ever listed (name, id, created / last-used dates). Deleting a key immediately stops every caller using it.

Trust model: minting or deleting a key requires a signed-in browser session — Bearer keys can't mint or revoke keys. Keys do not trigger a two-factor challenge when they are used, so treat them like passwords. New keys expire after 90 days (1–365 days on request) and are usage-capped.

The CLI can mint keys too: pipe your password to site-vault mint --email you@example.com (add --otp <code> for two-factor accounts, --save to store the fresh key as this machine's login). Like the /keys page it signs in with a session — Bearer keys can't mint by design — and the raw key prints exactly once. See cli/README.md for flags.

Open API keys on the main site ↗

Proxy without touching the secret

curl -X POST \
  -H "Authorization: Bearer <key>" \
  -H "content-type: application/json" \
  -d '{"url":"https://api.openai.com/v1/models","method":"GET"}' \
  https://your-app.vercel.app/api/proxy/:id

The server checks the URL against the secret's allowed hosts, injects the value as a header or body field, and returns the upstream status, headers, and body.

Trusted-hosts warning: anyone able to call the proxy can make the server send the secret to any allowlisted host — only allowlist hosts you trust with the value. Targets must be public https hosts on the default port (no credentials in the URL); private, loopback, link-local, and other reserved ranges are rejected after DNS resolution, and the resolution is re-checked after the call.

Setup & everyday use

# run in place, or link it onto PATH
node cli/vault.mjs --help
npm link
site-vault --help

# log in (one authenticated round-trip, then saved)
# --api-key-stdin / --api-key-env avoid leaving the key in shell history
printf '%s' "$SITE_VAULT_KEY" | site-vault login --url https://example.com --api-key-stdin
site-vault login --url https://example.com --api-key-env SITE_VAULT_KEY

# list and read (masked previews only)
site-vault list
site-vault get OPENAI_API_KEY
site-vault get OPENAI_API_KEY --reveal  # raw value on stdout

# delete
site-vault delete OLD_KEY

Pushing & proxying

# push (upsert: creates, or updates on name conflict)
printf '%s' "$OPENAI_API_KEY" | \
  site-vault push OPENAI_API_KEY --value-stdin --hosts api.openai.com
site-vault push STRIPE_KEY --env-key STRIPE_SECRET --inject header

# bulk import from an env file (names only are ever printed)
site-vault push-env-file .env.local --all
site-vault push-env-file .env.local --prefix OPENAI_
site-vault push-env-file .env.local --allowlist STRIPE_SECRET,OPENAI_API_KEY

# proxy: secret is injected server-side, never touches this machine
site-vault proxy OPENAI_API_KEY --url https://api.openai.com/v1/models

Login details are stored at ~/.config/site-vault/config.json with mode 600 — readable only by you. Prefer --api-key-stdin or --api-key-env over --api-key, which can linger in shell history. Proxy calls carry the same trusted-hosts rule as the web UI: the server will send the secret to any allowlisted host.