doppler-secrets

Doppler CLI - local access + secret injection

Doppler stores secrets per project and config (environment); a service token is scoped to exactly one project+config and doesn't need an explicit --project/--config flag once set - the CLI resolves both from the token itself.

Setting up local access from a token the user gives you

A dp.st.... string is a live secret the moment you see it - treat it like any other credential: don't echo it back, don't write it into a repo file, don't paste it into a memory/notes system. Configure it directly into Doppler's own local config store, scoped to the directory you're working in (so it doesn't leak into unrelated projects on the same machine):

doppler configure set token "dp.st.xxx" --scope /path/to/repo

After that, plain doppler <command> run from (or under) that path picks the token up automatically - no env var, no flag, and nothing written to the repo itself (doppler configure stores it under Doppler's own config, not project-local).

Verify it actually works and see what project/config it resolves to before relying on it:

doppler me                     # confirms the token identity
doppler projects               # shows which project it's scoped to
doppler secrets --only-names   # lists secret NAMES ONLY - safe to run/paste, never shows values

Reading secrets into a command

Prefer doppler run -- over doppler secrets get + manual export - it injects everything as env vars for the duration of one command and nothing leaks into shell history or a .env file:

doppler run -- bash -c 'curl -H "Authorization: Bearer $SOME_TOKEN" https://example.com'

Never echo/print a secret value to confirm it's "there" - use --only-names (above) or check the effect of using it (e.g. the API call suceeding) instead.

Read-only vs read/write tokens

A service token's scope (read-only vs read/write) is set when it's created in the Doppler dashboard, and there's no CLI-visible signal that a token is read-only until you actually try to write and get: