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.

This 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!

This 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)?

I 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.

Got 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.

you can do similar things with 1Password CLI.

Here is short example: https://github.com/stumyp/ope

Landing 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.

Thanks 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

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

Are 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/

Similar 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.

Congrats 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

[1] https://bitwarden.com/

Super happy user of EnvKey here - I'd be interested to hear what sets Doppler apart.

Founder 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.

Hey Dane- totally fair points. Agreed that Doppler and EnvKey have different threat models. Regarding your point about malicious JavaScript- I'd encourage you to take a look at our Content Security Policy. We've gone to great lengths to explicitly disallow all unsafe-inline JavaScript (technically in report mode, but will be moved to block mode within the next few days). This is just one of many things we do to help keep our users secure, but I figured it was worth addressing directly. We've also undergone extensive internal and external audits and pentests to ensure we're not susceptible to XSS and CSRF (and employ development practices to prevent us from introducing these vulns).

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.

Hey there! I completely agree with you on the tradeoffs between UX and security when it comes to end-to-end encryption. It's a tricky balance to get right, and I think it's great that there are multiple approaches out there in the market. People should weigh their own unique needs and comfort level when making the choice.

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.

Server access is an interesting scenario to explore. If we're considering an attacker gaining server access, what's to stop that attacker from shipping a modified EnvKey binary that steals your customers' secrets and their encryption keys? If the security of your binary is predicated on GitHub repo access, what happens in the event of GitHub account takeover? At some point, no system is infallible, and I think our Threat Mode adequately addresses this. I appreciate your point of view on this though.

The private certificates that sign our binaries are tightly controlled and not accessible to our servers or our GitHub accounts, so the scenario you're describing could only happen if an attacker compromised our Github account and our private signing certs (gaining access to our back end servers wouldn't help an attacker at all).

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.

Although the approaches are different, they both address a security need for all developers. For EnvKey it would be nice if you address the freelancer/single user Marketing tin some way - $20 a month for 5 users is a bit pricey for 1 user. Is that something you are considering?

We 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.

EnvKey user here - it looks exactly like EnvKey. Not sure what the underlying crypto primitives are - EnvKey relies on PGP/GPG style stuff and have a lot of documentation about it.

Oh, I just recently started using envwarden for managing dev secrets. I have some customizations for that use case on a fork, in case it's helpful to anyone: https://github.com/envwarden/envwarden/compare/master...simo...

That is awesome, I love seeing contributions in this space!

I agree that AWS Parameter store isn't great... that's why we use 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.

We 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.

You 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.

I had the same response. In fact, I assumed that there must be some kind of client-side secret wrapping with a customer-managed key or similar (i.e. you end up managing one secret, rather than n). I still need to secure access to the Doppler API key in any case.

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.

I came here to find/make this comment - especially with secrets management, I don't want to rely on an external vendor being up to access/manage my secrets. I want full access.

License the software, let me deploy and manage it.

That completely changes the kind of software that is being built, and would be a radical departure to their cloud based solution. Where do you store your secrets? AWS? GCP?

They'd get stored wherever is appropriate given what we already depend on to deploy software. If we deploy to our own data centre, that's where the secrets would go. If we're deploying to AWS, that's where the secrets would go.

Yes, for secrets storage it either needs to be e2e encrypted, or self-hosted. E2e partly to protect against internal employee theft, and partly to protect against Doppler’s db getting pwned by malicious hackers, as is so common these days. Storing secrets in the cloud unencrypted is kinda crazy these days.

We 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.

just 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.

Totally agree with this. I'd love a hosted solution for secret management, but e2e encryption seems like an absolute necessity.

If e2e encryption is a requirement for you, consider checking out https://secrethub.io

Full disclosure: I'm the founder :)

That is a fair reason and I understand the target market you are aiming.

It does seem like astroturfing is going on here. It wouldn't be the first time that a YC-backed startup has done so on HN.

Is it so much different from giving someone all of your source code, data, and conversations?

Not completely, that’s why most of those also have self-hosted solutions available.

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).

Tom 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.

Hey Tom! I see in the security section it says "We secure your data at rest through a mechanism called tokenization, which ensures our systems only store references to your secrets. In the event of a data breach, attackers would only gain access to the references." If this is the case, then where are the secrets stored? How can you view the secrets from the web console if they aren't stored anywhere? Thanks!

Great question! We tokenize all secrets and then store the tokens in our database. The raw secrets are stored with our tokenization provider, VGS. When you fetch your secrets, either via our dashboard or CLI, we exchange the token for the raw secret value and then relay that value in our response. This ensures that our infrastructure never persists raw secret values. You can find more information about this process in our Security docs [0].

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

Thanks for the quick response. I think this should really be explicitly stated in the docs, along with a link to VGS. The diagram didn't make it obvious to me that the "security provider" block is actually storing the secrets, rather than just converting them into tokens.

Thanks for that feedback, I completely agree. I've updated the linked page to mention this more explicitly.

Hi, 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?

The 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.

We 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.

Congratulations on the launch.

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!

I 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.

Thank you! Indeed I am not much of a writer on HN but I love the community.

I 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!

