Capy vs Infisical

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? This comparison covers when Capy is the right Infisical alternative and when it isn't.

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 as an Infisical alternative

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, a .keep 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 manifest. "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 that STRIPE_SECRET_KEY changed 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 checkout is also capy 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.

The pattern across all of them is the same: take an operation that historically required server-side plaintext, redesign it as a CLI affordance plus a cryptographic primitive, ship it as the default. Infisical's 2023 friction was real for a product trying to add those features on top of a client-side-encrypted core. Capy is what the same architecture looks like when the DX is built for it instead of against it, and it sidesteps the trade-off the 2023 post described.

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's ANTHROPIC_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.

How to choose between them

If your team specifically wants dashboard-driven operations, has the platform headcount to operate a stateful service (or is happy on Infisical Cloud), and the trusted-vendor or self-host trust model is acceptable, Infisical is a good fit. Its OSS posture, contributor base, and feature breadth are real strengths, and the team behind it has been clear about the engineering decisions they've made.

If your team's structural concern is that the vendor cannot read plaintext, that secret diffs should appear in PR review without exposing values, that removing a teammate should be cryptographic rather than permission-based, and that an agent on a developer's machine should not be able to enumerate the project's full secret catalog, the choice Infisical made not to make is the choice Capy is built around.