Secrets management tools compared: AWS Secrets Manager, HashiCorp Vault, Doppler, and WorkOS Vault

If you google "secrets management tools," you will find a lot of comparison posts that list features and end with "it depends on your use case." This is not one of those posts.

The tools in this comparison do not all solve the same problem. They solve different problems, and teams get into trouble when they pick a tool based on name recognition rather than what they actually need to store, who needs to access it, and what security guarantees they need to provide to their customers.

This post covers four tools: AWS Secrets Manager, HashiCorp Vault, Doppler, and WorkOS Vault. It explains what each was actually built for, where it excels, where it struggles, and the situations where one is clearly the better fit. The goal is to help you make the right call the first time rather than migrate later.

The two different types of secrets

There are two fundamentally different secrets problems, and different tools are built to solve them.

• ‍Infrastructure secrets are the credentials your systems use to talk to each other: database passwords, API keys for third-party services, TLS certificates, service account tokens, SSH keys. These are mostly static, stored at the infrastructure level, and accessed by services rather than by users. The problem here is sprawl: credentials copied into environment files, hardcoded in config, shared in Slack, never rotated. The goal is centralization, auditability, and rotation.‍
• User data secrets are sensitive values that belong to specific users or organizations in your application: PII, OAuth tokens acquired on behalf of a customer, API keys that your customers give you to integrate with their services, encryption keys tied to a specific tenant. These are accessed at the application layer, linked to a user or organization identity, and often need to be cryptographically isolated from each other. The goal is not just centralization but per-entity key isolation and the ability to offer customers control over their own keys.

AWS Secrets Manager, HashiCorp Vault, and Doppler are all primarily built around the infrastructure secrets problem: centralizing credentials, syncing them to where your services run, and managing rotation. ‍

WorkOS Vault covers both. It stores infrastructure secrets with the same encryption primitives as the others, but adds something they do not have: per-entity cryptographic isolation via key context, where each secret is scoped to an organization, user, or other metadata boundary with a separate encryption key derived per context. That is what enables BYOK and the guarantee that one tenant's key cannot decrypt another's data.

Most teams need to think clearly about which problem dominates before choosing a tool. If you need credentials stored and synced across environments, any of these tools can serve you. If you also need cryptographic isolation between the entities in your application, key context is the primitive that makes it possible.

With that distinction made, here is each tool in detail.

AWS Secrets Manager

AWS Secrets Manager is a managed service for storing and rotating credentials within the AWS ecosystem. It handles database passwords, API keys, and other static credentials that your AWS services need to function. If your infrastructure runs primarily on AWS, it is the path of least resistance because it integrates directly with RDS, Redshift, Lambda, and IAM.

Where it works well

For AWS-native teams, the integration story is genuinely good. Automatic rotation for RDS and Redshift credentials is built in and requires no custom code. Cross-region replication means your secrets are available even during a regional outage. IAM policies give you fine-grained access control that your security team can manage alongside the rest of your AWS permissions.

If you are a startup running everything on AWS and you need a place to store your database credentials and third-party API keys that is better than a .env file, Secrets Manager is a reasonable choice. Setup is fast, the pricing is predictable at small scale, and you do not need to manage any infrastructure.

Where it struggles

The AWS lock-in is real. If you ever run workloads outside AWS, whether on another cloud, on-prem, or in a developer's local environment, accessing Secrets Manager requires AWS credentials and SDK integration. Teams with hybrid or multi-cloud infrastructure find this becomes an operational headache quickly.

Pricing is $0.40 per secret per month plus $0.05 per 10,000 API calls. The per-secret model sounds cheap until you count your actual secrets. A typical product with 50 secrets across three environments (dev, staging, production) is already 150 secrets, at $60 per month before API call costs. High-frequency polling or Lambda functions that fetch secrets on every cold start can push API costs up unexpectedly.

Secrets Manager is also not designed for application-layer data encryption. You cannot use it to store per-tenant PII or provide customers cryptographic isolation of their data. It is a credential store, not an encryption service.

Who it is right for

AWS Secrets Manager is right for teams that run exclusively on AWS, need infrastructure credential management, and want zero operational overhead. It is not the right tool if you need multi-cloud support, developer-friendly workflow tooling, or any kind of per-user or per-tenant data encryption.

HashiCorp Vault (now IBM HashiCorp)

HashiCorp Vault is the most powerful and most complex tool in this comparison. It was built for organizations that need total control over their secrets infrastructure: multiple auth backends, dynamic secrets (credentials generated on demand and automatically revoked), PKI infrastructure, encryption as a service, and the flexibility to run anywhere from bare metal to cloud to Kubernetes.

It is the choice for large enterprises with dedicated security engineering teams, complex compliance requirements, and the willingness to invest in configuration and operations.

