GuidesAPIStatusCommunitySign Up

Branch Configs

Learn how to override secrets in your configs.

Projects have 3 default configs: dev, stg, and prd. You can think of these configs as the master branch or root config for their respective environments, where all future configs branch off of. There are many reasons why you may want to create a branched config such as:

  • Dedicated configs for each cloud deployment (AWS, GCP, Azure, etc..)
  • Development of a new feature that requires additional secrets not yet released
  • Provide personal branches for your developers to override secrets for their local development environment
  • Securely sharing a branched config by sharing the name with a coworker
  • Easy promotion of those change by adding them to Root Configs
  • Extensive audit logging and versioning

Creating a Branched Config

Creating a branched config is fast. To get started, go to a project and then click on the + button under the environment name. This will open up a modal to provide a name for the config which will be prefixed with the environment name.

1646

Duplicating a Config

It's possible to duplicate an existing root or branch config. This will create a new branch config that will inherit from the same root config that the source config is associated with. This new branch config will inherit changes from the root config just like any other branch config, but will contain all the same modifications the source config that was duplicated had overlaid.

To duplicate a config, find the config you want to duplicate in your Project and then click on the 3-dot menu on the top right corner of the config entry. Then choose Duplicate from the list.

828

You'll be prompted to enter a new name for the duplicate config:

538

Sharing a Config

When working on large complex features, you may need a branched config during development that your team can share. Sharing a config is fast and secure, all your peers need to get started is the name of the config.

Let's walk through an example. Your peer Tim is working on your new billing system which adds support for Stripe. To do so he creates a new config either in the dashboard or in the CLI.

doppler configs create dev_stripe_billing

Now that the config is created, he will set the dev_stripe_billing config as his primary for the current directory. Now when he calls commands in the future, the Doppler CLI will automatically use the dev_stripe_billing when he is in that directory.

doppler configure set config=dev_stripe_billing

Tim is ready to start integrating Stripe so he adds their API key to the config's secrets.

doppler secrets set STRIPE_API_KEY=sk_test_9YxLnoLDdvOPn2dfjBVPB

Great! We now have a config with the new Stripe API key added. From here on he can share the branched config with the rest of the team. If a team member wanted to test out that config they can pass the config name in on the run command.

doppler run -c dev_stripe_billing -- ./your-command-here

And that's it! When the feature is ready to be rolled out to master, they can add the Stripe API key to Root Configs and delete the feature branch config.

# Add secret to Development Root Config
doppler secrets set -c dev STRIPE_API_KEY=sk_test_9YxLnoLDdvOPn2dfjBVPB

# Add secret to Staging Root Config
doppler secrets set -c stg STRIPE_API_KEY=sk_test_9YxLnoLDdvOPn2dfjBVPB

# Add secret to Production Root Config
doppler secrets set -c prd STRIPE_API_KEY=sk_live_SinMsVYhdHurkdOrVKWCd

# Delete branched config
doppler configs delete dev_stripe_billing

Updated 6 months ago

What’s Next