Hacker News new | past | comments | ask | show | jobs | submit login

I've met the Doppler founders and greatly respect them (even played some poker with them!). Doppler has great design and UX.

That said, I'd say the key difference is that EnvKey places much more emphasis on security and privacy. Doppler is cloud-hosted and doesn't use end-to-end encryption, so it requires that you trust them to keep your data safe and not make any mistakes in their data security, network security, who they hire, what sub-processors they trust, etc. In my (very biased) opinion, that is not sufficient protection for the most sensitive data.

Doppler also uses a web interface, which is great for convenience and UX, but leaves you vulnerable to compromised browser plugins, XSS, etc. I don't believe browsers are sufficiently secure currently for secrets management (if this changes, we'll add a web interface to EnvKey ASAP!).

There are real costs in terms of UX to end-to-end encryption. EnvKey tries to be as user-friendly as possible, but doesn't compromise on security or privacy. Doppler's design, as I understand it, leans more toward the other side of this tradeoff.

On Terraform--yes, it's easy to use EnvKey with Terraform. The general pattern for integrating EnvKey with any tool or platform is to set your ENVKEYs as secrets in whatever way the platform handles them, then expose each ENVKEY as an environment variable to your VMs, containers, or whatever else you're running. We'll write up a Terraform-specific guide soon to make it as easy as possible.




Co-founder/CTO of Doppler here. I'd agree that Doppler currently focuses very heavily on UX. We aim to fit into developer workflows, regardless of where devs run their code. This includes local development (macOS/Windows/Linux), CI/CD, Kubernetes, Vercel, and just about anywhere else. We've found that security tools that are difficult to use end up being worked around by developers, which ultimately decreases an org's security posture (see HashiCorp Vault). This does come with some tradeoffs- specifically that you must trust Doppler with your secrets, given our tokenization model[0].

We do recognize that the current security tradeoffs of Doppler aren't going to satisfy everyone. For Enterprises, we offer Enterprise Key Management (EKM), which allows orgs to encrypt their secrets using a cloud KMS. Of course, this still doesn't satisfy every concern. And so, for customers requiring additional security guarantees, stay tuned!

[0] https://docs.doppler.com/docs/security-fact-sheet


I wonder why is it difficult to add an extra password on top of the access key. What I mean is you can have another password or hash (separate to normal auth pass) which is only used to encrypt at browser and decrypt at the time of usage(through env load packages or your custom doppler command. This extra password is never sent or stored at doppler server.


> I don't believe browsers are sufficiently secure currently for secrets management

This is a super rare view, but one I truly appreciate. The risk of compromised browser plugins especially is vastly understated and underappreciated by... way too many "security" "experts".


I don’t believe just about any platform we have now is really sufficiently secure for secrets management. Just as a compromised browser plugin can do a lot of damage, so too can a compromised desktop application (including its dependencies). The industry as a whole is not in a great place when it comes to protecting the integrity of our machines, especially developer workstations.

(And yes I know you probably know this better than most as a Sandstorm dev :)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: