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 to check specific certification boxes, Vault is the safer choice today. We're working on compliance, but we're not there yet.
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
Zero Ops
Running Vault in production is real work. Servers, storage backends, upgrades, HA configuration, unsealing -- if you've done it, you know. Redshift piggybacks on existing Nostr relay infrastructure, so there's nothing to deploy or maintain.
If you're a solo dev or small team without dedicated DevOps, Vault's operational overhead can be a dealbreaker. That's the problem we originally built Redshift to solve.
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-Compatible CLI
If you're coming from Doppler, Redshift's run command is a drop-in replacement. Vault's CLI is more powerful but also 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 | Redshift Cloud |
| Zero-knowledge | No | Yes |
| Free tier | OSS only | Unlimited for individuals |
| Audit logs | Yes | Yes (Cloud tier) |
| SSO/SAML | Enterprise | Coming soon |
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, small team, or open-source project that doesn't want to run infrastructure just to manage secrets -- that's who we built Redshift for. We also think it's worth a look if secret sovereignty matters to you, regardless of team size.
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.