The Doppler CLI provides access to your secrets in every environment, from local development, CI/CD, staging, and production. It is a lightweight binary available for every major operating system, package manager, and Docker.
# Prerequisite. gnupg is required for binary signature verification brew install gnupg # Next, install using brew (use `doppler update` for subsequent updates) brew install dopplerhq/cli/doppler
# winget is the recommended installation method winget install doppler.doppler # Scoop is also supported scoop bucket add doppler https://github.com/DopplerHQ/scoop-doppler.git scoop install doppler # WSL is supported. Just follow the Shell Script process or the process # for the OS you're using inside WSL (it defaults to Ubuntu). # Git Bash is also supported mkdir -p $HOME/bin curl -Ls --tlsv1.2 --proto "=https" --retry 3 https://cli.doppler.com/install.sh | sh -s -- --install-path $HOME/bin # When using Git Bash, your initial login and other operations requiring # interactive input will need to use `winpty` due to this bug: # https://github.com/skratchdot/open-golang/issues/34 # # winpty doppler login
wget -q -t3 'https://packages.doppler.com/public/cli/rsa.8004D9FF50437357.key' -O /etc/apk/keys/[email protected] echo 'https://packages.doppler.com/public/cli/alpine/any-version/main' | tee -a /etc/apk/repositories apk add doppler
# Debian 11+ / Ubuntu 22.04+ sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl gnupg curl -sLf --retry 3 --tlsv1.2 --proto "=https" 'https://packages.doppler.com/public/cli/gpg.DE2A7741A397C129.key' | sudo gpg --dearmor -o /usr/share/keyrings/doppler-archive-keyring.gpg echo "deb [signed-by=/usr/share/keyrings/doppler-archive-keyring.gpg] https://packages.doppler.com/public/cli/deb/debian any-version main" | sudo tee /etc/apt/sources.list.d/doppler-cli.list sudo apt-get update && sudo apt-get install doppler # Older versions of Debian/Ubuntu sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl gnupg curl -sLf --retry 3 --tlsv1.2 --proto "=https" 'https://packages.doppler.com/public/cli/gpg.DE2A7741A397C129.key' | sudo apt-key add - echo "deb https://packages.doppler.com/public/cli/deb/debian any-version main" | sudo tee /etc/apt/sources.list.d/doppler-cli.list sudo apt-get update && sudo apt-get install doppler
sudo rpm --import 'https://packages.doppler.com/public/cli/gpg.DE2A7741A397C129.key' curl -sLf --retry 3 --tlsv1.2 --proto "=https" 'https://packages.doppler.com/public/cli/config.rpm.txt' | sudo tee /etc/yum.repos.d/doppler-cli.repo sudo yum update && sudo yum install doppler
# Does not rely on package managers # Recommended for ephemeral environments (e.g. CI jobs) # Supports Linux, BSD, and macOS # Requires Curl & GnuPG: # Alpine: apk add curl gnupg # CentOS/RHEL: yum install -y curl gnupg # Ubuntu/Debian: apt install -y curl gnupg (curl -Ls --tlsv1.2 --proto "=https" --retry 3 https://cli.doppler.com/install.sh || wget -t 3 -qO- https://cli.doppler.com/install.sh) | sudo sh
Now, verify the Doppler CLI was installed by checking its version.
You can also upgrade the CLI to the latest version at any time.
In order for the Doppler CLI to access secrets for your projects, it needs an access token. For local development, we use the
doppler login command which will open a browser window and ask you to authenticate.
This only needs to happen once per workplace. If you have multiple workplaces, you can scope each login to a separate directory.
Now that the CLI is installed, let's configure it for use with a project in your development environment.
In Doppler, access to a project's secrets is scoped to a specific directory in your file system. This allows you to fetch secrets for multiple projects on a single machine.
Have you created a project?
If you or your team has yet to create a project, learn how in our Create a Project guide, as you'll need a project for the upcoming steps.
For each project, the setup command must be run, usually at the repository root level.
# Change to your project's directory cd ./your/project/directory # Select project and config doppler setup
You can optionally pre-configure the Doppler project and config to use for local development by creating a
doppler.yaml file, either in the root of the repository, or in each app folder if using a monorepo. You can specify just the project, or the project and config, but we recommend setting both to make setup as easy as possible. Here's an example:
setup: - project: example config: dev_personal
Now you'll get an enhanced experience when running
You can get more detailed information about how project management works in the CLI from our Secrets Setup Guide.
Fetch the latest versions of your secrets for your project and selected config using the run command, injecting them as environment variables into the running process from your command or script.
doppler run -- your-command-here
doppler run --command="./configure && ./process-jobs; ./cleanup"
Because Doppler injects secrets as environment variables, it works for any language, framework, platform, and cloud provider.
const secret = process.env["SECRET_NAME"]
secret = os.getenv("SECRET_NAME")
secret = ENV["SECRET_NAME"]
secret := os.Getenv("SECRET_NAME")
String secret = System.getenv().get("SECRET_NAME")
$secret = $_ENV["SECRET_NAME"]
secret = env::var("SECRET_NAME")
var secret: String = System.getenv("SECRET_NAME")
def secret = System.getenv("SECRET_NAME")
char const* secret = getenv("SECRET_NAME");
To run one-off commands using a secret in Doppler, please make sure to escape the secret or use single quotes. You will need to do this to guard against shell parsing the variable before the run command executes.
doppler run --command="echo \$SECRET_NAME"
doppler run --command='echo $SECRET_NAME'
echo $(doppler secrets get SECRET_NAME --plain)
If you are on the Team plan, the Doppler CLI can automatically restart your process when your secrets change using the
doppler run --watch -- your-command-here
doppler run --watch --command="./configure && ./process-jobs; ./cleanup"
Now that Doppler is injecting secrets as environment variables, it's best to remove all application code relying on
.env files as well as
.env files that may still exist locally.
This instantly improves security by removing the storage of unencrypted secrets from your file system and avoids potential confusion as to what the source of truth is for the loading of environment variables.
Now that you have local development running, let’s set up authentication for staging and production with Service Tokens or connecting an integration.
Updated 11 days ago