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).
  • Cloud/SaaS licensing that genuinely needs a hosted source of truth (e.g. the RunsOn license). Self-hosted app-service credentials — database passwords, Qdrant, and the like — live in OpenBao (T2), not here.

​
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).
  • Service API keys that only the macOS host uses (Keychain — see macos-keychain).
  • GitHub tokens — they are minted on demand and never stored (see GitHub access).

​
Project / config layout

Three Doppler projects, three delivery modes — each lands in a different consumer.

​
Runtime fetch via GitHub Actions

For Tier 2 secrets that must never sit in GitHub Actions stores:
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.

​
OpenTofu boundary

Doppler is not in the active OpenTofu plan or apply path. Terrakube uses native OpenBao identities, dynamic provider credentials, and ephemeral values. Do not copy an IaC credential from Doppler into a Terrakube workspace variable.

​
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 keys that only the macOS host uses; 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 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.
  • IaC tooling — the Terrakube and OpenBao execution path.
  • BWS — alternative for AI-specific OAuth tokens where Doppler is not yet wired up.
  • docs.dryvist.com — dryvist-internal project / config names.