Capy vs SOPS

SOPS is a long-running primitive that works well. It does one thing: encrypt a YAML, JSON, or .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. This comparison covers when Capy is the right SOPS alternative and when it isn't.

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 is capy 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 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.

When Capy is the right SOPS alternative

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.