Building a Secrets Manager in a weekend

Hello I'm CJ Brewer, and my full time gig is VP Operations at CipherStash.

So I've got this problem. CipherStash has genuinely great tech (a zero trust KMS, ZeroKMS, and searchable encryption) that lets you keep sensitive data encrypted while it's actually being used, not just at rest or in transit. The whole "encryption-in-use" method shifts the trust boundary from systems to data itself, which is objectively the right way to think about security in 2026.

But here's the thing: the company has been around for 5 years, spent a bunch of VC money to get the crypto right, and now the team is ready to scale. The sales cycles are long, and honestly, that's a good thing. It means organizations are taking security seriously and making careful decisions, which is what you want for software that handles sensitive data. But even as enterprises work through those processes, I want developers to be able to jump in and immediately see the security value of what we're building.

Enter Stash.

The hypothesis

Build a secrets manager on top of the core CipherStash ZeroKMS primitives. Give developers that stupid-easy onboarding experience they expect from modern dev tools. Prove that encryption-in-use isn't just enterprise security theater, it's genuinely a better security model for modern apps. Oh, and maybe build a community and help with GTM while I'm at it.

Ironically, CipherStash has historically avoided the whole "vault" concept because the main value prop is that you don't need an external system. You can just use your database with CipherStash and keep everything encrypted in your systems. But for a secrets manager, developers expect a vault. They expect something purpose-built.

Fair enough.

Weekend builds require good foundations

Here's where it gets fun. Supabase just released Supabase for Platforms, which lets you spin up isolated Supabase projects programmatically. So every Stash workspace gets its own Supabase instance - isolated, encrypted, provably zero-trust.

And because I'm using CipherStash's encryption-in-use, all that data stays fully encrypted and searchable. The Supabase platform handles the infrastructure, CipherStash handles the security model, and ZeroKMS provides the access intelligence that compliance teams and regulators actually care about.

I built the whole thing over a weekend.

Developer experience was non-negotiable

I didn't want to just slap an API on top of CipherStash's encryption primitives and call it a day. Stash needed to feel like the dev tools you already love - think Resend for email, Vercel for deployment, or Supabase for databases, that kind of experience.

Building for TypeScript first was a no-brainer, since I'm a TypeScript guy. The Stash CLI and SDK ship in CipherStash's existing @cipherstash/protect package, so if you're already using Protect.js for encryption, you've got Stash ready to go. And if you want to roll your own data security solution using the same primitives, the interfaces are right there.

What I'm really testing

Look, I don't know if Stash gains traction or not. What I'm really curious about is whether developers will feel the difference when they're using a security tool that's provably zero-trust by design versus just trusting that some system somewhere is doing the right thing with their secrets.

That's the bet. I'll see how devs react.

If you're curious, check out Stash. Would love to hear what you think!

Cheers

Disclaimer: These are my personal thoughts and experiences and do not represent the views of CipherStash.