I’ve just started my team using Doppler and so far it’s an absolute delight for both simplicity (particularly local development) and transparency (much more accessible, though safely so, than our previous Keybase-based hacks).
One thing I’m curious about is whether or not there are any plans to include support for “obviously-non-secret” configs in Doppler? One of the major niceties of Doppler for us is having a single place to manage configs that differ from one environment to the next, and to cleanly pull those during development and debugging as well, and while I could absolutely move environment variables into into Doppler, it feels wrong/awkward to shoe-horn non-secrets into the “secret store”.
Use Case: I’ve got a service that connects to about a dozen 3rd-party APIs, and for each API there are approximately 3 pieces of information to configure depending on which environment I’m deploying:
Base URL
Username
Password
In this example, I’d love for these pieces of information to be configured in the same place for clarity, but neither the URL nor the username are really secrets (username could and probably should be considered secret, but I digress).
I can tell you from experience that the benefits of having everything in Doppler is totally worth it, regardless of whether a variable is secret in nature or not. I think of Doppler as a SecretOps Platform, so it can store all manner of config and secrets equally well.
Also, we don’t, and won’t ever charge based on the number of secrets stored so there is no practical reason why you wouldn’t put everything in Doppler.
@Dangeruss just to add on to what @ryan-blunden has mentioned. We mainly call the variables in Doppler secrets to show that you can and should store sensitive data in Doppler. The added benefit of this approach is that your app config variables like a port, are just as secure as your sensitive data, like a database url. Plus you get to manage all of them (app config + secrets) in one dashboard. I hope this helps and super excited to have you on Doppler!
@ryan-blunden Thanks for the sanity check! That makes plenty of sense, and I felt that was likely a viable path forward, but I don’t know enough about canonical Doppler usage to know if that was a suggested usage pattern or if it was an anti-pattern.
Jumping on this thread. I’m also exploring options to store non-secret fields in Doppler. Think it might be good to share our use case.
Doppler & Gitops
We are implementing gitops (using ArgoCD) where all application configurations are stored in a single mono-repo. As we all know secrets should not be stored in git. Here we use your lovely service together with external secrets to manage this information. The other env depended fields are directly listed in the git repo. To give you some example field names:
We want application developers to have autonomy in deploying new versions of their apps. Sometimes new releases require new env variables. The challenge here is that we don’t want app developers to have direct write access to the cluster repo. This would mean they would have to create a PR to include the new env variables, decreasing their velocity.
If instead, we could give developers access to a a doppler project they would be free to add the additional configurations in a siloed environment (only having access to the applications they manage). The main downside here is that all information would be secret, making the configuration opaque for the ops team. Just thinking oud loud here, it would be awesome if we could somehow grab the non-secrets and commit them directly in the git repo. Could be an automated CI step
One crazy powerful feature that we would love to use is also the secret referencing feature. E.g. we would only have to define public_endpoint once per project and all other projects could reference this field. So only one change would update all references!
@boedy Thanks for sharing your use-case! As you mentioned, shared config values like these would work great in a dedicated project for them that are then referenced cross-project. Once you have that setup, if your ops team needed access to see what values were set, they could run doppler secrets using the access token of the deployment environment. Alternately, if you didn’t want them to see the actual secret values vs configuration values, then you could provide them access to the shared project and they could run doppler secrets against that (or just view it in the dashboard) to see what’s in use.
Would that work for you? Is there a particular reason you find including those values directly in git desireable?
@watsonian I preferably would want to have it in git as the rest of the configuration is also defined there. Having non-secret configuration spread out to various parts, makes the configuration fragmented and harder to reason about.
