Doppler is an easy way to manage and share environment variables and secrets -- things like API keys, database credentials, feature flags, and configuration like a port or a hostname. We’ve heard it's “GitHub for secrets”.
While working at Uber and small startups, managing app config via env vars really sucked. Simple options like .env files were a nightmare to keep updated. Enterprise tools like HashiCorp Vault and AWS Parameter Store felt like we were stuck using FTP instead of Dropbox!
For the past 2 years, we’ve been heads-down building a secrets manager we actually want to use. For our customers, it's now their central source of truth for secrets and app configuration. They use Doppler to quickly organize and sync secrets with teammates and across infra, from local to prod on every stack. It has the features you'd want in a secrets manager, like sharing, audit logs, versioning, and integrations with major cloud providers (AWS, GCP, Heroku, Docker, Netlify, Laravel Forge, etc.).
We’re deeply committed to strong security controls and highly available infra. Best-practices like data tokenization, security driven design, and external pentests help keep us secure: https://doppler.com/security. And fully managed encrypted fallbacks in your infra means your secrets are always available, even in the rare case we aren’t.
To support our community, we’re committed to offering a community plan that's free forever for unlimited users. Paid plans start at $6/seat/month.
For visual learners like me, here's a 4-min video of us installing Doppler: https://vimeo.com/447918575.
Take a look if you're curious: https://doppler.com. Let us know what you think!
How does it fair against Vault? Vault is self hosted and open source.
Does everyone in this thread know the founder or something? No one is asking these and they're in my view the absolutely most important questions.
Then I looked at the API documentation and it seems, no, you're being encouraged to send your secrets verbatim over the Internet.
I understand how this invites comparisons with the CSP secrets management products (e.g. AWS Secrets Manager), but it seems strictly worse from a number of perspectives:
* blast radius: if I'm a multi-cloud, or hybrid-cloud, property then compromise of one environment doesn't necessarily lead to compromise of the others; if I have all my eggs in one basket, like Doppler, then it seems like it does.
* Internet traversal: if I'm using something like AWS Secrets Manager from within AWS, I can entirely avoid having to traverse the Internet for my secrets by using VPC endpoints. Having to cross the Internet just means I'm exposed to more bad actors, an increased variety of attacks and also operational risk factors unrelated to security.
* (probable/possible?) segregation of duties concerns: the design of products like AWS Secrets Manager means that some kind of active collusion across product teams within AWS is required to create inappropriate disclosures and to conceal that disclosure. If secrets management is the only product line, that seems less likely to be sustainable.
License the software, let me deploy and manage it.
It is different in at least one important way: secrets (Such as private keys) are used to secure things (Such as code, data, or conversations) and thus are usually given a higher security priority (Like much tighter access control).
I'm also familiar (but never used) Envkey, which I think might also be from the YC alumni? but I'm not sure...
Shameless plug: I created an open-source tool called envwarden[0], which is really just a simple wrapper around the Bitwarden[1] CLI (also open-source). envwarden helps you manage your server secrets and other variables inside your Bitwarden password manager.
Definitely not as polished as neither Doppler nor Envkey, but just another (open) alternative I guess :)
There's certainly room for alternatives in this space! I'd say the major difference from my perspective is that EnvKey uses client-side end-to-end encryption and a signed desktop application instead of a web app interface, giving it quite a different security and trust model than Doppler.
Because Doppler is delivered as a web app, its users are implicitly trusting Doppler's servers on every request. If their servers were compromised, user data would be at risk despite any tokenization or encryption they might be using on the back end, because the attacker could simply inject malicious javascript into the html of the initial web app request. EnvKey's architecture doesn't allow this.
[0] https://docs.doppler.com/docs/security-fact-sheet#data-flow-...
I saw the demo video which looks great - one question though, how does this work with Heroku add-ons? If you configure Heroku Postgres for example, a DATABASE_URL env var gets automatically added. This variable can change (e.g. when Heroku applies a patch to your DB and restarts it). Is the sync two way, or do you expect applications to have two sets of environment variables (split across Doppler and Heroku)?
"dev": "doppler run -- nodemon --exec \"heroku local\" --signal SIGTERM"
For managing our production secrets, we're obviously a bit more hesitant to give those over to an additional third party. Heroku secrets management works well for us, so I think we will continue to use that for now. But for managing development secrets, this is perfect.
Here is short example: https://github.com/stumyp/ope
[0] https://github.com/marketplace/actions/install-doppler-cli
However, please stop trying to contrast yourself with these analogies. Owncloud and Nextcloud both have hosted OR on-prem versions
They did compare it to all of these
NextCloud: self-host OR pay for a managed option (this means someone runs it for you.) ownCloud: self-host OR pay for a managed option (this means someone runs it for you.)
He compared it to Dropbox, Nextcloud, and ownCloud.
What happens if Doppler is down or if there is a SNAFU when syncing the env in production?
1. Don't go down! We run two independent compute clusters on different managed infrastructure products (GKE and GAE) and route between them at the DNS layer to help avoid downtime
2. We store local encrypted fallback files on your infra via our CLI [1]. These local fallback files are fully managed and allow the CLI to continue to serve your secrets, even if our API or your internet connection is down. I use this heavily whenever I'm on a flight
3. More coming soon! (really)
Do you have thoughts about using this on other systems. Bare metal, VMWare, or maybe even a cloud service without the use of their secret manager? I know it may seem odd, but those are cases where I would think this would be even more useful.
How about the use of client certificates for user authentication. Or maybe kerberos tokens for server authentication.
Client certificates are an interesting use case that we'd be open to, but admittedly the request hasn't come up a whole bunch yet from our customers. Same with Kerberos tokens- this would definitely be used in the Enterprise space, which is an offering we're still in the early stages of. Other forms of identity-based auth would fall into this category as well.
An enterprise (self hosted) offering is probably what my admittedly niche uses would require. Just kind of spit-balling some ideas really, to see where things are headed.
Any concept of separation of duties? Like Doppler level Owner / Admins who don't have access to the configs, they just create projects and give users access to edit the configs with them. Or audit ability, where someone can't see the secrets, just who made changes when?
How long is the history on each config? Is it permanent history? Or just some time frame?
Or how about universal configs? Occasionally I have something like an api url, a git repo, or an artifactory url. Which rarely change, but would like synced across all environments in a project. Or even across projects. I know I could cut and paste the value across environments, but mistakes can be made.
Aside from a feature-by-feature comparison, I feel that both SecretHub and Doppler do a great job of:
1) making secrets management simple enough so any engineer can use it with limited overhead.
2) making secrets management work throughout your entire stack – from development to production – and not just inside one ecosystem.
Finally, we see a trade-off between usability and security being made. At SecretHub, we feel end-to-end encryption is a must for any managed service handling passwords, API keys and other secrets.
One thing we strived for during the design phase was to make it feel like a tool you would want to use. From the colors to the bold fonts and large screenshots. I personally was inspired by what Stripe and Slack did, take a traditionally "unsexy" space and aim to make it "sexy".
The Show HN guidelines (which also apply to Launch HNs) have a few things to say about this: https://news.ycombinator.com/showhn.html, and of course the site guidelines do also: https://news.ycombinator.com/newsguidelines.html.
However `Enterprise tools like HashiCorp Vault and AWS Parameter Store felt like we were stuck using FTP instead of Dropbox!` is in itself bashing other peoples' work, and misleading prospective users.
It's not alright to mislead people, and the trends over the years of new engineers without a ton of experience looking at a battle-hardened, vetted system with their one specific use case and no understanding of the endless numbers of refinements that resulted in the predominant solution that solves more problems and edge cases than just their partially understood use case, is... why we have shit like this coming out of Apple (for example)
https://lapcatsoftware.com/articles/macl.html
Despite being a millennial, I can't help but agree with this sentiment:
> When I try to list the contents of the Documents folder in Terminal, I get a permissions dialog, because Millennials are killing Unix.
Understand _why_ things are done the way they are before you write them off as inferior and re-invent the wheel, otherwise you'll simply discover all the things you didn't understand previously, and create effectively the same solution, only poorly implemented and without all the vetting and refinement that went into what was already there before you came and "did it better".
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.
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.
Chamber is an open source wrapper for AWS Parameter Store. You add a secret by doing:
`chamber write ENV_NAME SECRET_NAME SECRET_VALUE`
And when you want to execute a command with those values in your environment...
`chamber exec ENV_NAME -- yarn start:prod`
Parameter Store comes with auditing tools and versioning. Chamber uses KMS for encryption. Also, you can control permissions (including namespacing) with IAM.
My question is - what does Doppler provide that would make me want to switch? I'm weary about letting someone else own our secrets.
Your product looks great. I watched the demo on the home page and I'm impressed.
I'm definitely going to give a try. The developer integration seems awesome.
Congratulations on the release.
> Doppler empowers engineers and their teams too quickly set up a secure way to store and manage their sensitive application secrets like API keys, database urls, certifications, etc... through a dashboard, API, and command line tool.
should be "to quickly".
Best of luck with the launch, I'll definitely try it out.
This space is definitely evolving with how many environment configs and creds teams have to maintain for all their environments and services.
I’m only familiar with Secrets Manager and Parameter Store and will check this out. Unfortunately, our customers are not going to be early adopters of this service but if it does the job well, this is something I can try and recommend them in future.
- Is this basically the config management that's in Heroku, but it's possible to use with anything else?
- Any plans for open source? I think that's a big reason why people use Vault, or roll their own.
- Our CLI is open source. No plans to open source the core product but have debated it internally.
Would it be suitable for a use-case where we manage (hypothetically) 400~ API keys, secrets, usernames etc for different use-cases. Our main application would need to be able to grab the secrets for APIs which run periodically.
I'm guessing Vault is more suited for this.. and not Doppler?
PS. My very last post on HN last week was about secrets: https://news.ycombinator.com/item?id=24625934
I'm looking for something like this for login passwords that i can share with a headless browser (SaaS) service for managing authen into services.
That way i only have to trust one service and not los of headless browser services
Can it be used that way ?
Kudos to the team for the launch! this is a beautiful product that solves a real problem in an elegant way!
A few months ago a wrote about how I solve this problem (https://www.viadog.com/replacing-environment-variables-aws-s...) and it works nicely for a small team with a small number of projects but this looks like a very nice solution when starting to scale a little bigger.
Good luck going forward!
Question, is it possible to rename the default local environment to "local"? dev means something else at our place ...
Have been in touch with one of Doppler’s co-founders and he’s been extremely helpful in integrating Doppler for us to use with NextJS (hosted on Vercel). Way to go on giving attention to your customers. We’ll be using Doppler for life, that’s for sure.
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.
