Capy vs dotenvx

dotenvx implements a long-standing approach: encrypt the values in your .env to a public key, commit the encrypted file to git, hand the corresponding private key to anyone who needs to decrypt at runtime. There is no service in the path, no account to create, and no vendor whose breach you have to worry about. For a single developer or a stable two-person team, this is hard to beat, and Capy is not pretending otherwise.

The interesting question is what happens after the team grows. This comparison covers when Capy is the right dotenvx alternative and when it isn't.

When you need a dotenvx alternative

A second engineer joins. You generate them a key, share it over Signal or 1Password, and confirm they can decrypt. A third engineer joins; same dance. By the fifth or sixth engineer, the answer to "who has which key" lives in a shared password manager, which has now become the actual security boundary. The file encryption is still happening, but the property the team is relying on is a vault someone else controls.

The first time an engineer leaves the team, the question is whether their key still works. It does. They had it. The careful response is to rotate every secret they had access to and redistribute new keys to everyone else. In practice, most teams skip the rotation, because it is tedious and nobody wants to spend the afternoon on it. This is the pattern engineering leads describe in interviews almost universally: nobody rotates their secrets. The tool didn't make them irresponsible; the operational steps did.

What changes under Capy

Capy preserves the property dotenvx is built around (values are ciphertext before they leave the engineer's machine) and replaces the manual key-distribution and revocation steps with cryptographic primitives the service mediates.

Adding a teammate is capy invite alice@example.com. The new member's machine generates its own keypair and the service hands them a wrap they can use to decrypt. No private key has to leave one developer's machine for another's. Removing a teammate is capy kick. The service-side outer wrap on their key is destroyed, their local key.enc becomes inert, and the rest of the team's keys keep working unchanged. There is no rotation event and no afternoon spent re-encrypting and shipping new private keys to the survivors.

The .keep manifest is the other piece dotenvx doesn't have. It lives in your git repo as a list of hash references (committable, value-free), so a code reviewer sees in a PR diff that someone added or changed STRIPE_SECRET_KEY, without seeing what the value is. dotenvx commits the encrypted file itself, which is workable but mixes the value-list and the value-storage in a way that makes review patterns more awkward.

Where dotenvx remains the right answer

If your situation is "one developer, one machine, one key, no team operations to perform," dotenvx is built for it and there is no reason to introduce a service to the path. The crossover is the moment the team is more than two people, or whenever turnover becomes plausible. Past that point, what dotenvx asks you to do manually (distribute keys, track who has which one, rotate everything when someone leaves) is what Capy is asking you to stop having to do at all.