Redshift vs HashiCorp Vault: When to Choose Each
We get asked about Vault a lot. Fair enough -- it's the default choice for secret management at most companies, and for good reason. But Vault and Redshift are built on fundamentally different assumptions about how secrets should work, and the right choice depends on what you actually need.
The Core Architectural Split
Everything else in this comparison flows from one decision: centralized server vs. decentralized protocol.
Vault: Centralized Server
Vault is a server (or cluster) that your applications connect to. Secrets live in a storage backend -- Consul, PostgreSQL, whatever you configure -- encrypted at rest. Access is governed by policies and auth methods. It's a well-understood model and it works.
- Server required: You run and maintain Vault infrastructure
- Network dependency: Clients need connectivity to the Vault server
- Centralized trust: Vault operators can access all secrets
Redshift: Decentralized Protocol
Redshift stores encrypted secrets on Nostr relays. There's no Redshift server -- just a CLI and web interface that talk to public relays. It's a less proven model, but it eliminates a whole category of operational concerns.
- No server to run: Use public relays or run your own
- Relay redundancy: Secrets replicate across multiple independent relays
- Zero-knowledge: Relay operators can't decrypt your secrets
Where Vault Wins
Let's start here, because Vault genuinely does a lot of things we don't.
Enterprise Compliance
Vault has years of enterprise deployments behind it, SOC 2 certifications, and the kind of compliance documentation that makes auditors happy. If you need specific certification coverage, evaluate products that currently provide it. The Redshift individual product does not offer compliance certification.
Dynamic Secrets
This is probably Vault's best feature. It generates short-lived database credentials, AWS IAM creds, PKI certificates -- created on demand and automatically revoked. Redshift doesn't do any of this, and we don't have plans to. Dynamic secrets fundamentally require the centralized server model that Vault uses.
Access Policies
Vault's policy language is genuinely powerful -- fine-grained rules based on paths, metadata, time windows, identity. Redshift's access model is binary: you have the key or you don't. For large orgs with complex permission requirements, that simplicity is a real limitation.
HashiCorp Ecosystem
If you're already running Consul, Nomad, or Terraform Enterprise, Vault fits right in. That ecosystem integration is a legitimate advantage we can't replicate.
Where Redshift Wins
No Required Redshift-Operated Service
Running Vault in production is real work. The Redshift individual product instead uses relays you select, so no Redshift-operated service is required. Relay selection, availability, and retention still remain your operational decisions.
For an individual developer without dedicated infrastructure staff, that narrower operating model can be useful. It is not a managed availability or retention guarantee.
Actual Zero-Knowledge
Vault operators can read your secrets. That's not a bug -- it's how centralized secret management works. With Redshift, nobody can read your secrets without your private key. Not us, not relay operators, nobody. If that property matters to you, Vault can't offer it by design.
Censorship Resistance
A Vault server can be shut down, blocked, or seized. Redshift secrets are spread across independent Nostr relays around the world. For most teams this is irrelevant, but for some it matters a lot.
Cost
Vault Enterprise is expensive. Vault OSS is free but you're paying in infrastructure and ops time. Redshift is free for individuals -- unlimited projects, unlimited secrets.
Doppler-inspired CLI
If you're coming from Doppler, Redshift's run workflow is familiar, but only Redshift's documented commands and flags are supported. Vault's CLI is more powerful and more complex for day-to-day use.
Feature Comparison
| Feature | Vault | Redshift |
|---|---|---|
| Static secrets | Yes | Yes |
| Dynamic secrets | Yes | No |
| PKI/certificates | Yes | No |
| Self-hosted option | Yes (required) | Optional (run own relay) |
| Managed service | HCP Vault | Not launched |
| Zero-knowledge | No | Yes |
| Free tier | OSS only | Unlimited for individuals |
| Audit logs | Yes | Not currently |
| SSO/SAML | Enterprise | Not launched |
Can They Coexist?
Absolutely. Use Vault for dynamic database credentials and PKI -- that's what it's great at. Use Redshift for static secrets where you want true sovereignty. They solve different problems and complement each other fine.
Bottom Line
If you're a large enterprise with compliance requirements, a platform team, and budget for infrastructure -- use Vault. It's earned its reputation and we're not going to pretend otherwise.
If you're an individual developer or open-source maintainer who wants sovereign static-secret workflows, Redshift may fit. Shared team custody, RBAC, and enterprise controls are not launched.
Give Redshift a try and see if it fits how you work. If Vault is a better fit, no hard feelings -- it's a good tool.
Ready to try Redshift?
Own your secrets with decentralized, censorship-resistant secret management.