Multi-project Doppler Setup


I have a typescript project where it has some configs and I am storing in Doppler.

However, I have another project that needs to share only some of the secrets with it.

So I split the Doppler project to multiple projects to make it more flexible.

But I met with a problem that I cannot setup multiple service tokens in one work directory, as the previous ones will be overwritten.

Is it a bad practice to have multiple Doppler projects in one directory? What’s the recommendations for my use case?

Hey @zidong !

I’ve been through this some time ago, and Doppler released a feature to ease those kind of setups, please take a look here :

I think you can edit your local doppler.yaml like the following :

  - project: frontend
    config: dev
    path: frontend/
  - project: backend
    config: dev
    path: backend/

Hey @zidong!

Welcome to the Doppler Community!

Assuming you weren’t needing these all in the exact same directory and instead needed them in subdirectories for a monorepo setup, then what @Grraahaam mentioned should help you out! It’s worth noting that although that feature is merged, it hasn’t yet been released (hopefully we’ll see that come out this week!).

If you do need to pull secrets from multiple projects+configs for a single directory/service, then the only way to accomplish that right now is to create a new config that includes the secrets from the other projects using secret referencing.


@watsonian @Grraahaam thank you both! what I ended up doing is to create multiple environments in one Doppler project and create service tokens for each environment.

I created a .dp_tokens file to store the service tokens:

env1: xxx
env2: xxx

then I wrote a shell script to download and merge the secrets from different envrionments:

fetch_secrets() {
    # Get the first parameter as the config
    local config="$1"
    doppler_token=$(get_doppler_token "$config")

    echo "# $PROJECT.$config" >> $ENV_FILE
    # set token for config
    echo $doppler_token | doppler configure set token
    doppler secrets download --project $PROJECT --config $config --no-file --format env-no-quotes | grep -v '^DOPPLER_' >> $ENV_FILE
    echo "" >> $ENV_FILE

for arg in "${INPUT_ARGS[@]}"; do
      fetch_secrets "$arg"

any suggestions?

Hi @zidong,

That’s certainly one way to accomplish this. My main concerns there are twofold:

  1. Storing your tokens in a plain text file on-disk is not really recommended.
  2. Storing your secrets in a plain text file on-disk is also high discouraged (which I assume is what’s happening with >> $ENV_FILE – correct me if I’m wrong!).

Some ways you could potentially make this more secure:

First, have a Doppler project that contains the Doppler service tokens you’re going to use and inject the service token for access that project into the environment as DOPPLER_TOKEN. Then, execute your script using Doppler and have it pull down the tokens that you’d then use inside the script. This may be a little roundabout, but would be more secure. That’s purely if you’re using this in a deployment environment though. If you’re running this locally for development, you can just use your CLI token to accomplish most of this without needing separate service tokens for each project.

Second, regarding combining secrets – I would probably still recommend creating an additional config that uses secret referencing to pull in whatever secrets are needed. Are you able to elaborate a bit more on specifically what you’re accomplishing here? (i.e., what’s being stored in the separate configs, what kind of service are you deploying, etc.)



The monorepo support for setup files has been released and is in v3.57.0 of the CLI!

1 Like

thanks for the suggestions!

For second, using reference is not really what we want. Say we have a project A that have 100 secrets and project B that reuses 20 secrets from A.

It’s error prone to reference all the 20 secrets from A and hard to maintain.

Is there a way to reference an entire project?

Unfortunately, there isn’t currently. This is something that’s come up a lot on our end and is almost certainly something we’ll add at some point down the road. We don’t have any kind of timeline for that right now though. Sorry about that!


1 Like

Unfortunately, we had to roll this change back in v3.57.1 due to an issue it caused with interactive invocations of doppler setup. We’ll get it re-released after we’ve had a chance to review it further.

No worry! thanks for the info.

Okay, we re-released the feature in v3.60.0! After upgrading you should be good to go.