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?
At a glance
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-in “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, a keep.lock manifest committed to your git repo as PR-reviewable hash references, secret branches you switch with capy checkout, 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 mints a one-time token, wraps the master key with it, and has the service add a second wrap on top. The invitee’s redeem code carries only that double-wrapped material: opening it takes an authenticated, active membership to strip the outer wrap and an inner key bound to their email address, so an intercepted code gets an attacker nothing. 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 deletes their membership on the service, which then refuses to strip the outer wrap for them; their local key material becomes inert, and 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.lock 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 travel with your repo. Environment switching is another job a dashboard typically does. Capy branches are their own namespace — you switch with
capy checkout <branch> — and the keep.lock you commit rides along with your git branch. The post-checkout and post-merge hooks Capy installs run capy status, so a git checkout tells you straight away whether your secrets match the code you just checked out. The switch 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. On the platforms that have a connector — Vercel, Cloudflare Workers, AWS SSM Parameter Store, and Cloudflare Pages — Capy decrypts the current branch on the engineer’s machine. For Vercel, AWS, and Workers it pushes the values into that platform’s own store through the vendor’s CLI or API; for Cloudflare Pages, it injects them into the build and ships the built site with wrangler pages deploy. Everywhere else it mints the SECRETS_BLOB and PROJECT_KEY pair you set on the platform, and capy run decrypts them in the running process. Either way, 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. Last modified on August 11, 2026
