The Hidden Costs of Centralized Secret Management

I spent a weekend migrating off a secret manager last year. Not because it was bad software, but because the vendor got acquired and the new owners tripled the price on our tier. Two days of my life, rewriting CI pipelines and rotating credentials, because someone else controlled where our secrets lived. That experience got me thinking about all the ways centralized secret management costs you beyond the monthly bill.

You can check in, but you can't check out

Every secret manager has its own API, its own CLI syntax, its own way of organizing data. That's fine on day one. By month six, you've got it wired into your CI/CD, your deployment scripts reference it by name, your onboarding docs all assume it exists. You're locked in, and the vendor knows it.

We've watched this play out over and over. HashiCorp changed Vault's license to BSL and teams that had built their entire infrastructure around it suddenly had to consult lawyers. Heroku killed its free tier overnight. Docker slapped rate limits on pulls that had been free for years. The playbook is always the same: get developers hooked with generous terms, wait until switching costs are high, then change the deal.

The worst part is that migration isn't just "point at a new API." It's re-auditing access controls, re-testing every integration, and hoping nothing breaks in production at 2am. Most teams just eat the price increase because the alternative is worse.

Compliance gets weird fast

If you work in a regulated industry, try answering these questions about your secret manager: Where are your secrets physically stored right now? Which employees at the vendor have access to the underlying infrastructure? What jurisdiction are those servers in, and whose subpoena power applies to them?

Most teams can't answer any of those confidently. And it gets worse during audits. Your auditor asks where your production database credentials live, and the honest answer is "on servers we don't control, in a region we think is us-east-1, managed by people we've never met." That's not a great answer. If the vendor gets breached, you might find out from a news article before their incident response team gets around to notifying you.

When the service goes down, you go down

Every major cloud provider has outages. This isn't controversial, it's just reality. But when your secret manager is down, it's not like a CDN outage where pages load a bit slower. You literally cannot deploy. You can't rotate credentials. You can't onboard a new service. You're stuck.

I've seen teams hit API rate limits during an incident response, right when they needed to rotate a compromised key. And account suspensions happen too, sometimes over something as dumb as a billing dispute or an expired credit card. Imagine explaining to your CTO that production is down because your corporate card got flagged for fraud and the vault provider auto-suspended the account.

Trust is a liability

This is the one that bothers me most. When you use a centralized provider, you're trusting their employees won't go rogue, their security practices are actually as good as their marketing claims, and that the company will still exist and care about your use case in three years. You can't audit their implementation. You can't verify their access logs. You just... trust.

That's a lot of trust to extend to an organization you have zero visibility into. And every additional trust relationship is another surface area for things to go wrong. This isn't paranoia. It's the same risk calculus you'd apply to any other dependency in your stack.

Who actually owns your secrets?

Here's what keeps me up at night: if a provider can revoke your access to your own secrets, are they really yours? They can change their ToS. They can be compelled by a government to hand over your data. They can shut down with 30 days notice and a "thanks for being a customer" email. For most commercial SaaS teams this is an acceptable risk. But for open-source projects, independent developers, journalists, or anyone operating in a politically sensitive context, this is a non-starter. Your secrets should survive your relationship with any single vendor.

What we built instead

Redshift sidesteps all of this. Your data uses standard Nostr protocols, so there's no proprietary format locking you in. Secrets replicate across independent relays, so no single outage takes you down. Everything is encrypted client-side before it ever leaves your machine, so there's no trust required in relay operators. Your keys, your data, full stop.

Yeah, there's a learning curve. But it's a one-time cost, not a compounding one. Every month you spend on a centralized provider, the switching costs get higher and your leverage gets lower.

Questions worth asking

Before you sign up for (or renew) any secret management service, sit with these for a minute: What does it actually look like to leave this vendor? Not in theory, in practice, with your current integrations. What happens to your deployments if they have a bad day? And what happens to your data if they get acquired by someone who doesn't care about your use case?

If you don't like the answers, give Redshift a look. It's free, it's open, and your secrets stay yours.