Secrets distribution hub

Vendors create credentials. Humans (and agents) should not re-enter those credentials every time a preview host, team scope, or deploy matrix changes.

Name the credential by architecture before you distribute it: API key vs token (long-lived project keys and PATs are still keys; short-lived handshake credentials are access tokens).

Secrets distribution flow: vendor → vault → hub → hosting → runtime

The split that matters

  • Create — each vendor dashboard (OAuth client, deploy key, publishable key).

  • Store — human vault (Bitwarden, 1Password, …) with custom fields for machine-readable API material; optionally a deploy-time hub (Pulumi ESC, cloud secret manager). For Bitwarden server choice (cloud vs official self-host vs Vaultwarden), see Bitwarden and Vaultwarden.

  • Distribute — local ignored env files; hosting project env (Vercel, Netlify, …); CI secrets.

The hosting UI is a target, not the long-term source of truth.

Where agents fit

Agents coordinate CLIs and MCP:

  • Vault CLI — unlock, search, read custom fields (prefer over pasting secrets into chat).

  • Hosting CLI — env ls / env add against the correct org/team project.

  • MCP — optional when a server is authenticated and exposes the right tools. A linked hosting MCP is convenience; a vault MCP that only manages org groups is not a substitute for the vault CLI.

  • Package managers — install CLIs with the team’s preferred global tool (pnpm add -g, winget, …). Package catalogs do not always ship every CLI.

See also Composio and MCP connectors and Studio MCP install strategies.

Pulumi ESC (and friends)

Infrastructure as Code can own distribution:

flowchart LR
  V[Vendor consoles] -->|create once| H[Human vault]
  H -->|seed| E[Secrets hub ESC]
  E -->|sync / apply| M[Hosting env matrix]
  E -->|optional| L[Local pull / run]
  M --> R[App runtime]

Changing BETTER_AUTH_URL / public app URL / which Vercel project receives keys should be a hub + apply step—not a scavenger hunt through browser password managers.

App data schemas (for example Convex schema.ts) still live with the application. Org infra repos often start as DNS/email only; promote app secrets into ESC when the matrix pain shows up.

Ownership patterns

  • Org email logins for SaaS that allows it (Radar, Customer.io, Google Cloud OAuth clients).

  • Personal identity + Business app when the vendor forces one-human-one-login (common for Meta/Facebook): keep one personal account, create a Business/Developer app, invite the org email as admin, store Client ID/Secret under the org vault item.

  • Generated locals (BETTER_AUTH_SECRET, token encryption keys)—create per environment; do not reuse local secrets in production.

Example instance (non-normative)

FoodTruckNerdz web app work used Bitwarden CLI custom fields (Convex deploy keys), Vercel team scope for ftn-site-nextjs, and local site-nextjs/.env.local. Org Pulumi infra remained DNS-focused until ESC sync is added. Detail: How-to and Tutorial.