> ## Documentation Index
> Fetch the complete documentation index at: https://docs.jacobpevans.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Doppler

> The T3 strict cloud tier — cloud-shared keys-to-the-kingdom under human approval, and the holder of secret-zero that bootstraps the T2 runtime manager.

> 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](/security/comparison). 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](/security/tools/openbao): 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](/security/tools/macos-keychain)).

## Project / config layout

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

| Doppler project        | Delivery mode                                                 | Consumer                                                             |
| ---------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------- |
| `secrets-sync`         | Auto-sync → GitHub Actions secrets on the `secrets-sync` repo | [`secrets-sync`](/security/secrets-sync) workflow fans out (Tier 1)  |
| `infra-project/prd`    | Runtime fetch via `dopplerhq/secrets-fetch-action`            | Infra CI jobs (Tier 2 — values never sit in GitHub)                  |
| `ai-ci-automation/prd` | `doppler run --` wrapper at subprocess launch                 | Local dev + the [`doppler-mcp`](/security/local-ai-isolation) bridge |

## Runtime fetch via GitHub Actions

For Tier 2 secrets that must never sit in GitHub Actions stores:

```yaml theme={null}
- 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:

```bash theme={null}
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_*`:

```bash theme={null}
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](/security/secrets-sync#rotation-cadence-best-practice).
* Audit log: enable Doppler's per-project audit log; review on every PAT/key rotation.

## See also

* [Tools comparison](/security/comparison) — the four-tier model and where T3 sits.
* [OpenBao](/security/tools/openbao) — the T2 runtime manager Doppler bootstraps.
* [secrets-sync](/security/secrets-sync) — Tier 1 distribution.
* [aws-vault](/security/tools/aws-vault) — the wrapping layer for the local-dev chain.
* [BWS](/security/tools/bws) — alternative for AI-specific OAuth tokens where Doppler is not yet wired up.
* [`docs.dryvist.com`](https://docs.dryvist.com) — dryvist-internal project / config names.