Secrets-management tools split along one architectural choice: does encryption happen on the client, before any value crosses the wire, or on the server, after the vendor has already received the plaintext? Most of the rows you’d want to draw in a feature spreadsheet trace back to that single decision. Capy encrypts on the client. Each value in yourDocumentation 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 becomes ciphertext on the engineer’s machine, via a two-party key hierarchy where the service holds half of the wrap and the client holds the other half. Neither side can decrypt alone. Doppler, Infisical Cloud, AWS Secrets Manager, and GCP Secret Manager all encrypt server-side: their staff, their infrastructure, and any party with legal compulsion to that infrastructure can in principle reach plaintext if compromised. 1Password’s user vaults use a Master Password + Secret Key model that is also client-derived; their Service Accounts (the typical CI/CD path) use a token model that is closer to the server-side products.
Local-native solutions like SOPS and dotenvx encrypt client-side too, but neither ships a team mechanism: keys are distributed and managed by you.
At a glance
| Capy | 1Password | Doppler | Infisical | dotenvx | AWS SM | SOPS | |
|---|---|---|---|---|---|---|---|
| Client-side encryption by default | ✓ | Partial¹ | No | No (since 2023) | ✓ | No | ✓ |
| Vendor cannot read plaintext | ✓ | Partial¹ | No | No | n/a² | No | n/a² |
| Built-in team service (no manual key swaps) | ✓ | ✓ | ✓ | ✓ | No | ✓ | No |
| Cryptographic revocation, no rotation event | ✓ | No | No | No | No | No | No |
| Branches pin to your git branches | ✓ | No | No | No | No | No | No |
| PR-reviewable secret diffs without exposing values | ✓ | No | No | No | No | No | No |
| AI-agent blast radius limited to active session | ✓ | No | No | No | No | No | No |
| Multi-runtime deploy (Vercel, Cloudflare, Fly, Lambda, …) | ✓ | ✓ | ✓ | ✓ | No | AWS only | Varies |
| Headless (no dashboard required) | ✓ | No | No | No | ✓ | No | ✓ |
A different design philosophy
Capy treats secrets the way developers already treat code. The CLI mirrors git:capy checkout, capy push, capy deploy, branches that pin to your git branches, and a keep.lock manifest that lives in your repo and shows up in PR diffs. The homepage puts it directly: “Like GitHub, but for secrets.”
Most tools in this category extend either the password-manager metaphor (vault items, RBAC dashboards, web UIs you log in to) or the cloud-runtime metaphor (IAM-scoped fetches at request time). Capy starts from a different question: what would secrets management look like if it followed the same disciplines you already apply to source code? How do we enable that while maintaining a secure identity-scoped storage and retrieval mechanism?
The answer produces specific design choices. Branches that align with git branches. Diffs that show up in PR review. A kick command that reads as cleanly as git revert. None of these is decorative; each is the answer to “how would a developer expect this to work?” applied to a domain that has historically been answered with dashboards and access policies. The team writes about wanting to “simplify to the point of invisibility”; the goal is for secrets to feel like the rest of the toolchain, not a separate one.
The corollary is intentional narrowness. There is no vault for human passwords (use 1Password). There is no rotation hook for AWS-managed RDS credentials (use ASM). There is no dashboard for non-engineering stakeholders to browse secrets in. Capy does the engineering team’s .env workflow, with the cryptographic and operational properties that workflow would have if it had been designed natively for it.
How each tool fits
1Password CLI (op / op run) is a strong fit for teams already standardized on 1Password company-wide who want a single vault for humans, machines, and AI agents. 1Password’s recent Unified Access launch pushes that direction further. Reach for it when one centralized vault across your whole organization is the goal.
Doppler is an established managed product with server-side encryption and a long list of built-in integrations. Reach for it when the trusted-vendor model is acceptable and a hosted dashboard for non-engineers is part of the buying criteria.
Infisical is the leading open-source platform; reach for it when self-hosting (and the platform team to run a stateful service in production) is the right fit for your org. Worth knowing: Infisical’s client-side end-to-end encryption mode was deprecated in their June 2023 product update. Encrypt-at-source has not been the default since.
dotenvx is the file-only client-side encryption tool. Reach for it when you’re solo or a tiny stable team and you accept that adding or removing teammates means manually distributing or rotating private keys.
AWS Secrets Manager is the AWS-runtime store: IAM-scoped fetches from inside Lambda / ECS / EC2 and automatic rotation hooks for AWS-managed credentials. ASM is the right place for an RDS password. It is not the right place for a developer’s daily loop.
SOPS is the file-encryption primitive most platform engineering teams already know. Reach for it when your team owns KMS or Vault and is already operating the recipient-key plumbing around it.
Capy is what you reach for when client-side encryption needs to be the default rather than an opt-in mode, when removing a teammate should be a single command rather than a rotate-everything event, and when you want secrets to track git branches the way the rest of your code does. The architectural commitments are documented in zero-trust and cryptography; the team mechanics are in kicking and inviting.
Why this matters more with AI agents in the dev loop
For most of the last decade, the choice between client-side and server-side encryption was a defensible-but-academic distinction. AI coding agents have made it more practical. Claude Code, Cursor, Cline, and Copilot run on developer machines, read environment variables, and increasingly execute shell commands and HTTP requests on the engineer’s behalf. That changes an old threat: a successful prompt injection now means the attacker has whatever the agent process can read, fetch, or run. The credentialed-agent failure mode is not theoretical. The Comment-and-Control attack (CVSS 9.4, disclosed by Legit Security) exfiltrated a developer’sANTHROPIC_API_KEY via a prompt-injected pull-request title that an agent picked up while reviewing PRs. Check Point’s research on Claude Code Hooks (CVE-2025-59536, CVE-2026-21852) showed remote code execution and API-token exfiltration through the same surface. InjecAgent’s ACL 2024 benchmark of indirect prompt injections found roughly a quarter of agent runs against GPT-4 followed embedded malicious instructions, climbing to nearly half under reinforcement. GitGuardian’s State of Secrets Sprawl 2026 reports AI-service secrets leaking at +81% year-over-year, with commits carrying Claude Code’s co-author trailer leaking at roughly twice the baseline rate.
Client-side encryption changes this in a specific way. Under a server-side product, the developer’s machine continuously holds credentials that can fetch any project secret on demand, meaning a compromised agent process, a compromised CI step, or a subverted shell hook can pull the full set, encrypted-at-rest by the vendor or not. Under Capy, values that aren’t actively being injected by capy run -- live on disk as ciphertext bound to a two-party key whose outer wrap the agent’s process cannot strip alone. Stolen .env bytes are bytes. A prompt-injected agent gets only what is currently decrypted into the process it has authority over, not the entire project’s catalog.
This is not a claim that any tool makes AI agents safe to use. An agent that legitimately needs a secret will hold it in memory while it works, and that surface is the same under every product in this category. It is a claim that the architectural choice (where encryption happens) controls the blast radius when something else fails. With server-side encryption, the radius is “everything the developer’s machine has authority to fetch.” With client-side encryption, it is “the values currently in scope of an active capy run --.” That gap is the security property worth paying attention to in 2026.