Doppler vs Keeper Secrets Manager

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.

Keeper Secrets Manager

Each client device signs requests with its own key, is locked to an IP address by default and can be revoked alone, and secrets decrypt only on the client. The add-on has no public price, no request limits were found in the reviewed documentation, and a person must create the application and device in the vault.

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

Keeper Secrets Manager

1. Ask the vault owner for a new device on an application that holds only the folders the task needs. Use the Base64 configuration, not the first one-time token
2. Run commands under ksm exec so secrets arrive as environment variables and stay out of the model's context
3. Expect HTTP 403 with {"error":"throttled"} under load. The Python SDK retries five times from 11 seconds, so allow for long waits
4. A device is locked to the IP address it first connects from unless it was created with --unlock-ip. Check this before running from a dynamic address
5. Leave --auto-approve off on the MCP server. It removes confirmation for deletes and for unmasking values