14 ms·
Launch HN: Doppler (YC W19) – Easily manage your env vars and secrets
Brian here - I am one of the creators of Doppler and I’m pumped (and kinda nervous!) to share it with HN.
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 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 https://vimeo.com/447918575.
Take a look if you're curious: https://doppler.com https://doppler.com. Let us know what you think!
- 5d30593126e79d6 6y ago(throw-away here; mods banned my account, rearranged, hid, and selectively stripped away the context from comments) Great input; not flame war enticing, just facts, and I respect your 20 year head start - implicit memory is only attainable by experiencing things first hand, and I appreciate that. 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!
- 43b9d8eb9a0 6y ago(throw-away here; mods banned my account, rearranged, hid, and selectively stripped away the context from comments) That's great input; not flame war enticing, just facts, and I respect your 20 year head start - implicit memory is only attainable by experiencing things first hand, and I appreciate that. 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!
- 62902a29a3d 6y ago(throw-away here; mods banned my account, rearranged, hid, and selectively stripped away the context from comments - take from that as you will) This project in particular: - attacked otherwise neutral competitors, misrepresenting them. FTP is a protocol associated with a general air of insecurity and poor practice. Most technical people would immediately say not to use it, and that there are far better solutions which aren't fundamentally insecure. Vault is not anything like that. That is a misrepresentation and additionally an attack on the usability of their competitor's product, which is unmerited. - does not observe the best practice of having security-oriented products be open source. It is crucial for software in this category be open source, in order to have them widely vetted, and for vulnerabilities not to be incentivized to hold onto (and sold), vs reporting to the vendor. The team have reached their decision that they will NOT open source it https://news.ycombinator.com/item?id=24720669 https://news.ycombinator.com/item?id=24720669 If I cannot build my own binaries (even if unreproduceable builds), I cannot trust the vendor. Additionally, I must trust them to operate and secure it as a public multi-user system better than one could in their own infrastructure under several layers separating it from the public. Humans are prone to mistakes, closed source software engineers make the same mistakes made in open source, only they have employees who's primary task is shipping new features-not fixing a bug which no one may see until it comes out that it's been actively exploited for years; let people improve the overall security, and encourage the only people looking for vulnerabilities to be those who would benefit from exploiting them personally, or by reselling them to the highest bidder. - demonstrated that the are willing to say things which aren't true, or that they just didn't care to verify the details before stating them as fact. The authors make the black/white distinction between "you use Dropbox if you aren't paranoid" and "there are self-hosted options if you care about that, but they aren't qualified because you can only use them this way", despite it not being the case. It's a spectrum, and you can achieve the same results with either offering, only with one your only choice is to trust them and that they have things so tight that several malicious employees would be subverted. - used their employees' previous employers to legitimize their product. As someone who may be selecting security-oriented tools for a project, and as a someone who has experienced a lot of issues specifically with their engineering/operations firsthand, Uber engineering as a point pushes me away from considering this tool. Uber has also been criticized many times for unethical actions; sure, engineers may often be simply heads-down and following a spec, but I would rather work with someone who didn't just "follow orders". As someone evaluating your offering, my specific feedback is that you will push people like myself away by leaning on that as part of your marketing/branding, particularly when it involves secret management - a topic which is highly dependent on unbreakable morals.
- bcb29df3 6y ago(throw-away here; mods banned my account, rearranged, hid, and selectively stripped away the context from comments - take from that as you will) Take aways from this marketing push; this company: > does not observe the best practice of having security-oriented products be open source. - It is crucial for software in this category be open source, in order to have them widely vetted, and for vulnerabilities not to be incentivized to hold onto (and sold), vs reporting to the vendor. The team have reached their decision that they will NOT open source it https://news.ycombinator.com/item?id=24720669 https://news.ycombinator.com/item?id=24720669 If I cannot build my own binaries (even if unreproduceable builds), I cannot trust the vendor. Additionally, I must trust them to operate and secure it as a public multi-user system better than one could in their own infrastructure under several layers separating it from the public. Humans are prone to mistakes, closed source software engineers make the same mistakes made in open source, only they have employees who's primary task is shipping new features-not fixing a bug which no one may see until it comes out that it's been actively exploited for years; let people improve the overall security, and encourage the only people looking for vulnerabilities to be those who would benefit from exploiting them personally, or by reselling them to the highest bidder. > attacked otherwise neutral competitors, misrepresenting them. - FTP is a protocol associated with a general air of insecurity and poor practice. Most technical people would immediately say not to use it, and that there are far better solutions which aren't fundamentally insecure. Vault is not anything like that. That is a misrepresentation and additionally an attack on the usability of their competitor's product, which is unmerited. > demonstrated that the are willing to say things which aren't true, or that they just didn't care to verify the details before stating them as fact. - The authors make the black/white distinction between "you use Dropbox if you aren't paranoid" and "there are self-hosted options if you care about that, but they aren't qualified because you can only use them this way", despite it not being the case. It's a spectrum, and you can achieve the same results with either offering, only with one your only choice is to trust them and that they have things so tight that several malicious employees would be subverted. > used their employees' previous employers to legitimize their product. - As someone who may be selecting security-oriented tools for a project, and as a someone who has experienced a lot of issues specifically with their engineering/operations firsthand, Uber engineering as a point pushes me away from considering this tool. Uber has also been criticized many times for unethical actions; sure, engineers may often be simply heads-down and following a spec, but I would rather work with someone who didn't just "follow orders". As someone evaluating your offering, my specific feedback is that you will push people like myself away by leaning on that as part of your marketing/branding, particularly when it involves secret management - a topic which is highly dependent on unbreakable morals.
- tompic823 6y agoTom here from Doppler. I'm a founding engineer at Doppler and work on most of our security. Feel free to hit me with any security questions about our product, philosophy, etc.
- qchris 6y agoHi, congrats on the launch! Potentially a little off topic, but I'm curious how you came up with the name Doppler. After the audio effect, or the Witcher creature, or something else entirely?
- bvallelunga 6y agoThe domain was available ;) More seriously, outside of the properties (easy to spell and most people have heard of it before) I wanted something that was more than just environment management. Something grand we could grow into.
- quinndiggity 6y agoIt is a re-use/pivot of a name for a previous project from Brian that didn't take off: ``` 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 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 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.
- candiddevmike 6y agoWhy would someone use this over Vault or SOPS? Your (somewhat condescending) "stuck using FTP instead of Dropbox" is a very poor characterization. I think you've entered into a very busy space without bringing anything new to the table.
- bvallelunga 6y agoI can see why you might think that at first glance, but I'd encourage you to try out Doppler. No secrets manager offers the flexibility and incredible ease of use that we do. I'm not going to dive into a feature list, because a lot of that is table stakes, but what really sets us apart is our philosophy. We have the explicit goal of making our customers not only more secure but also more productive. Find me a Vault customer that would describe their install as helping them move faster!
- auspex 6y agoI think I would focus a bit more on answering why this philosophy makes your product better than the proven secrets managers out there. I’m looking at products and comparing you against the established enterprise proven players. What really sets you apart from a product / use case standpoint.
- quaffapint 6y agoVault is definitely much more of a beast, but it also does a lot more, such as dynamic credentials. For just storing static secret/env vars this seems like a simpler solution.
- blntechie 6y agoCongrats on the launch! 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.
- tompic823 6y agoYour point about not being an early adopter is well taken. We fully expect a segment of the market will be disinterested in using a relatively new product like ours. If we were a customer considering a new secrets manager, we would likely weigh similar concerns. I think the onus is on us to prove to these larger customers over time that we can be trusted (from a security/availability/longevity standpoint) and we certainly intend to do so.
- fimoreth 6y agoSounds interesting, but could you explain to me why I should use this over something like Azure KeyVault?
- tor291674 6y agoThey say they worked at Uber and small startups, they mention a ton of alternatives to their product, but never once mentioned Azure KV. And your comment is also the only comment mentioning it. Im not sure what Hacker News has against Microsoft and the Azure offerings, but AKV is one of the best secret managers on the market today. It does 90% of the features Doppler advertises, and the developer experience is awesome, even the deployment experience is great, especially when hosting in App Services (not required!).
- bvallelunga 6y agoThere are two immediate reasons. The first is so that you can manage your secrets and env vars in the same way in development as you do in production. Engineers focus a lot on doing this for code, but this hasn't hit the env var space yet. The second is so that all your secrets live in one place. Doppler is your source of truth for secrets in the same way that GitHub is your source of truth for your code. Your developers pull from GitHub, Azure pulls from GitHub during a deployment, etc. This centralization allows for really smooth access controls and auditing.
- p2hari 6y agoBut the [Secret Manger](https://cloud.google.com/secret-manager https://cloud.google.com/secret-manager) from google is also easy to use and specially firebase environment config is exactly like the demo. Best wishes ...
- deleted 6y ago[deleted]
- bvallelunga 6y agoWe don't think of Secret Manager as a competitor, but more of a destination for your secrets. We have integrations with both AWS and GCP Secrets Manager so you can write directly to them from Doppler. We also can write to AWS Parameter Store.
- arsalanb 6y agoThis is great! I tried to use Vault and it just was a nightmare to get started (they seem to have improved now, in their defense). The more impressive thing here is that it democratizes access to safe env var/secret management by not requiring a devops background to understand how this works (Vault docs have a whole ton of newly coined terms which you must understand in order to use this, which was just too much for me—a self-taught web developer) Kudos to the team for the launch! this is a beautiful product that solves a real problem in an elegant way!
- gingerlime 6y agoCongrats on the launch. Great to see more products in this space. 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 https://github.com/envwarden/envwarden [1] https://bitwarden.com/ https://bitwarden.com/
- bvallelunga 6y agoThat is awesome, I love seeing contributions in this space!
- drcongo 6y agoSuper happy user of EnvKey here - I'd be interested to hear what sets Doppler apart.
- deleted 6y ago[deleted]
- bvallelunga 6y agoWe are friends with the folks at EnvKey! Our core philosophy is what’s different, we focus on building something for the everyday developer, where we abstract as much overhead as possible. A example of this is how you log into the Doppler CLI when developing. The “doppler login” command takes you to the browser and you sign in like how you would any other site. There is no need to remember API keys, everything is handled behind the scenes for you. Other things that set us apart: audit logs, versioning, and rich integrations with production infras like AWS, GCP, Heroku, Vercel, Netlify, etc.. Besides that, our pricing is much more friendly, we offer a free tier for unlimited users for all the core functionality.
- danenania 6y agoFounder of EnvKey here. I'm glad to hear you're a happy user :) 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.
- kkwtfeliz 6y agoYou leaked your yoda translate api key in the video (31wiU[redacted]AQeF)
- tompic823 6y agoWe were waiting to see how long it took someone to notice that :) That key has already been rolled and instantly redeployed via our Heroku integration, but nice catch!
- heymartinadams 6y agoWe’ve been using Doppler for a few months in development so far, and I can tell you, it’s a game-changer. The thing that stands out is that Doppler is a technology in its own category — analogous to what Airbnb is to the travel industry or what Uber/Lyft is to transportation. As far as I know, nothing else exists like it, and yet it’s incredibly useful. 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.
- adar 6y agoNitpicky typo alert on the pricing page: > 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.
- bvallelunga 6y agoNice catch! Pricing page is updated.
- meagher 6y agoLooks great! What happens if Doppler is down or if there is a SNAFU when syncing the env in production?
- tompic823 6y agoGreat question! We address this in detail on our Security page [0], but I'm happy to give a high-level overview here: 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 https://docs.doppler.com/docs/security-fact-sheet [1] https://github.com/DopplerHQ/cli https://github.com/DopplerHQ/cli
- onei 6y agoIs there a scenario where the CLI fallback gets out of sync and you may as well not have the fallback? How is the fallback file secured and what's stopping someone else from accessing those secrets of they can get at the encrypted file itself? Finally, what if a disgruntled ex-employee still has that fallback - can access be revoked reliably even if your API is down or they just turn off the internet connection?
- lukevp 6y agoI think if you substitute all your questions with env vars, all the same issues present themselves. You have to roll secrets whenever someone with access no longer has access, and the env vars can be stale just the same as the encrypted file.
- tompic823 6y agoThe local fallback file is updated each time new secrets are fetched. It is possible for your Doppler secrets to change between your last successful fetch and your next unsuccessful fetch, and in that scenario you wouldn't be operating off the latest secrets. We don't see the fallback file as an excuse for availability; our service needs to be up. 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 https://doppler.com/careers
- shay_ker 6y agoInteresting. Couple Q's: - 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.
- bvallelunga 6y ago- Kind of. It's more a GitHub for secrets. A central place to store all of your secrets organized by projects and environments. From there you can setup auto-sync with a bunch of destinations like Heroku or AWS Parameter Store. - Our CLI is open source. No plans to open source the core product but have debated it internally.
- davefp 6y agoCan I change my local secrets without using the web interface? I see there's a local fallback mode but it's not immediately clear if it's user updatable.
- tompic823 6y agoYou can indeed! You can manage all of your secrets from the Doppler CLI [0]. Specifically, you'd want the `doppler secrets update` command. [0] https://github.com/DopplerHQ/cli https://github.com/DopplerHQ/cli
- jaequery 6y agoWoah, blown away by their onboarding page after signup. Kudos for whoever came up with the concept!
- lucasverra 6y agohey there, congrats on this launch. 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 ?
- tompic823 6y agoAbsolutely, we use Doppler ourselves in this way with puppeteer for our E2E tests. You would simply wrap your orchestrator (like puppeteer) with our Doppler CLI [0] to make the secrets available via environment variables. For example, `npm start` would now be `doppler run -- npm start`. [0] https://github.com/DopplerHQ/cli https://github.com/DopplerHQ/cli
- armatav 6y agoI've been waiting for something this easy.
- kenanpulak 6y agoWe were using AWS SSM previously which got exponentially more difficult to manage with each service we added, we had stumbled upon Doppler while spinning up a new service and decided to give it a shot. We've been using Doppler for over a year and it's saved us a lot of developer hours on managing secrets and improved our dev workflows significantly.
- zlwaterfield 6y agoHappy user here. My favorite part is the seamless local development abilities.
- kbyatnal 6y agoThis is very neat - my favorite part so far is being able to synchronize local .env across all developers instantly. We currently use 1Password as a hacky solution for this, which is a bit of a pain. 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)?
- rgmvisser 6y agoI am glad you asked! I built the Heroku integration at Doppler. We are doing a one way syncing as we believe Doppler should be the single source of truth for your secrets. However, we know that addons & attachments are an important part of Heroku, so we make sure we never overwrite any of the addons/attachments env vars. Those continue to live within Heroku as they wouldn't make much sense or be useful outside of that context.
- kbyatnal 6y agoGot it, thanks for sharing that! I just got local development setup via Doppler and it was a breeze. "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.
- stimur 6y agoyou can do similar things with 1Password CLI. Here is short example: https://github.com/stumyp/ope https://github.com/stumyp/ope
- ampdepolymerase 6y agoWhat are your thoughts on Secrethub? https://secrethub.io https://secrethub.io
- bvallelunga 6y agoWe love seeing other companies innovate to make managing secrets less painful. We have found that most developers really want a holistic way to manage secrets. One stark difference between Doppler and SecretHub is that we have a dashboard that makes it super easy to manage your secrets. We have a deep rooted focus on user experience.
- mackenbach 6y agoFounder of SecretHub here, big kudos on the GUI Doppler made, looks amazing. 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.
- ampdepolymerase 6y agoYou should apply for YC too.
- llarsson 6y agoI could not find anything about Terraform integration. That is something I bet many of your customers will need.
- rgmvisser 6y agoWe do support Terraform via our CLI, but the integration is still a bit more primitive than some of our other integrations that are more "one click". It is definitely on our radar and we are actively exploring a tighter integration with Terraform.
- ricklamers 6y agoWe're also building on Terraform so this kind of integration would be neat! How well are GitHub Actions supported? We've been dancing with secrets there too.
- tompic823 6y agoWe fully support GitHub Actions and have a native GitHub Action[0] that you can use to install our CLI. [0] https://github.com/marketplace/actions/install-doppler-cli https://github.com/marketplace/actions/install-doppler-cli
- ricklamers 6y agoPerfect! Will check it out.
- quinndiggity 6y agoHave the creators of Doppler not used Vault... Comparing FTP and Dropbox to Doppler and Vault; there are several logical fallacies in their marketing material. https://yourlogicalfallacyis.com/anecdotal 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.
- megakid 6y agoThis looks neat. Do you have any plans to provide a Kubernetes CRD or something else to pull/sync secrets into pods?
- rgmvisser 6y agoCurrently the customers that are using Kubernetes integrate with our Docker integrations. We do see that Kubernetes is a growing use case and are looking into a dedicated integration (possibly through a CRD as you mentioned). Send us an email at support@doppler.com, we would love to hear about your specific use case with Kubernetes.
- Edmond 6y agoFor folks looking for alternatives, there is also confighub: https://www.confighub.com/ https://www.confighub.com/
- arjie 6y agoCool product. Definitely always felt that SSM and Vault were very heavyweight solutions.
- quinndiggity 6y agoWait wait wait, and this is paid and hosted too? Bleh, nooooo thanks. I'm not sending private and secret key material to a bunch of ex-Uber employees (gross on that point alone), but nevermind to ones who looked at the existing market, didn't understand the tool-scape, and essentially decided to roll their own crypto...
- dang 6y agoWhoa, please don't be a jerk in response to other people's work on HN. It's fine if you don't like it, and it's certainly fine if you have substantive criticism. But it's not fine to put down others, or their work; internet cultures can easily turn in that direction and we're hoping to avoid that here. The Show HN guidelines (which also apply to Launch HNs) have a few things to say about this: https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html, and of course the site guidelines do also: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- quinndiggity 6y agoUnderstood, and yes my comment was harsh, perhaps a bit much so 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 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".
- chrisacky 6y agoIs the primary use-case only for configuration secrets? 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 https://news.ycombinator.com/item?id=24625934
- bvallelunga 6y agoThis is the exact use case that Doppler was built for! Doppler is designed to store API keys, secrets, config vars, etc. Depending on your setup (monolith vs microservices), you can group these into one project or many. From there you can fetch all your secrets in one call.
- daddykotex 6y agoI don't write much on Hacker Nees, I'm much of a reader. But... 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.
- bvallelunga 6y agoThank you! Indeed I am not much of a writer on HN but I love the community.
- makethetick 6y agoCongratulations on the launch. A few months ago a wrote about how I solve this problem (https://www.viadog.com/replacing-environment-variables-aws-secrets/ 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!
- neximo64 6y agoYou have to give Doppler your secrets which is absolutely crazy. Is there a self hosted version? 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.
- bvallelunga 6y agoWe realize that storing secrets requires trust and for some companies it may be outside of their comfort zone at the moment. We are currently focused on creating a super easy to use solution. An analogy: there are open source versions of Dropbox for users that don't trust Dropbox with their files (NextCloud, ownCloud, etc.), however this comes with the friction of having to host your own solution. We are more like Dropbox, where we want to create a solution that is incredibly easy to install, manage, and work with. That being said, a self-hosted solution is top of our mind as we totally acknowledge that some companies would not want to use a hosted solution.
- jerrygoyal 6y agojust thinking out loud.. isn't it a better solution if you implement e2e encryption with dashboard and cli like how password managers do? i mean it's secrets and as a company you also wouldn't want to get into any trouble. if user losses the password he can always disable old keys of respective services and generate new ones.
- nicoburns 6y agoTotally agree with this. I'd love a hosted solution for secret management, but e2e encryption seems like an absolute necessity.
- mackenbach 6y agoIf e2e encryption is a requirement for you, consider checking out https://secrethub.io https://secrethub.io Full disclosure: I'm the founder :)
- quinndiggity 6y agoThank you for acknowledging the need for trust, self-hosting + auditability. However, please stop trying to contrast yourself with these analogies. Owncloud and Nextcloud both have hosted OR on-prem versions https://owncloud.com/pricing/ https://owncloud.com/pricing/ https://nextcloud.com/providers/ https://nextcloud.com/providers/
- rat9988 6y agoHe compared it to Dropbox...
- jasonwhittaker 6y agoI think the context was lost here - https://news.ycombinator.com/item?id=24724730 https://news.ycombinator.com/item?id=24724730 They did compare it to all of these
- quinndiggity 6y ago"An analogy: there are open source versions of Dropbox for users that don't trust Dropbox with their files (NextCloud, ownCloud, etc.), however this comes with the friction of having to host your own solution. We are more like Dropbox, where we want to create a solution that is incredibly easy to install, manage, and work with." 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.
- quinndiggity 6y agoIn case that wasn't straight forward - "NextCloud, ownCloud, etc. ... comes with the friction of having to host your own solution" NextCloud and ownCloud don't require you to host your own solution, however you can if you want, which is important. "We are more like Dropbox, ... incredibly easy to install, manage, and work with" Nextcloud and ownCloud are incredibly easy to install, manage, and work with.
- quinndiggity 6y agoTo 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.
- temuze 6y agoI agree that AWS Parameter store isn't great... that's why we use Chamber: https://github.com/segmentio/chamber https://github.com/segmentio/chamber 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.
- rgmvisser 6y agoWe agree that Chamber is a great wrapper that makes working with Parameter Store much easier. However, we go a bit further where we have a visual dashboard that makes it much easier to manage secrets in different projects and environments as a whole. In Doppler you can easily edit them in a dashboard, inherit from other configs or reference other secrets. We also have permission control, audit logs, versioning and rollbacks. In your case, no more need to run `chamber write ENV_NAME SECRET_NAME SECRET_VALUE` to sync each secret to each application/region combination you have. We also have a direct integration with AWS so that you can automatically sync all secrets to Parameter Store, should you want to continue pulling from it in production.
- antoncohen 6y agoThis 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.
- bvallelunga 6y agoWe 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 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.
- jrochkind1 6y agoThis is definitely a pain point for me, interested to check it out.
- quinndiggity 6y agoGoing 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.
- DanBC 6y agoPlease reread what moderator Dang said to you 3 hours ago.
- quinndiggity 6y agoIf ycombinator and their mods are more concerned with the promotion of one of their own investments, over discussion of its merits and feedback from the people who _would_ be the ones adopting and promoting it in their own companies if it indeed lived up to its own marketing, then I invite a ban for trying to keep hackernews honest and driven by community discussion, over a place for them to advertise, self promote, pat themselves on the back, and pad their wallets.
- dang 6y agoBaiting the moderators is in poor taste and is not going to change our behavior. The way we moderate HN when YC or YC startups are involved has been stable for many years: we moderate less in such cases. You'll find many statements of this going back a long time here: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=moderate%20less%20not%20more%20yc%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so.... Less, however, does not mean zero. You posted 15 aggressive comments in this thread; that's extreme. You've crossed well into trolling, and even descended into personal attack (https://news.ycombinator.com/item?id=24724190 https://news.ycombinator.com/item?id=24724190). I don't know where this grudge is coming from, but it's time to stop. Plenty of other commenters have been raising similar concerns (e.g. about hosted secrets); that's obviously fine. The difference is that they're doing it in a decent and non-vindictive way, as the site guidelines require.
- quinndiggity 6y agoQuestions for @bvallelunga, @tompic823, @rgmvisser What is your philosophy on determining what behaviour helps to improve developers lives? Does it involve leaving out or misrepresenting facts, pushing people away from making decisions based on pure data, or trying to blindly go full steam ahead with an idea over evaluating and responding to flaws that become known? What do you think of a secret management tool, whose team leaks credentials in their marketing material but asks people who don't know them to trust they'll do any better once they are holding all their keys? Would you use this tool, knowing the people building it would rather hide and bury their mistakes than be transparent about them? Should a product be enticing on its own, or should it need to name drop companies where their team may have worked in the past (which even those companies' ethics are regularly headlines)? How did you decide this was a tool that need to be made? Were you the ones operating the existing tools at your previous companies, or did you read one page of those tools' docs and decide they were too hard? Who should be in control of a company's secrets? The company, or a stranger who has done more to cause distrust in them than prove they can adapt to challenges and admit mistakes or poor decisions?
- nyrulez 6y agoLanding page does not address the elephant in the room: security and trust. I can't imagine mentioning in our security policy/audit that we store secrets with a third party and Doppler doesn't seem to be talking about this aspect, just ease of use. But this isn't a photo sharing app.
- tompic823 6y agoThanks for pointing this out, you're absolutely right. I'm linking to our Security page[0] and our security docs[1] below, but we'll definitely be updating our marketing site to place more of an emphasis on this. I hope the rest of this post and our comments here illustrate that trust and security are things we think a lot about, despite our oversight with the landing page. [0] https://doppler.com/security https://doppler.com/security [1] https://docs.doppler.com/docs/security-fact-sheet https://docs.doppler.com/docs/security-fact-sheet
- rswail 6y agoAre you planning external compliance certification similar to AWS [1]? In particular the PCI/DSS world requires underlying auditing and compliance of infrastructure components. [1] https://aws.amazon.com/compliance/programs/ https://aws.amazon.com/compliance/programs/
- bvallelunga 6y agoSimilar to AWS we plan to get extensive external compliance certifications starting with SOC 2. We are currently in our first audit cycle and plan to expand into other compliances there after. Truthfully we are still evaluating which compliances to get next (PCII, ISO, etc) based on customer demand. We also do frequent pentests to help vet our infrastructure and security posture.
- Bedon292 6y agoLooks really interesting, and potentially useful. I looked around, but didn't see much about a few things, which are probably not standard use cases: 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.
- tompic823 6y agoWe fully support using Doppler on bare metal servers, VMs, and just about any other cloud service via our CLI [0]. This would be identical to how you'd access your secrets locally when developing. You'd wrap your command with our CLI so that your secrets are injected into the process's environment (e.g. `npm start` becomes `doppler run -- npm start`). 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. [0] https://github.com/DopplerHQ/cli https://github.com/DopplerHQ/cli
- Bedon292 6y agoDoesn't the use of the CLI require the manual setup process in the demo video? With the login and configure? If I don't want to manually setup each machine, is there any war around it? I saw there are service tokens, but I think there might be a bit of chicken and egg issue, where I need to pass secret tokens to access the system to pass secrets with. 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.
- blago 6y agoI have been looking for something like this for years. I can't wait to give it a try on my next personal project. Thank you!
- ublaze 6y agoHow did you build your landing page? It's pretty slick.
- bvallelunga 6y agoWe built it using Webflow (an amazing YC company!) and used the Timber template as the foundation: https://webflow.com/templates/html/timber-ui-kit-website-template https://webflow.com/templates/html/timber-ui-kit-website-tem... 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".
- gervwyk 6y agoGreat job on the landing page and congrats on the launch! Definitely addressing a real pain with this! One question, how did you do the cli / typing text animation? Also in webflow?
- bvallelunga 6y agoThank you! In Webflow you can use HTML Embed components. In there I wrote some javascript to type out each character. I put a Gist that has all the code but fair warning it is pretty hacky as I made it over a weekend for fun. I definitely wouldn't treat this code as "high quality" code. https://gist.github.com/bvallelunga/6846593ca50500f058a1f07ff537c1ae https://gist.github.com/bvallelunga/6846593ca50500f058a1f07f...
- gervwyk 6y agoAhh! This is great thanks!
- aliswe 6y agoChecked this out and to be honest I'm completely stoked. We've been looking for a solution to our secrets nightmare and this just might be it. Question, is it possible to rename the default local environment to "local"? dev means something else at our place ...