Skip to content

Doppler

Doppler organises secrets into projects, each with configs such as dev, stg, and prd. Doppler.Secrets downloads one config into the stack’s secret providers, without writing anything to process.env or to disk.

import * as Doppler from "alchemy/Doppler";


secrets: [
  Doppler.Secrets(({ stage }) => ({
    project: "my-app",
    config: stage === "prod" ? "prd" : "dev",
  })),
],

Browser login and personal tokens are not scoped to a single config, so project and config are required with those. A service token is scoped to one config, so both may be omitted. Doppler’s branch configs map neatly onto preview stages if pr-42 should inherit from dev.

Connect your account

Section titled “Connect your account”

Run alchemy profile edit --add Doppler. Login opens the Doppler dashboard; approve the request and the token is stored in your profile. It shows up in Doppler as Alchemy (<your hostname>), and alchemy profile edit --remove Doppler revokes it. API token takes a service or personal token you already have. Non-interactively:

Terminal window
alchemy profile edit --add Doppler --method api-token --set token=env:DOPPLER_TOKEN

In CI

Section titled “In CI”

Profiles are never consulted in CI; the environment decides. The simplest is a service token in DOPPLER_TOKEN:

- run: bun alchemy deploy --stage prod --yes
  env:
    DOPPLER_TOKEN: ${{ secrets.DOPPLER_TOKEN }}

On Doppler’s Team and Enterprise plans, use OIDC to avoid storing a long-lived Doppler token. Create a service account identity that trusts your platform’s OIDC issuer and set DOPPLER_IDENTITY_ID; Alchemy exchanges the platform’s own identity token for a short-lived Doppler token on every run:

jobs:
  deploy:
    permissions:
      id-token: write   # lets the job request an OIDC token
      contents: read
    steps:
      - run: bun alchemy deploy --stage prod --yes
        env:
          DOPPLER_IDENTITY_ID: ${{ vars.DOPPLER_IDENTITY_ID }}

Alchemy detects GitHub Actions, Vercel, and supported Google Cloud runtimes. Each platform must be configured to issue a token whose issuer, subject, and audience match the Doppler identity’s trust policy. Use your job’s actual subject claim when configuring that policy; it can vary with the repository, branch, environment, and organization settings.

For GitLab, name the token in the job’s id_tokens block DOPPLER_OIDC_TOKEN and set its aud to the audience trusted by Doppler. SIGSTORE_ID_TOKEN is also detected when GITLAB_CI is set. On other platforms, DOPPLER_OIDC_TOKEN accepts an explicitly supplied token.

DOPPLER_OIDC_AUDIENCE sets the requested audience on GitHub Actions and Google Cloud. It is required for Google’s metadata identity endpoint. It does not change the audience of tokens already supplied by Vercel, GitLab, or DOPPLER_OIDC_TOKEN.

DOPPLER_TOKEN wins over DOPPLER_IDENTITY_ID, and either wins over a profile, so a teammate can deploy with a token they were handed. alchemy provider check-env lists these variables.

Where next

Section titled “Where next”