HashiCorp Vault is considered by many to be the gold standard against which other secrets management tools are measured.
If Vault were a vehicle, it would probably be a Humvee. Tough, infinitely configurable, able to tackle any possible scenario you can throw at it. But if you were buying a new car today, would a Humvee be the best choice? How would you decide, and what factors should you take into consideration?
In this post, we'll summarize our strengths compared to Vault and highlight the different approaches they take in managing and delivering secrets to applications.
While Vault is an exceedingly good Key-Value store for secrets, it wasn't designed with the conceptual model of an application developer that requires secrets to be organized by microservice, CI/CD, and multi-cloud deployment platforms. Unifying the different expectations that product and security teams have for how a secrets manager should be operationalized is one of the most significant challenges organizations face in gaining widespread adoption of any secrets management solution.
The first hurdle organizations may face when implementing Vault is the heavy burden placed upon developers and product teams to define, design, and implement how secrets will be extracted from Vault's Key-Value store and injected into their application.
If developers find a secrets manager too difficult to implement, they may use unvetted and/or homegrown secrets management solutions. This makes secrets management not just a security consideration but a productivity one as well.
The additional development effort required by product teams to integrate a complex solution like Vault into their applications may consume precious time and resources that could've contributed to building new features to meet product goals and revenue targets. A secrets manager must deliver immediate security and productivity benefits.
Doppler was founded on the belief that the requirements of both security and software engineers could be met equally well, minimizing the time required to integrate a secrets manager while still meeting the most stringent security requirements.
The open source nature of Vault is attractive in that it's free to get started. However, the time and expertise required to meet even the most modest production deployment requirements are significant and beyond what most developers could achieve on their own.
A production-ready Vault instance must (at a minimum) be a multi-server, load-balanced cluster with a HA capable backend plus request forwarding and client redirection correctly configured for failover scenarios.
Add to this the engineering resources required for ongoing support and maintenance, plus cloud hosting fees, and it soon becomes apparent why many organizations are looking for a more cost-effective, easier to manage solution.
In contrast to Vault's self-hosted open source option, Doppler offers a completely managed service with:
Vault is essentially a Key-Value secrets store, requiring developers and Vault administrators to determine and agree on how secrets will be organized (e.g. /com/app-name/production/db-user).
While flexible, this manual path-based approach can be prone to error. Vault also does not provide a visual diffing mechanism for comparing application secrets between environments, making it challenging to ensure all environments are configured correctly at a glance.
Doppler was built for today's microservice world, organizing secrets by application with a customizable list of environments for each application.
Beyond just organizing secrets, Doppler's dashboard tracks all secret operations, displaying them in a git log-style format. The dashboard visually highlights configuration discrepancies between environments, such as a secret present in staging but not production.
The ease in which developers and security folks can use the Doppler dashboard to quickly organize and view the state of secrets across all environments is significantly faster than Vault's CLI.
Doppler uses the industry-standard mechanism of environment variables for app secrets and configuration.
Environment Variables are ideal as they are language and framework agnostic, with the added benefit of moving the concern of populating app config and secrets to the deployment or runtime layer. This enables the application to run the same way in every environment without code changes, environment-specific data structures, or conditional logic.
The extraction of secrets from Vault for injection to applications often requires language or platform-specific SDKs or consuming secrets directly from Vault's RESTful JSON API, often on a per-application basis. The authentication method by which an operator, application, or machine will be identified and authorized for secrets retrieval is another implementation detail both developers and security teams must consider and agreed upon.
Doppler simplifies access to secrets by using service tokens which provide read-only access to secrets in a specific Doppler environment. Secrets can then supplied to an application by the Doppler CLI, a standalone binary that acts as an application runner, spawning a child process and injecting the secrets into the process as environment variables.
The Doppler CLI can also supply secrets in JSON, YAML, and .env format for applications that prefer a config file approach. However, we actively discourage this practice to avoid unencrypted secrets touching the file system.
Doppler continues to attract customers that were previous Vault users for one or more of the following reasons:
- They weren't using enough of Vault's feature set, such as dynamic secrets and automated rolling and provisioning of secrets, to warrant the complexity.
- There is no off-the-shelf solution for using Vault in local development, with many teams resorting to individual developers running their own Vault instance on their development machines.
- The team responsible for maintaining and supporting Vault wasn't allocated the necessary resources to meet HA requirements, resulting in service interruption, which caused production interruptions when secrets were unable to be fetched during deployment.
- Developers struggled to integrate their applications with Vault due to the complexity and steep learning curve. Instead, teams rolled their own (often limited and insecure) secrets management solution or just used plain text .env files (which should be avoided whenever possible).
- The managed Enterprise or HCP Vault offerings were too expensive.
These issues don't fault Vault as a system or secrets manager. It simply highlights how teams can struggle to justify the expense and effort required to continue using Vault long-term.
Teams appreciated how they could evaluate Doppler with an existing production-facing application in minutes and for free. Doppler's specific workflow for local development and the transition to using environment variables ensured that the migration process was quick and painless, simplifying application deployment and secrets fetching.
Vault's Web UI is unfortunately very limited and provides only a tiny fraction of Vault's full capabilities, leaving most secrets management tasks to be performed using the CLI.
In contrast to this, Doppler's dashboard is a first-class citizen. It puts critical aspects of secrets management front and center, such as:
- Flexible user account provisioning and access via SAML SSO, Email SSO, and SCIM.
- Git-style secret activity log with the ability to rollback changes.
- Ability to compare and monitor secret changes across environments.
- Manage secrets access at the project and environment level. For example, you can limit developers to accessing the dev environment while granting DevSecOps access to every environment.
- Easily set up integrations for syncing secrets to third-party secrets managers, such as AWS Parameter Store or Azure Vault.
- Restrict secrets access to specific CIDR ranges for staging and production environments.
The Doppler dashboard makes secrets management simple, quick, and easy, saving time and effort.
Virtual Machines, Docker Containers, Serverless, No-Code, and Multi-Cloud deployments — the current DevOps landscape means deploying to multiple platforms has become the norm.
Progressive organizations embrace a multi-cloud deployment strategy, e.g. AWS Lambda for serverless, Vercel for front-end applications, and GKE for containerized workloads. This presents a challenge to customers using Vault as it's bound to a specific cloud provider, often with tight integration into the IAM policies for that cloud provider.
One of the primary benefits of a secret manager is centralizing secrets storage, essential for fine-grained access control, auditing, and taming secrets sprawl. But this centralization of secrets can come at the cost of additional complexity in applications being forced to integrate with Vault directly and not being able to use the native secrets storage solution built into many platforms such as AWS Lambda, Vercel, Heroku, and cloud-specific secret managers.
Our philosophy at Doppler is to provide a single source of truth for secrets management and storage but support automated secrets integration syncing to any external secrets store. This could be the secrets store for Cloudflare Functions, Azure App Services, of AWS Secrets Manager. Check out our ever-growing list of integrations to learn more.
It's a win-win for developers, providing a frictionless secrets access experience when using a platform's native secret storage capabilities (e.g. Netlify environment variables) while gaining all the operational benefits the Doppler dashboard provides.
Doppler gives you the benefits of a centralized secrets manager without forcing developers to integrate directly with Doppler on every platform.
HashiCorp Vault is an incredibly powerful, flexible, and configurable secrets manager, but with this power, comes a steep learning curve, formidable complexity, and a non-trivial amount of design decisions to get up and running and integrate with your application.
We're finding that for most companies, Doppler's multi-cloud integration model, focus on developer productivity, streamlined authentication and access model, plus support for every environment (including local development), caters well to the needs of all but the most demanding applications.