Branch 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
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

Personal Configs

Personal Configs provide every user that has write access to the environment with their own branch config that only they can access (e.g., for the dev environment, every user would have a dev_personal branch). This feature is enabled on all dev environments by default.

📘
Doppler projects created prior to the release of this feature will not have Personal Configs enabled by default on the dev environment.

You can control which branches this is enabled by default for by editing the Default Environments for your workplace. To do that, go to the Projects list view, click on the three dot menu near the top right of the page and select Default Environments .

Next, select which environments you would like this feature enabled on by default. After doing so and saving, all newly created projects will have this enabled on the selected branches automatically.

It can also be enabled on a per-environment basis by a user with Admin permissions for the project. To enable it:

Browse to the project you want to enable it on.
Click on the three dot menu next to the environment name and choose Settings.
Click on the Personal Configs slider to toggle the feature and then click Save.

After enabling Personal Configs, you'll see a new dev_personal branch config that's pinned to the top of the branch config list. Every user with write access to the dev environment will see one of these and it will be a private branch only they can see (changes they make will only affect their own branch).

Personal Configs help remove the need to create branch configs for each individual developer on your team. Now, you can simply enable this feature. Setup scripts for local development can target the dev_personal branch and it will only affect that particular Doppler user's personal config. This simplifies managing branches like this and also provides for an added layer of security since only the individual user in question can see the secrets in their personal config. You can further aid in initial project setup by creating a doppler.yaml file in your application root directory that will target the dev_personal branch config:

setup:
  - project: example
    config: dev_personal

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.

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.

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

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