Where it works well

The dynamic secrets feature is genuinely differentiated. Instead of storing a long-lived database credential, Vault generates a unique credential for each requesting service, with a TTL of minutes or hours. When the TTL expires, the credential is automatically revoked. There is nothing long-lived to steal. For organizations where a compromised credential sitting in a config file is an existential risk, this is a meaningful architectural improvement over static credential stores.

Vault's flexibility is also real. It supports dozens of auth backends (Kubernetes service accounts, AWS IAM, LDAP, GitHub, and more), dozens of secrets engines, and can integrate with almost any infrastructure stack. For large organizations with heterogeneous environments, this breadth is necessary.

Where it struggles

The complexity is the cost of the flexibility. Running Vault in production means managing the cluster, the storage backend, the seal mechanism, high availability, and upgrades. Teams consistently underestimate the operational burden. Dynamic secrets in particular require planning: the application needs to handle credential rotation mid-request, which is not trivial.

IBM completed its $6.4 billion acquisition of HashiCorp in February 2025. Since then, community engagement and support response times have slowed, and the product lineup has been rationalized, with HCP Vault Secrets sunset in mid-2025 and the Starter tier discontinued. For teams that were on those products, the migration path leads to significantly more expensive options.

The BSL license change from August 2023 means Vault is no longer open source under an OSI-approved license. Teams that depended on the open-source model now have commercial licensing questions to navigate. The OpenBao fork under the Linux Foundation exists for teams that want a genuinely open-source Vault-compatible alternative, but it is a different bet.

Enterprise pricing is not published. Expect an annual contract negotiated through IBM sales, sized primarily by client count, where a client is any user, application, or service that authenticates to Vault.

Who it is right for

HashiCorp Vault is right for large enterprises with complex, multi-environment infrastructure, dedicated DevSecOps capacity, and genuine requirements for features like dynamic secrets or PKI management. It is not the right tool for teams that want to ship product rather than operate infrastructure, or for teams that were relying on the open-source licensing model.

Doppler

Doppler is built around the idea that secrets management should not require any infrastructure, any cryptography knowledge, or any significant configuration. You define your secrets once in a central dashboard, and Doppler syncs them to wherever your application runs: Kubernetes, AWS, GitHub Actions, Heroku, local dev environments, and more.

The core abstraction is an environment config: a named collection of secrets for a specific project and environment (dev, staging, production). Syncs keep those secrets current wherever they are deployed.

Where it works well

The developer experience is the genuine strength. The Doppler CLI injects secrets as environment variables at runtime, which means local development looks identical to production from the application's perspective. Onboarding a new developer to a project means giving them Doppler access, not handing them a list of secrets to copy into a file.

The pricing model is also well-designed for development teams. Doppler charges per seat rather than per secret or per API call, which means cost does not grow with the number of secrets or environments you have. The Team plan starts at $12 per user per month billed annually, with unlimited projects and environments. For a team that would otherwise spread credentials across hundreds of secrets in AWS Secrets Manager, the flat seat-based model is often cheaper in practice.

Doppler also has a thoughtful multi-environment inheritance model. A root config defines shared secrets, and environment-specific configs inherit and override. This mirrors how most teams actually think about configuration.

Where it struggles

Doppler is a secrets sync and distribution tool more than an encryption service. It is very good at getting the right secret to the right place. It does not provide per-tenant cryptographic isolation, application-layer encryption of user data, or BYOK. If your security requirement is "each customer's data is encrypted with a key they control," Doppler is not the tool for that.

The closed-source SaaS-only architecture is a constraint for some teams. Organizations with data residency requirements or compliance programs mandating self-hosted deployments will find the options limited. Doppler does offer an on-premises product, but it is enterprise-tier with custom pricing.

Some capabilities on the Team plan are add-ons at $9 per seat per month each, including custom roles, user groups, and expanded integration syncs. If you need two add-ons, the effective seat cost is $39 per month. The headline price is not always the full picture.

Who it is right for

Doppler is right for development teams that need to centralize and sync environment configuration across environments and services, want a great developer experience, and do not have complex compliance requirements around key control. It is not the right tool for application-layer data encryption or per-tenant key isolation.

WorkOS Vault

WorkOS Vault is an EKM (Encryption Key Management) service that stores and encrypts any type of object: tokens, passwords, certificates, PII, API keys, files, and other sensitive data. Where it differs from the other tools in this comparison is the key architecture underneath. Every object is encrypted with a key derived from its key context, a set of metadata you supply when storing it. Each unique context gets a cryptographically isolated key.

