Launch HN: Doppler (YC W19) – Easily manage your env vars and secrets
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!
149 comments
[ 3.4 ms ] story [ 220 ms ] thread``` Show HN: Doppler – Machine learning marketplace of pretrained models (producthunt.com) - 6 points by bvallelunga on Apr 25, 2018 | 1 comment ```
It's a cool name for sure, but after perusing the founder of this project's blog posts and other web activity, their highly misleading marketing ("you have three options: waste time, don't even try, or pay us!" https://doppler.com/blog/build-vs-manual-vs-buy | "we recreated what these specific competitors which are already established made; they sucked, you don't want to use them, take our word for it and pay us instead of looking for yourself!" https://news.ycombinator.com/item?id=24719722 ) I question their morals.
Substantive criticism: your marketing needs not be slinging mud, and referencing specific established players in your marketing material in order to give false credibility that you are a one-for-one replacement is a shady practice. I looked at your post solely because it contrasted itself from your competitors claiming superiority, and was disappointed by all of the above AND that the fact that it couldn't do the things it claimed to by making those contrasts.
All in all, disappointed to see a ycombinator funded project hoisted on HN with all the above going on, and one with a large number of investors behind it and no open source to back up their claims. This isn't just a community built tool to improve developers' lives, this is a marketing push by a corporation with the intent to get a burst of customers with misleading/questionable marketing.
https://www.vaultproject.io/docs/vs
``` More importantly, just as we like to present information about Vault and its capabilities in the ways that we prefer, we felt it wasn't appropriate to describe the capabilities of other projects or products in ways other than their own terms. ```
[0] https://docs.doppler.com/docs/security-fact-sheet#data-flow-...
https://www.vaultproject.io/docs/secrets/databases/mysql-mar...
It's incredibly simple, and a breeze to use.
``` job "vault" { group "demo" { task "task" { vault { policies = ["database"] } template { env = true data = <<EOF {{ with secret "database/creds/production" }} DB_USERNAME={{.Data.username}} DB_PASSWORD={{.Data.password}} {{ end }} EOF } } } } ```
edit: thanks HN formatting
Can do all sorts of great things with this; for example TLS (ssl) certificate renewals, etc, as the certificate expiry IS the TTL; when a certificate needs to be renewed it can happen automatically and your application can receive any signal you choose (SIGHUP, for example)
"Dynamic" secrets imply that rotation is automated and frequent, and that there are no "blessed" certs, but rather that all certs/keys are generated in exchange for a successful identity assertion.
For example, if I can prove that I am LDAP user gen220, who belongs to group db-x-developer, I have earned the right to request a credential for connecting to db-x, which expires some arbitrary time before my identity-assertion expires.
You lost the entire audience who have actually used Vault before when you claimed it was too complex for your team to understand.. Why would I trust a company staffed with a crew that can't even understand the tools they are trying to compete with
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.
We also can write to AWS Parameter Store.
Kudos to the team for the launch! this is a beautiful product that solves a real problem in an elegant way!
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 :)
[0] https://github.com/envwarden/envwarden
[1] https://bitwarden.com/
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.
I'd also argue that EnvKey might be a bit too absolutist about security, in that we think the user experience greatly suffers as a result. We have a different tradeoff that emphasizes secure defaults and best practices while also allowing for necessary features like audit logs and syncing with different infra providers. We spent quite a bit of time considering the tradeoffs of zero-trust, but our user experience would suffer as a result, and so we have taken a different approach.
That said, a Content Security Policy doesn't actually address the issue I'm raising, because an attacker with server access could simply remove or modify it.
Of course, no system is invulnerable to any attack. But in practice, Doppler's architecture implies a much larger degree of trust (any server breach = secrets compromised) than EnvKey's (servers can be fully breached and secrets still aren't compromised). Doppler looks like a great product in many other ways, but I do think it's important for users to fully understand the risks they're taking.
> 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.
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.
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)
[0] https://docs.doppler.com/docs/security-fact-sheet
[1] https://github.com/DopplerHQ/cli
The fallback file is encrypted using AES-GCM with a key derived from the auth token and other metadata using PBKDF2. It is theoretically possible for an ex-employee to store the fallback file and retain a copy of the auth token and other metadata, even after the token has been revoked. In this case, they could construct the key using their privileged information. However, this attack would require active malfeasance by an authorized party during the period in which they're still authorized. It would be easier for the bad actor to store the raw secrets (by logging process.env, for example) than storing the encrypted file. To really solve this issue, the secrets would need to be time-bound and dynamic. Dynamic secrets are on our roadmap, but the issue you point out is a really hard problem. (And if you'd like to help, we're hiring![0])
[0] https://doppler.com/careers
- 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.
[0] https://github.com/DopplerHQ/cli
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 ?
[0] https://github.com/DopplerHQ/cli
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
https://secrethub.io
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.
[0] https://github.com/marketplace/actions/install-doppler-cli
Comparing FTP and Dropbox to Doppler and Vault; there are several logical fallacies in their marketing material.
https://yourlogicalfallacyis.com/anecdotal
I'll take Vault+Nomad+Consul, because I'd rather run Nextcloud than use Dropbox, kthx
Seriously though, if you can't market your product on its merits alone, don't try to misrepresent your competition.
https://www.confighub.com/
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".
This is on top of their SEP and read only System volumes with secure boot. Leave aside the argument about system openness to modification, that is beyond Unix's security and permissions model.
Sure, Unix offers some of that with chmod and mount options, but it's hardly a comprehensive solution.
Perhaps not the greatest example was provided, but the general sentiment I was aiming for was when disdain is expressed for tools without taking the time to understand what their intended (and practical) purposes are, and how they are effectively used.
When you have used a tool and understand it well, and witness another person go off on a tangent about how "Android is complete garbage, why would they ever do this this way", you naturally question that person's capability or whether they know what they are doing. In my experience, the person venting about how a tool sucks will 15-20 minutes later realize "oh. that's why.", or otherwise head off to roll their own implementation and 15 working days later realize "oh. that's why." or get into production and cause an outage from missing several edge cases.
On the macOS topic, it is odd that the root user no longer functions as one would expect in the Unix model (for example, cli tools which can no longer list OS processes, which haven't had any issues during the amount of time I've used them). It is frustrating that a wide variety of tools no longer work correctly as a result of some of these changes as well; for example, emacs can no longer navigate my filesystem. All said and done, my day to day work has been via Linux workstations for nearly all of the past 15 years, which is partly why some of those effects are more jarring than others to me.
Again, thanks for your input!