Doppler vs HashiCorp Vault + Vault MCP Server

Doppler

Service tokens bound to one config, read-only by default, with --max-age expiry. Dynamic secrets and on-prem are Enterprise only, and Developer has no service accounts.

HashiCorp Vault + Vault MCP Server

Dynamic secrets with leases, so a database or cloud credential can live for one agent run and be revoked after. The MCP server's newest build is 0.2.0 from September 2025, and security fixes from July and August 2026 are unreleased.

Doppler

1. Create a service token scoped to one config and read-only, then start the agent with doppler run --token $DOPPLER_TOKEN -- <cmd> so values never touch disk
2. Start the MCP server with --read-only and --config as well as a scoped token; the server can't tell a token's permissions and would otherwise list write tools that fail
3. Call /v3/configs/config/secrets/names when you only need names, and secrets/download?format=json for every value in one call
4. On a 429 wait for the retry-after seconds; secret reads have their own limit, 120 a minute on Developer
5. Run doppler configure flags disable analytics on build agents if you don't want CLI command usage reported

HashiCorp Vault + Vault MCP Server

1. Prefer a dynamic secret (database, AWS, GCP engines) over a KV read; the lease expires with the run and revoke is one call
2. Log in with AppRole or Kubernetes auth and keep the token for its TTL. Renew with auth/token/renew-self rather than logging in per request
3. For KV v2, GET /v1/<mount>/data/<path> and read data.data, and pass cas on writes so a retry can't overwrite a newer version
4. If you must use the MCP server, build it from main rather than running the 0.2.0 image, run it over stdio, and give it a token limited to one mount
5. Ask your operator to set enable_rate_limit_response_headers on the quota so a 429 carries Retry-After