This article follows the official documentation. We haven’t tested this tool for a hands-on review.
When a coding agent runs project tests or a local service, it needs credentials. Doppler CLI supplies those credentials when it starts the command. Doppler stores secrets in project configurations. The CLI starts a command with the selected configuration’s secret values in the environment. Environment variables are named values that a running program can read from its process environment.
Doppler CLI manages secrets for many kinds of commands; it does not have a dedicated integration with coding agents. Configure access, then run the agent’s command through doppler run. This keeps secrets out of the command text, but the launched program still receives them. Use a configuration with only the access the task needs, and never paste secret values into the agent’s prompt. The Doppler CLI documentation covers setup, authentication, and command options.
Install and select a configuration
On macOS, Doppler recommends installing with Homebrew:
brew install dopplerhq/cli/doppler
Doppler also provides installation options for other operating systems and package managers in its official CLI repository.
To log in locally, run the interactive login command and follow the prompts:
doppler login
Doppler authenticates the CLI with an API key. For local development, log in with the CLI. For automation, use a service token, which limits access to one configuration in a project. Keep credentials in Doppler or the local authentication setup rather than including them in an agent prompt.
From the project directory, run:
doppler setup
Choose the Doppler project and the configuration that holds the needed secrets. The CLI saves those choices in a local doppler.yaml file, so later commands can use them. The CLI contacts Doppler when you select a project and configuration, but leaves the stored secrets unchanged. By default, login authentication applies from the root directory, which can make the token available to CLI projects in subdirectories. Check the documented login scope options if you need to limit where the token applies.
Run a command without printing secret values
Suppose a project’s selected configuration contains a secret named DATABASE_URL. To check that the CLI supplies it without displaying its value, run:
doppler run -- sh -c 'if [ -n "$DATABASE_URL" ]; then echo "DATABASE_URL is set"; else echo "DATABASE_URL is missing"; fi'
Replace DATABASE_URL with the actual secret name in the selected configuration. The -- marks where Doppler’s options end and the command begins. Doppler fetches the configuration’s secrets and gives them to the shell as environment variables. The shell prints only a status message, so the command’s output does not include the secret value.
For project tests, run the project’s test command with Doppler:
doppler run -- npm test
Doppler makes a network request to retrieve secrets before it starts the test command. The test command leaves Doppler’s stored secrets unchanged, and the test process receives their values. Test code or subprocesses can expose them if they print or transmit environment variables.
A realistic agent prompt for this example is: “Run the project tests with doppler run -- npm test. Do not print secret values or inspect them directly. Report the test result.” That instruction tells the agent what to do, but it does not limit the shell commands the agent can run. An agent with unrestricted shell access can run other commands that read secrets from the environment. Use a narrowly scoped configuration and service token when the agent should have access only to one configuration.
Know what the CLI exposes
Doppler CLI passes secrets to a process, so commands in different languages and frameworks can use them without separate integrations. Any command launched under doppler run can access those values. Avoid running untrusted scripts with secrets available, and do not ask an agent to print environment contents.
The CLI also supports secret management and audit-log commands, which are separate from the read-only test example. Give an agent only the access and task it needs. For automation, use a service token limited to the relevant configuration instead of a broad local login credential.
The commands above follow Doppler’s documented usage and have not been installed or tested for this article. Browse developer command-line tools in the Awesome CLI directory.