[HN Gopher] Launch HN: Doppler (YC W19) - Easily manage your env...
___________________________________________________________________
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. And fully managed encrypted fallbacks
in your infra means your secrets are always available, even in the
rare case we aren't. To support our community, we're committed to
offering a community plan that's free forever for unlimited users.
Paid plans start at $6/seat/month. For visual learners like me,
here's a 4-min video of us installing Doppler:
https://vimeo.com/447918575. Take a look if you're curious:
https://doppler.com. Let us know what you think!
Author : bvallelunga
Score : 127 points
Date : 2020-10-08 15:03 UTC (7 hours ago)
| heymartinadams wrote:
| 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.
| candiddevmike wrote:
| 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.
| bvallelunga wrote:
| 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!
| auspex wrote:
| 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.
| quaffapint wrote:
| 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.
| tompic823 wrote:
| 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.
| quinndiggity wrote:
| 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
| shay_ker wrote:
| Just out of curiosity - what do people use dynamic secrets
| for? What is a "dynamic" secret anyway?
| gen220 wrote:
| 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.
| quaffapint wrote:
| 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.
| shay_ker wrote:
| how does that actually work? Vault has the user/password,
| and then acts as a gateway to the db?
| quinndiggity wrote:
| 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
| quinndiggity wrote:
| 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)
| tecleandor wrote:
| 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...
| gingerlime wrote:
| 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/
| bvallelunga wrote:
| That is awesome, I love seeing contributions in this space!
| Plugawy wrote:
| 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.
| drcongo wrote:
| Super happy user of EnvKey here - I'd be interested to hear
| what sets Doppler apart.
| danenania wrote:
| 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.
| tompic823 wrote:
| 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.
| danenania wrote:
| 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.
| tompic823 wrote:
| 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.
| danenania wrote:
| 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.
| incognos wrote:
| 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?
| [deleted]
| bvallelunga wrote:
| 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.
| simon_weber wrote:
| 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...
| neximo64 wrote:
| 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.
| bvallelunga wrote:
| 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.
| quinndiggity wrote:
| Thank 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://nextcloud.com/providers/
| daddykotex wrote:
| 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.
| bvallelunga wrote:
| Thank you! Indeed I am not much of a writer on HN but I love
| the community.
| zlwaterfield wrote:
| Happy user here. My favorite part is the seamless local
| development abilities.
| quinndiggity wrote:
| Have 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
|
| 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.
| kkwtfeliz wrote:
| You leaked your yoda translate api key in the video
| (31wiU[redacted]AQeF)
| tompic823 wrote:
| 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!
| llarsson wrote:
| I could not find anything about Terraform integration. That is
| something I bet many of your customers will need.
| rgmvisser wrote:
| 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.
| davefp wrote:
| 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.
| tompic823 wrote:
| 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
| arjie wrote:
| Cool product. Definitely always felt that SSM and Vault were very
| heavyweight solutions.
| blntechie wrote:
| 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.
| tompic823 wrote:
| 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.
| chrisacky wrote:
| 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
| bvallelunga wrote:
| 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.
| fimoreth wrote:
| Sounds interesting, but could you explain to me why I should use
| this over something like Azure KeyVault?
| bvallelunga wrote:
| 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.
| p2hari wrote:
| 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 ...
| rgmvisser wrote:
| 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.
| [deleted]
| bvallelunga wrote:
| 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.
| kbyatnal wrote:
| 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)?
| rgmvisser wrote:
| 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.
| kbyatnal wrote:
| 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.
| stimur wrote:
| you can do similar things with 1Password CLI.
|
| Here is short example: https://github.com/stumyp/ope
| quinndiggity wrote:
| Wait 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 wrote:
| 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.
| quinndiggity wrote:
| 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".
| arsalanb wrote:
| 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!
| megakid wrote:
| This looks neat. Do you have any plans to provide a Kubernetes
| CRD or something else to pull/sync secrets into pods?
| rgmvisser wrote:
| 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.
| jaequery wrote:
| Woah, blown away by their onboarding page after signup. Kudos for
| whoever came up with the concept!
| tompic823 wrote:
| Thank you! Full props to our design guru and CEO @bvallelunga
| for that one.
| jaequery wrote:
| wish more documentations were like this
| tompic823 wrote:
| 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.
| qchris wrote:
| 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?
| bvallelunga wrote:
| 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.
| quinndiggity wrote:
| It 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 | "we
| recreated what these specific competitors which are already
| established made; they sucked, you don't want to use them,
| take our word for it and pay us instead of looking for
| yourself!" https://news.ycombinator.com/item?id=24719722 ) I
| question their morals.
|
| Substantive criticism: your marketing needs not be slinging
| mud, and referencing specific established players in your
| marketing material in order to give false credibility that
| you are a one-for-one replacement is a shady practice. I
| looked at your post solely because it contrasted itself from
| your competitors claiming superiority, and was disappointed
| by all of the above AND that the fact that it couldn't do the
| things it claimed to by making those contrasts.
|
| All in all, disappointed to see a ycombinator funded project
| hoisted on HN with all the above going on, and one with a
| large number of investors behind it and no open source to
| back up their claims. This isn't just a community built tool
| to improve developers' lives, this is a marketing push by a
| corporation with the intent to get a burst of customers with
| misleading/questionable marketing.
| quinndiggity wrote:
| A great example of not trying to play politics/marketing-
| spin to elbow competitors in the face:
|
| https://www.vaultproject.io/docs/vs
|
| ``` More importantly, just as we like to present
| information about Vault and its capabilities in the ways
| that we prefer, we felt it wasn't appropriate to describe
| the capabilities of other projects or products in ways
| other than their own terms. ```
| adriaanmulder wrote:
| 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!
| tompic823 wrote:
| 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-...
| adriaanmulder wrote:
| 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.
| tompic823 wrote:
| Thanks for that feedback, I completely agree. I've
| updated the linked page to mention this more explicitly.
| makethetick wrote:
| 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!
| armatav wrote:
| I've been waiting for something this easy.
| lucasverra wrote:
| 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 ?
| tompic823 wrote:
| 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
| adar wrote:
| 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.
| bvallelunga wrote:
| Nice catch! Pricing page is updated.
| meagher wrote:
| Looks great!
|
| What happens if Doppler is down or if there is a SNAFU when
| syncing the env in production?
| tompic823 wrote:
| 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
| onei wrote:
| 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?
| lukevp wrote:
| 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.
| ampdepolymerase wrote:
| What are your thoughts on Secrethub?
|
| https://secrethub.io
| bvallelunga wrote:
| 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.
| Edmond wrote:
| For folks looking for alternatives, there is also confighub:
|
| https://www.confighub.com/
| kenanpulak wrote:
| 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.
| shay_ker wrote:
| 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.
| bvallelunga wrote:
| - 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.
___________________________________________________________________
(page generated 2020-10-08 23:00 UTC)