In June 2023, Infisical published a product update explaining why they were deprecating their original client-side end-to-end encryption mode in favor of a server-side architecture. The post is worth reading in full; the short version is that maintaining client-side encryption while shipping the dashboard, integrations, and team operations their customers asked for was a constant source of friction. Features that needed to read or transform plaintext kept colliding with a key model that lived only on the client. The Infisical team made a practical decision: meet the buyer where they are, accept a server-side trust boundary, and keep the dashboard surface area broad. That history is the most useful frame for the Capy/Infisical comparison in 2026, because Capy is the answer to the question Infisical chose not to answer: what would a secrets product look like if client-side encryption stayed the architecture?Documentation Index
Fetch the complete documentation index at: https://capy.sc/docs/llms.txt
Use this file to discover all available pages before exploring further.
At a glance
| Capy | Infisical | |
|---|---|---|
| Default encryption model | Client-side, always | Server-side; opt-in zero-knowledge mode |
| Client-side E2EE history | Built around it from day one | Deprecated in their June 2023 product update |
| What the service stores | Ciphertext only | Plaintext into the service; encrypted at rest via AES-256-GCM key hierarchy |
| Self-hosting trust model | Service still holds only ciphertext | Self-hosted Postgres + Node service holds plaintext on infrastructure you operate |
| Removing a teammate | capy kick — destroys the outer wrap; no rotation needed | RBAC revocation; rotation recommended |
| Secret diffs in PR review | keep.lock manifest with hash references | Dashboard-driven changes, outside the repo |
| Git-branch alignment | Branches pin to your git branches | Environments, not git branches |
| Dashboard for non-CLI users | No — CLI-first | Yes — broad dashboard surface |
| AI-agent blast radius | Only what capy run -- is currently injecting | Anything the authenticated machine can fetch |
Where Infisical landed
Today’s Infisical is a server-side product with a broad feature set. According to Infisical’s own security documentation, data is encrypted server-side via a multi-tier AES-256-GCM key hierarchy; the client transmits plaintext to the server, and the server performs the encryption. There is an opt-out “zero-knowledge” mode in which the server cannot read project values, but it is the exception, not the default. Self-hosted deployments still place plaintext on infrastructure you operate. That choice buys breadth. Infisical ships a dashboard, RBAC, audit logs, SAML on paid tiers, and integrations into a long list of CI and runtime targets. Self-hosting is supported via a Postgres-backed Node service that you run alongside whatever else your platform team is running.Where Capy landed
Capy made the opposite choice. The CLI encrypts each value on the engineer’s machine before any of it crosses the wire. The service stores ciphertext only. There is no mode in which it doesn’t, and no fallback path that exposes plaintext to vendor infrastructure. Server-side features that would require plaintext access don’t exist; the workflow is built around a small command-line surface, akeep.lock manifest committed to your git repo as PR-reviewable hash references, branches that pin to your git branches, and capy kick for cryptographic revocation that doesn’t require anyone else to rotate or re-encrypt.
The cost of choosing this architecture is the surface area Infisical’s 2023 update describes: a dashboard for non-CLI users does not exist, and broader SaaS integrations are intentionally narrower. The benefit is that the trust property is built into the product, not a setting that depends on a checkbox staying checked.
How Capy made client-side encryption usable
Infisical’s 2023 post named the friction honestly: dashboard features, integrations, and team operations kept colliding with a key model that only lived on the client. Each customer ask (view this in the UI, rotate from the dashboard, share read-only with on-call) pulled toward needing plaintext on the server. Capy didn’t try to fight that. The CLI is the product surface, and the team primitives are designed around what client-side encryption can actually do rather than around what a SaaS dashboard expects. A few of the DX moves that made the architecture usable for a team:capy invite. A simpler client-side scheme would have an existing member generate a private key and hand it to a new teammate. Capy’s service issues each member a freshly-wrapped key on join. The inner half stays on the new member’s machine, the outer half lives on the service, and no plaintext key material ever crosses a human boundary. The onboarding step that breaks naive client-side products is one command.capy kick. Removing someone in a file-encrypted-to-recipients scheme means re-encrypting every file to the remaining recipients and rotating values the leaver could have decrypted. Capy destroys the service-side outer wrap on the kicked member’s key; their local material becomes inert; the rest of the team rotates nothing. Cryptographic revocation without a rotation event is what lets client-side encryption actually work for teams that have turnover.- The
keep.lockmanifest. “Show me which secrets changed in this PR” is something a dashboard solves by reading plaintext. Capy solves it without plaintext: the manifest is a list of hash references in your git repo, so a PR diff shows thatSTRIPE_SECRET_KEYchanged without revealing the value. Reviewability without server-side access to plaintext. - Branches that pin to your git branches. Environment switching is another job a dashboard typically does. Capy pins each Capy branch to a git branch, so
git checkoutis alsocapy checkout. The operation happens on the machine that already has the keys. capy deploy. Pushing secrets to runtime targets is the other place server-side products want plaintext access: injecting into Vercel, Cloudflare, Fly, Lambda, and so on. Capy’s deploy decrypts on the engineer’s machine and writes the values into the target’s own secret store via the target’s API. The Capy service never holds the plaintext that gets injected.
Why their 2023 decision matters again in 2026
The trade-off Infisical described in 2023 was made for a threat model where the principal risks to a secrets product were vendor breach, insider misuse, or compromise of the storage tier. In each of those cases, keeping the vendor out of the plaintext path was the load-bearing property. Against that threat model, accepting a server-side trust boundary in exchange for product surface area was a defensible call. The threat model has shifted. AI coding agents (Claude Code, Cursor, Cline, Copilot) now run on developer machines, read environment variables, and increasingly execute shell commands and HTTP requests on the engineer’s behalf. The dev machine itself has become the dominant exfiltration surface, and the failure mode is no longer hypothetical. 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 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 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 +81% year-over-year, with commits carrying Claude Code’s co-author trailer leaking at roughly twice the baseline rate.
Under a server-side product, the developer’s machine continuously holds credentials that can fetch any project secret the developer is permitted to fetch. That is exactly the surface a prompt-injected agent, a subverted shell hook, or a compromised CI step is good at exploiting. They don’t need to break the vendor’s storage; they just need to ask the authenticated client. An Infisical-authenticated client on the dev machine pulls the full set on demand.
Under a client-side product, values that aren’t actively in scope of capy run -- stay as ciphertext on disk, 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.
Infisical’s 2023 trade-off was right for its threat model. The exfiltration-via-agent surface in 2026 is the case the trade-off didn’t account for, and it is the case Capy was built for. The comparisons overview walks through this in more detail.