Show HN: Capy – A Git-style platform for managing your team's secrets | Hacker News Reader

Show HN: Capy – A Git-style platform for managing your team's secrets

github.com

13 pointscvince13 comments

Hello HN!

We're all spending more and more time making stuff with agents, but I've noticed that one of the things that is the most disconnected from my daily engineering workflow is dealing with secrets and credentials. It often involves a lot of click-ops, copying/pasting, and collaboration, and none of the secrets management products out there have truly scratched that itch.

I built Capy to solve this. It's a secrets manager whose entire frontend is a developer CLI, and I find it extremely ergonomic to use by hand. You also don't need to leave the CLI to sign up for and use it! You can install and authenticate without leaving your terminal (or agent) session.

It also has very powerful version management with git-like branching and conflict resolution. You can push a version manifest to source control and have collaborators pull a specific version of the secrets at any point in time.

The platform itself is extremely secure. It encrypts your local .env files so they can't be read directly. Upon pushing the values to the service, it encrypts them yet again with a service key. That way neither a compromised local machine nor a compromised service alone will result in a leakage.

BTW: Since it was released in April, I've been refining it and have evolved the focus a bit. Originally I was going for more TUI and TTY with guided wizards for doing things like deployments, rotations, and connecting services, but I realize that the real future is in making the product work EXTREMELY well with agents.

So the next evolution of is a more satisfying Agent ergonomic, and I have been working on something big next on that front.

Curious about your thoughts on the idea, execution, and would appreciate any and all feedback!

Open articleView on HN

Need to try this out and dig into it as a secrets option for my current dev team. We've been having issues coordinating secrets securely and easily across different projects.

How does this compete with built in secrets management already available in Coder, Claude, and Copilot?

Do I need another “C” in my workflow?

I'd say the two biggest things are Portability, and Ergonomics.

For portability your secrets in those platforms can't move around with you, but with Capy they can move with you wherever you're doing your work. Your local machine, your sandbox, etc.

Capy also helps you deploy your secrets into Coder, Claude, Copilot and whatever other Clever product you prefer to use ;)

For ergonomics, Capy is built from the ground up as a CLI, which means it's extremely flexible in where you want to use it. I'm also working currently on making it work SUPER well in agentic coding workflows. There's going to be more on that coming soon!

This has been needed long before agents were a thing - and now with agents, even more so! Excited to try it out. But I would like to understand more about the security posture. What documentation do you have for how Capy keeps secrets safe?

Capy uses a split-key encryption model, meaning secrets are encrypted client-side before reaching our servers—so the backend never sees or stores raw plaintext keys. The design is also pretty unique in that it can be used to cryptographically revoke local secrets remotely.

You can read more about it here: https://www.capy.sc/docs/internals/zero-trust

In addition, the company is right around the corner on our SOC2 Type I audit. It should be available within the next week!

https://trust.capy.sc/

Very interesting, so would you consider yourself more secure than other tools like doppler because of the split secret management? Are you going to build an MCP for this?

Absolutely. Doppler custodies the credentials entirely themselves, and Infisical ditched zero-trust earlier on citing complexity and UX concerns - IMO they just didn't try hard enough ;)

I also decided to embrace .env because that's how humans (and apparently agents -- for now) like to work when building stuff. Except Capy is the only solution I know of that allows you to cryptographically revoke access to those .env files in real time.

Regarding the MCP, watch this space: https://www.capy.sc/

Looks pretty cool, what steps are you taking to ensure that the backend is secure?

On the crypto side, the values are encrypted client-side before they’re sent. This means the service stores ciphertext it has no ability to decrypt. So the worst case for a backend compromise is someone getting encrypted blobs plus some metadata.

On the controls side, SAST scanning in CI, and minimizing deps as much as possible in the client and the service.

it looks super but I am more concerned about agentic determinism , because still they do change behavior, so curious how you are controlling it

I love this question, because it's something I've been thinking about a lot for the next evolution of this product. My solution, currently, is that the CLI provides all the guardrails.

All the security and logical primitives are enforced via the CLI's command layout, similar to how it is done with git, and the human is still in the loop for the most critical stuff like initial onboarding, saving secrets, resolving conflicts, running deployments, and performing rotations.

I do eventually want to find safe ways for agents to take over those tasks, and there is a lot to learn from how software factory agents currently work with git. The thing is, even with software factories, the VERSION CONTROL gates are also usually still defined by humans (when to commit, merge, deploy, etc.). Whatever it is, the same level of automation ought to exist for secrets and configuration.

To that end, I have an upcoming MCP that acts as a wrapper for orchestrating sequences of Capy CLI commands (but never the contents of them). In the preliminary MCP implementation there's nothing the agent is actually able to interpret, besides maybe identifying variable names, what the stack looks like, and what services the application likely uses.

Good idea

Thanks! Try it out and let me know what you think!

Reply on news.ycombinator.com