SOPS is a long-running primitive that works well. It does one thing: encrypt a YAML, JSON, orDocumentation Index
Fetch the complete documentation index at: https://capy.sc/docs/llms.txt
Use this file to discover all available pages before exploring further.
.env file value-by-value to one or more recipient keys (age, PGP, AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault), leave the file committable to git, and decrypt at runtime for whoever holds a corresponding key. If you have a platform engineering team that already runs KMS or Vault and treats encrypted-config-in-git as the source of truth for everything from database credentials to Helm values, SOPS belongs in that workflow.
Where the conversation gets interesting is in everything SOPS leaves to the adopting team.
At a glance
| Capy | SOPS | |
|---|---|---|
| What it ships | Productized system around client-side encryption | Cryptographic primitive only |
| Where encryption happens | On the client | On the client |
| Vendor in the path | Mediating service holds ciphertext and the outer wrap | None — keys live with you |
| Onboarding a teammate | capy invite — service issues a wrap | Generate an age key, re-encrypt every file to add their public key |
| Removing a teammate | capy kick — cryptographic, no rotation needed | Re-encrypt every file to remaining recipients; rotate values the leaver could have decrypted |
| Recipient-key registry | Implicit in team membership | You build and maintain it |
| Rotation runbook | Not needed — revocation is structural | You build and maintain it |
| Secret diffs in PR review | keep.lock manifest with hash references | Encrypted file diffs |
| Git-branch alignment | Branches pin to your git branches | None built in |
| File format coverage | .env only | YAML, JSON, ENV, INI, binary |
| Key backends | Capy’s two-party wrap | age, PGP, AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault |
| AI-agent blast radius | Only what capy run -- is currently injecting | Whatever the local age/KMS key can decrypt while the agent runs |
What teams build around SOPS
SOPS itself does not ship a recipient-key registry, a rotation script, an onboarding checklist, a CI-decryption step, or a runbook for emergency revocation. Adopting teams build all of these. A new engineer joins; they generate an age key; someone re-encrypts every relevant file to add their public key; a PR lands. An engineer leaves; the careful version of the response is to re-encrypt every file to the remaining recipients, and rotate any value the leaver might have decrypted in the past. The deploy pipeline acquires a step that fetches a master key from KMS or Vault, decrypts the file, and hands the plaintext to the application. None of these steps are unreasonable; all of them are real engineering, and almost all of them are invisible to the engineers who didn’t build them. This is what most adopting teams describe (out loud or implicitly) as the cost of SOPS. The cryptographic primitive is free; the operational system around it is not.What Capy ships in place of that system
Capy is essentially an answer to the question of what that surrounding system should look like, productized so a team adopting it doesn’t have to build it from primitives. The recipient-key registry is implicit in the team membership the service tracks. Onboarding iscapy invite; the new member’s machine generates its own keypair, the service hands them a wrap they can use, and no existing recipient list has to be updated by hand. Revocation is capy kick. It does not require re-encrypting every file or rotating values, because the service-side outer wrap on the kicked user’s key is destroyed and their local key material becomes inert; remaining members keep their keys unchanged. The committable artifact in your repo is the keep.lock manifest, a list of hash references rather than the encrypted values themselves, which makes secret diffs PR-reviewable without showing what changed.
The trade is that Capy is built for the developer-and-team .env workflow rather than the broader file-format and key-backend coverage SOPS has. Encrypting Kubernetes manifests to multiple cloud KMSes is a SOPS workflow, not a Capy one.
How to choose
If your platform team already owns the SOPS surrounding system, has built the onboarding and rotation scripts, and is comfortable with the runbooks, switching is rarely worth the disruption. Tools that are working should keep working. If you are picking up the conversation fresh (your team uses.env files, you don’t currently run KMS, and the surrounding system would be net-new engineering), Capy is the version of that system you don’t have to maintain. The bet underneath that choice is straightforward: the cryptographic property both tools give you is the same in spirit, and the difference that decides the buying choice is who maintains the operational system around it.