Vault vs AWS Secrets Manager vs Doppler: Choosing a Secrets Tool

Vault vs AWS Secrets Manager vs Doppler: Choosing a Secrets Tool#

"Where do we put the secrets" gets answered by inertia more often than by evaluation: whatever cloud you're already on, or whatever a previous engineer set up. That's usually fine, because the wrong answer here is rarely catastrophic, but the right answer depends on things that are worth being deliberate about: how many clouds you're actually on, whether you need secrets that expire on their own, and how much operational overhead your team can absorb.

What each one actually is#

HashiCorp Vault is a full secrets and encryption platform, not just a secrets store. Beyond static key-value secrets, it issues dynamic secrets (short-lived database credentials, cloud IAM credentials generated on demand and auto-revoked), does encryption-as-a-service (transit engine, so apps never handle raw keys), and supports PKI issuance. It's self-hosted (or HCP Vault, HashiCorp's managed offering) and it's genuinely complex to run well: unsealing, storage backends, auth methods, and policy design are all real operational surface.

$ vault kv put secret/myapp/db password="s3cr3t"
$ vault kv get secret/myapp/db

# Dynamic secret: a real Postgres credential, auto-expiring in 1 hour
$ vault read database/creds/readonly

AWS Secrets Manager is AWS-native secret storage with automatic rotation (built-in Lambda rotation for RDS, Redshift, DocumentDB, and a rotation-function template for anything else) and tight IAM integration — access control is the same IAM policies you already use for everything else in the account.

$ aws secretsmanager create-secret --name myapp/db --secret-string '{"password":"s3cr3t"}'
$ aws secretsmanager get-secret-value --secret-id myapp/db --query SecretString

Doppler is a managed, developer-workflow-first secrets platform: a single dashboard and CLI across every environment and every cloud, secrets synced into CI/CD and local .env files without anyone copying them by hand, and no infrastructure for you to run at all.

$ doppler secrets set DATABASE_PASSWORD=s3cr3t --project myapp --config production
$ doppler run -- node server.js   # injects secrets as env vars, nothing written to disk

Where each one actually wins#

Vault wins on capability and multi-cloud reach. Dynamic, auto-expiring credentials are a real security upgrade over long-lived static secrets sitting in any store, and Vault is the only one of the three that does this natively across databases, cloud providers, and PKI. If you're genuinely multi-cloud, or secret leakage is a threat model you're actively defending against (not just a checkbox), Vault's capability ceiling is higher than the other two. The cost is real operational weight: someone has to run it, or you pay for HCP Vault to not have to.

AWS Secrets Manager wins when you're AWS-only and want the boring, native answer. No new tool to learn, IAM does the access control you already understand, built-in rotation covers the common RDS/Redshift case with almost no setup, and cross-region replication is a checkbox. The cost is real too: it's AWS-only (a second cloud means a second secrets story), and rotation for anything outside the built-in templates means writing and maintaining your own Lambda function.

Doppler wins on developer experience and time-to-value. No infrastructure to run, a UI and CLI most engineers are productive in within an hour, native multi-cloud/multi-platform sync (CI providers, Vercel, Kubernetes, local dev), and a genuinely good "keep every environment's .env in sync without anyone pasting values into Slack" story. It doesn't do dynamic secrets or encryption-as-a-service — it's a very good secrets store and distribution layer, not a full secrets platform.

The dimension that actually decides this#

Ignore the feature comparison for a second and ask: who is this for, day to day? Vault is built for a platform/security team defending a real multi-cloud, high-sensitivity environment and willing to own its operational cost. AWS Secrets Manager is built for a team that's already deep in one cloud and wants the path of least resistance inside it. Doppler is built for developer workflow first — getting the right secret into the right environment without friction — for a team that doesn't want to run infrastructure to get there. Most of the actual disagreement about "which secrets tool" traces back to which of those three problems a team is actually solving, not which tool has more checkboxes.

The decision, concretely#

• AWS-only, want native IAM integration and built-in rotation for RDS-style secrets with minimal setup? AWS Secrets Manager.
• Genuinely multi-cloud, or need dynamic/auto-expiring credentials and encryption-as-a-service as real security controls, and can staff the operational cost? Vault (self-hosted or HCP).
• Multi-cloud or multi-platform but the priority is developer experience and zero infrastructure to run, without needing Vault's dynamic-secrets depth? Doppler.
• These aren't mutually exclusive: a team can run Vault for dynamic database credentials while using Doppler to distribute the resulting static config across CI and local dev — they solve different layers of the same problem.

This decision compounds with how the app actually consumes secrets at runtime; see secrets management in practice, from .env files to Vault for that operational side, and Vault as a secrets backend for Kubernetes if Kubernetes is where these secrets need to land.

The call we'd make#

Start with AWS Secrets Manager if you're single-cloud and want the boring, native answer with real rotation for the common cases. Reach for Vault specifically when dynamic secrets or multi-cloud reach are real requirements, not nice-to-haves, and staff for the operational cost that comes with it. Choose Doppler when developer workflow and zero infrastructure matter more than Vault's deeper capability set — and don't discount combining Vault's dynamic-secrets engine with Doppler's distribution layer if you eventually need both.