That distinction matters most for B2B SaaS companies. Storing your own infrastructure credentials (API keys, database passwords, service tokens) in Vault works the same as any other secrets manager. But when you need to store data that belongs to your customers, scoped to their organization, and isolated from every other tenant's data, key context is the primitive that makes it possible. Two organizations' data cannot be decrypted with the same key, by design.

This is the tool you reach for when you need to answer the question: "if our database were leaked, could an attacker read our customers' data?" With Vault and per-tenant key context, the answer is no. With a credential store that uses shared encryption, the database is still plaintext.

Where it works well

The key context model makes per-tenant cryptographic isolation trivial to implement. Where a traditional approach would require building a key registry, managing key lifecycle, and handling rotation manually, Vault derives keys from context automatically. You do not manage key IDs. You set the context once per object, and Vault handles the rest.

  
// Each org's data is encrypted with a cryptographically isolated key
const object = await workos.vault.createObject({
  name: 'acme-stripe-key',
  value: 'sk_live_...',
  context: { organizationId: 'org_acmecorp' },
});
  

BYOK (Bring Your Own Key) follows naturally from the same architecture. Once you are using per-tenant key context, offering an enterprise customer their own customer-managed key (CMK) in AWS KMS, Azure Key Vault, or GCP KMS is a configuration step in the WorkOS Admin Portal, not an engineering project. The application code does not change.

The full CRUD lifecycle (create, read, update, delete) includes useful primitives that matter for real applications: describeObject for reading metadata without decrypting, versionCheck for optimistic concurrency control on updates, and listObjects with name search for auditing before deletion. These are the operations that make the difference between a toy implementation and one you can run in production.

For GDPR right-to-erasure compliance, the model is clean. PII lives only in Vault. Deleting a user's data means calling deleteObject for each of their Vault objects. There is no risk of forgetting a database column, an analytics copy, or a backup table.

Where it struggles

The key context model delivers the most value when your application has meaningful tenant boundaries. If you are not building a multi-tenant product and do not need to offer customers cryptographic isolation or BYOK, the isolation guarantees Vault provides are more than you need, and a simpler credential store will serve you well.

Who it is right for

WorkOS Vault is right for any team that needs encrypted secret storage, and especially right for B2B SaaS companies that need per-tenant cryptographic isolation without building a key management system themselves. If offering enterprise customers BYOK is on your roadmap, or if "your data is encrypted and mathematically isolated from every other tenant" is a promise you need to make and keep, Vault is the tool built for that.

Choosing the right tool

Most production applications need more than one of these tools. Here is a practical framework for deciding which combination fits your situation.

If you are running on AWS and need to store application credentials: start with AWS Secrets Manager. It is the simplest path for RDS passwords, third-party API keys, and other infrastructure credentials if your stack is AWS-native.

If you have a large, heterogeneous infrastructure and need dynamic secrets or PKI: HashiCorp Vault is the answer, with the understanding that you are also committing to operating it. Make sure you have the engineering capacity before choosing it.

If you want a great developer experience for secrets distribution across environments: Doppler is the strongest choice in this category. The sync model, the CLI, and the environment inheritance make it genuinely pleasant to use. For teams that have outgrown .env files and want a managed service rather than infrastructure, it is the right call.

If you need encrypted secret storage and want per-tenant cryptographic isolation or BYOK: WorkOS Vault is the right choice. It handles both infrastructure secrets and user data secrets, but the key context model is what sets it apart. No other tool in this comparison derives per-entity encryption keys from metadata automatically, which is what makes tenant isolation and BYOK possible without a custom key management implementation.

The question to start with

Before evaluating any tool, answer two questions: what are you storing, and who needs cryptographic isolation from whom?

If the answer to the second question is "nobody, we just need credentials centralized and synced," then AWS Secrets Manager, HashiCorp Vault, or Doppler will each serve you well. Pick based on your infrastructure, your team's appetite for operational complexity, and your developer experience requirements.

If the answer is "our customers need to know their data cannot be read by another tenant, or by us, without their key," then key context and BYOK are the features that matter. That is where WorkOS Vault is specifically designed to help, and where the other tools in this comparison do not go.

Most B2B SaaS companies at scale end up needing both: a secrets manager for infrastructure credentials and a key-context-based encryption service for customer data. Getting that distinction clear before you start evaluating saves migration pain later.

Further reading

• Vault quick start: get started with application-layer encryption in minutes.
• Encrypting PII in a Node.js app with WorkOS Vault: a full tutorial covering the CRUD lifecycle.
• Cryptographic key isolation in multi-tenant SaaS: the deep dive on per-tenant key isolation.
• Envelope encryption explained: how the DEK and KEK model works and why it matters.
• BYOK documentation: letting enterprise customers supply their own encryption key.
• Why building your own BYOK is a trap: the fastest and safest way to implement BYOK.