Nitpicky 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.

Nice catch! Pricing page is updated.

Checked 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 ...

Looks great!

What happens if Doppler is down or if there is a SNAFU when syncing the env in production?

Great 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

[1] https://github.com/DopplerHQ/cli

Is 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?

The 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

I 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.

Congrats 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.

Your 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.

You leaked your yoda translate api key in the video (31wiU[redacted]AQeF)

We 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!

Sounds interesting, but could you explain to me why I should use this over something like Azure KeyVault?

They 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!).

There 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.

But the [Secret Manger](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 ...

We 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.

Hi this is Ruud, founding engineer at Doppler. You can see us as a single source of truth where it is easy to manage your different projects and environments all in 1 place. GCP Secret Manager is great for production, but becomes harder to manage when you want to use it multiple environments with larger teams and in different projects/micro services.

Ick, talk about different products fimoreth! Look at the 4min video. Keyvault could theoretically be a good datastore for the secrets, though.

Why 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.

I 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!

I 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.

Vault 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.

Great point about dynamic secrets. This is an area we currently don't address, but it is definitely on our roadmap. There is a segment of the market for which dynamic secrets are an absolute requirement and we fully acknowledge that.

Just out of curiosity - what do people use dynamic secrets for? What is a "dynamic" secret anyway?

At our company, we use vault to generate and cycle short-lived database credentials and tls certs. Our RPC services use the certs to encrypt their traffic amongst each other, and also to enforce RBAC (since the certs are traceable, via vault, to a service or individual's identity).

"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.

A simple example that we use them for is for dynamic database credentials. So you no longer define a static username/password. You request the access/credentials from vault as you need them.

how does that actually work? Vault has the user/password, and then acts as a gateway to the db?

IIRC, Vault has plugins with GRANT access to your database, and rotates your passwords automatically. So it is able to create new users when access is requested, and to rotate passwords if needed.

https://www.vaultproject.io/docs/secrets/databases/mysql-mar...

It looks like this https://www.nomadproject.io/docs/integrations/vault-integrat...

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

with this setup, Vault will create a new database user based on the configuration you set (read-only for some services, for example), and will attach a time-to-live to those credentials; as long as the application is using them, it will renew the TTL. When an application is killed, or scaling happens, etc, and the application instance isn't using those specific credentials, Vault will clean up and remove the unused account cleanly

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)

Fascinating! Thanks for sharing, I had no idea this was possible.

I guess dynamic secrets are too "ftp" for Doppler, eh?

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

We’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.

Interesting. 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.

- 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.

Is 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

This 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.

Looks 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.

We 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

Doesn'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.

Lots of really great questions in here! Starting at the top-

The process demoed in the video is for user-based auth. Service tokens can be issued programmatically and provide read-only access to one config. You can pass these into your environment via puppet and other configuration tools, or even via LDAP, in much the same way you bootstrap other OS config like SSH keys.

I really like your thoughts around more niche access roles, and it's definitely where we're headed. Admittedly our RBAC is currently more limited with a basic Member, Admin, Owner model. We do have existing audit capabilities for monitoring secrets changes (without revealing the actual secrets) and support shipping those logs to Slack or a webhook.

Audit history is based on your specific plan[0], but we currently offer up to a year. Some customers do have requirements for longer time periods and we can easily configure that for them.

Regarding your last point, this is what we refer to as secret referencing. You can absolutely reference secrets across different configs and projects to avoid repeating common values. Here's our announcement from when we shipped this feature back in August[1].

[0] https://doppler.com/pricing

[1] https://doppler.com/changes/secrets-referencing

Can 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.

You 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

For folks looking for alternatives, there is also confighub:

https://www.confighub.com/

I've been waiting for something this easy.

Woah, blown away by their onboarding page after signup. Kudos for whoever came up with the concept!

Thank you! Full props to our design guru and CEO @bvallelunga for that one.

wish more documentations were like this

hey 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 ?

Absolutely, 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

Cool product. Definitely always felt that SSM and Vault were very heavyweight solutions.

Happy user here. My favorite part is the seamless local development abilities.

This looks neat. Do you have any plans to provide a Kubernetes CRD or something else to pull/sync secrets into pods?

Currently 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.

I could not find anything about Terraform integration. That is something I bet many of your customers will need.

We 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.

We'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.

We 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

Perfect! Will check it out.

What are your thoughts on Secrethub?

https://secrethub.io

We 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.

Founder 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.

You should apply for YC too.

This is definitely a pain point for me, interested to check it out.

How did you build your landing page? It's pretty slick.

We 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-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".

Great 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?

Thank 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/6846593ca50500f058a1f07f...

Ahh! This is great thanks!

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.

Whoa, 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, and of course the site guidelines do also: https://news.ycombinator.com/newsguidelines.html.

Understood, 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

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".

Not to start a flamewar, but as a 35 year veteran, the permissions dialog is the same as what SELinux would give you. Apple are implementing an RBAC and require authentication and authorization on a per-app basis.

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.

He compared it to Dropbox...

I think the context was lost here - https://news.ycombinator.com/item?id=24724730

They did compare it to all of these

"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.