← ClaudeAtlas

dopplerlisted

Development-time secret injection with Doppler — secrets reach a process as environment variables and are never read from a committed file, `doppler run --` wraps the mise task rather than the application, and nothing here is in the deployed path. Auto-applies when editing doppler config or a mise config that wires it.
virajp/ai-plugins · ★ 1 · AI & Automation · score 78
Install: claude install-skill virajp/ai-plugins
# Doppler — development secrets only **Doppler is a development tool.** It is how a developer's laptop gets the credentials the app needs before any cloud secret manager is in the picture. It is **not** the production answer and must not be presented as one: in CI the injector is the CI system's secret store, and in production it is the cloud plugin's secret manager (`gcp` → Secret Manager, `cloudflare` → Workers secrets). A product that needs Doppler at runtime has moved a dev tool into production. There is deliberately **no `secrets` plugin** in this marketplace. Dev secrets are `devtools`; production secrets belong to whichever cloud plugin the project deploys on. ## The one rule that outranks the mechanism **Secrets are injected into the process environment. Nothing is read from a committed file.** That holds whichever injector is in use, in every environment, and it is the rule the mechanism exists to serve — not the other way round. Two consequences worth stating plainly: - A `.env` file checked into the repo is a leak, not a convenience. If one exists, it is `gitleaks`' finding and it is not waived. - A secret that is only ever an env var can change injector without touching a line of application code. That portability is what keeps Doppler a dev concern rather than a dependency. ## Wrap the task, not the application ```sh doppler run -- mise run dev doppler run -- mise run test:e2e ``` Wrap the **mise task**, never the application binary and never a she