How to manage secrets for 40 git repositories in doppler

hi all, we have quite a few git repositories with github actions. we’d like to use doppler as the central place to manage these secrets. we have different types of repositories, like:

  • some repositories with lambda functions with secrets which refer to dev/staging/production deploy
  • some repositories with definitions for kubernetes services (code & charts) with secrets which refer to dev/staging/production image build and deploy
  • some repositories with docker base images with secrets which refer to dev image build
  • an infrastructure repository with terraform code which needs credentials for dev/staging/production terraform applies

These credentials are often AWS credentials - which we’d like to rotate automatically via Doppler.

So the naive attempt was:

  • one project: github
  • one environment: github-actions with all the secrets (in particular rotated secrets)
  • one branch per git repository which defines all the secrets

The brick wall we hit was:

  • rotated secrets are forcefully inherited in all branches (git repositories) which means that our terraform AWS keys would be distributed to all git repositories, which is really not desirable.

obviously we can split our list of repositories by ‘flavour’ (infra, lambda, kubernetes, …) and map these to doppler. what is the best pattern here you have encountered? one additional complication is: I’d like to rename the key names of the rotated secrets as well.


Hi @yasinzaehringer!

Welcome to the Doppler Community!

We actually have a doc that discusses workplace layout in depth that you might find useful here:

Generally speaking, it’s pretty common for each of your applications/services to have their own project in Doppler. You can then create separate “global” projects for shared secrets and leverage cross-project secret referencing to pull in shared secrets you need to your application/service projects. Doing this also provides you with an easy way to rename the rotated secrets as well. Those secrets are created in the “global” project and then brought into the projects they’re needed in via secret references – the actual secret name that has the reference can be whatever you want!

Would that approach work for you?


Hi Joel! I implemented it yesterday and it worked very nicely. Thanks!