Launch HN: Doppler (YC W19) – Easily manage your env vars and secrets

To be brutally honest (as if not already), Doppler makes me wonder why not simply focus on building on-top of open solutions like Vault. Considering there is no on-prem version of Doppler, you could essentially run Vault behind the scenes and provide the experience you are aiming to deliver with Doppler, giving you a marketing strategy for free ("Ready to run secret management with a focus on usability; the fastest zero to production option for 'Enterprise' secret management"), that doesn't require contrasting yourself ("We ARE Vault; it's a great tool, we made it easier"), and could even value-add or contribute back upstream (vs trying to cannibalize someone who could be your peer), and even reduces your engineering effort and the need to revalidate all the security primitives (and have 3rd parties do that for you just by their using it).

Disclaimer; I have nothing to do with HashiCorp, they've just done right by me, have been great to the community, and are always improving and learning from their mistakes. A nerve is struck when marketing tells people that they are using the wrong tool (without backing that up with data), and making comparisons to a protocol which has fallen to the wayside aside from limited use cases but otherwise is predominantly insecure.

This is awesome! The interface looks great, it is the UX I want. It boggles my mind why the major cloud providers who have parameter/secret management don't optimize their UX for the 90% use case of "I have an app, it runs in multiple environments, I want to vary the config by environment, and expose the config as environment variables, all with a simple and easy to audit interface".

On the feature request front, I'd like to be able to vary the config by location (e.g., region, but could be zone, rack, etc.). It is common to have a production app deployed to multiple regions (as Doppler itself does), and it is likely that 80% of the config will be the same between regions, but there may be region specific settings.

Which leads to the next thing I want, a hierarchy of config precedence: app default -> app+env -> app+env+location. So that the common settings don't need to be duplicated. Right now my guess is that to use Doppler with multiple regions I'd create environments like "prod-us-central1" and "prod-us-east1", but then 80% of the config will be the same between them.

Another thing that can be nice is to have a canonical value, and have multiple apps point to that value instead of having their own copy of the value. For example if you have a "production DB host" you can set that once, and multiple apps can point their DB_HOST or DATABASE_HOST at the "production DB host" canonical value. That way when the "production DB host" changes, it only needs to be changed in one place.

We actually support that exact use case natively. Each Doppler project has the concept of root and branch configs where branch configs inherit their secrets from the root. There is a root config for each environment (dev, stg, prd). More here: https://docs.doppler.com/docs/enclave-config-branching

In your specific case I would recommend creating a Doppler project for each app. Then you can add the common secrets to the "prd" root config. From there create branch configs for each locations:

prd (holds common secrets)

- prd_us_east_1 (inherits secrets from root plus hold us_east_1 specific vars)

- prd_us_central_1 (inherits secrets from root plus hold us_central_1 specific vars)

When you need to add/modify/delete a secret for all production configs, just modify the "prd" config.

Going off how any comment questioning their poor behaviour is being downvoted and even intentionally hiding some comments now, this being a ycombinator alumni project, and any meaningful discussion about the project itself being shut down in preference of their own developers' posting meaningless "i luv how perfect you made it and it beats everything"... Yeah, this project has gross all over it now, and really should not be trusted for something as crucial as secret management.

You could have chosen to make a product that could stand on its own two feet.

You could have chosen to respond to criticism over your lack of marketing experience and mistaken choice to misrepresent your competition instead of, you know, compete with them.

You could have learned from this experience, instead of trying to trudge ahead.

Please reread what moderator Dang said to you 3 hours ago.