Skip to main content
Doppler holds the values that must be shared across the cloud — and secret-zero.

​
Its job in the four-tier model

Doppler is T3, the strict cloud tier of the four-tier secrets model. Its role has narrowed to two things:
  • Cloud-shared keys-to-the-kingdom. Secrets that genuinely need a hosted, cross-environment source of truth (GitHub Actions distribution, CI-shared provider keys). These are the rare high-blast-radius values — an AI agent reaches them only under explicit, per-use human approval, never as part of a routine flow.
  • Secret-zero for T2. Doppler holds the material that bootstraps the OpenBao runtime manager: its static seal key (for auto-unseal) and the first AppRole secret_id an agent presents to authenticate. This is why T3 is kept small and tightly scoped.
Everything an always-on machine consumes routinely resides in T2, where credentials are self-hosted, short-lived, and readable with zero interactive prompts. Doppler serves as the small, human-gated cloud tier plus the bootstrap root.

​
What goes in Doppler

  • AI provider keys: AI_TOKEN, COPILOT_GITHUB_TOKEN, HF_TOKEN, plus provider-specific keys when a tool cannot use the shared AI_TOKEN convention.
  • GitHub App credentials: GH_APP_CLAUDE_BOT_*, the SSH signing key for Actions-signed commits.
  • Slack webhooks (broadcast and per-channel).
  • Infrastructure runtime config: database passwords, RunsOn license, Qdrant credentials.

​
What does not go in Doppler

  • SSH keys for git auth (lives in Bitwarden + ssh-agent).
  • Recovery codes, account passwords, age-key escrow (Bitwarden).
  • Anything an AI tool must never read (Bitwarden vault).
  • macOS-only GitHub PATs (Keychain — see macos-keychain).

​
Project / config layout

Three Doppler projects, three delivery modes — each lands in a different consumer.
Doppler projectDelivery modeConsumer
secrets-syncAuto-sync → GitHub Actions secrets on the secrets-sync reposecrets-sync workflow fans out (Tier 1)
infra-project/prdRuntime fetch via dopplerhq/secrets-fetch-actionInfra CI jobs (Tier 2 — values never sit in GitHub)
ai-ci-automation/prddoppler run -- wrapper at subprocess launchLocal dev + the doppler-mcp bridge

​
Runtime fetch via GitHub Actions

For Tier 2 secrets that must never sit in GitHub Actions stores: 
- uses: dopplerhq/secrets-fetch-action@v1
  with:
    doppler-token: ${{ secrets.DOPPLER_TOKEN }}
    inject-env-vars: true
That DOPPLER_TOKEN service token is itself a Tier 1 secret distributed by secrets-sync to the two _infra_repos: ansible-proxmox-apps and tofu-runs-on.

​
Local-dev chain

The canonical chain pairs AWS Vault with Doppler so an MFA-protected AWS session wraps the Doppler injection: 
aws-vault exec tf-proxmox -- doppler run -- terragrunt plan
Secrets injection happens at terragrunt’s subprocess launch — no values touch your shell history or environment. For OpenTofu variables specifically, Doppler’s name-transformer flag prefixes everything as TF_VAR_*: 
doppler run --name-transformer tf-var -- terragrunt plan

​
Anti-patterns and best practices

  • Do not export DOPPLER_TOKEN in ~/.zshrc. Use the doppler-mcp wrapper or doppler login interactive auth. Tokens persisted in the shell env are reachable by every later command.
  • Do not store the same value in both Doppler and the Keychain. Pick one source of truth per secret. The Keychain is for tokens that only the macOS host uses (GitHub PATs); Doppler is for tokens that CI also needs.
  • Rotate the service tokens at 90 days. The rotation runbook lives in secrets-sync.
  • Audit log: enable Doppler’s per-project audit log; review on every PAT/key rotation.

​
See also

  • Tools comparison — the four-tier model and where T3 sits.
  • OpenBao — the T2 runtime manager Doppler bootstraps.
  • secrets-sync — Tier 1 distribution.
  • aws-vault — the wrapping layer for the local-dev chain.
  • BWS — alternative for AI-specific OAuth tokens where Doppler is not yet wired up.
  • docs.dryvist.com — dryvist-internal project / config names.