Capy vs 1Password CLI

1Password is widely used among developers and has spent the last several years expanding from password management into infrastructure secrets: the SecretHub acquisition in 2021, Secrets Automation, self-hosted Connect Servers, and in March 2026 the Unified Access platform, which adds discovery, vaulting, and audit for credentials used by AI agents alongside integrations with Anthropic, Cursor, GitHub, Vercel, and Perplexity. For organizations already standardized on 1Password, the case for using op and op run as the secrets layer too is strong: one vault, one auth flow, one admin surface.

Capy and 1Password are aiming at different problems. 1Password is building a unified credential layer across humans, machines, and AI agents: a single product that holds your engineers' passwords, your service accounts' API tokens, and the credentials your AI tools use to act. Capy is built for one specific surface: the developer-and-team .env workflow, with git-aligned branches, a committable manifest, and ciphertext-only storage on the service. Both can be the right answer; the choice depends on which problem you are actually trying to solve. This comparison covers when Capy is the right 1Password CLI alternative and when it isn't.

How the trust models differ

1Password's user vault uses a strong design. The encryption combines a user-chosen Master Password with a Secret Key generated on-device, and 1Password's documentation states that they cannot decrypt user vault items without both. The Secret Key never leaves the user's devices. For interactive op use from an engineer's laptop, this is closer to client-side encryption than most managed products.

The CI/CD path uses a different model. 1Password Service Accounts are token-authenticated: the account presents a token, 1Password validates it, and 1Password's infrastructure provides access to the vault items that account is permitted to read. Self-hosted Connect Servers can cache decrypted material in your infrastructure to avoid rate limits. In both cases, the trust boundary for machine workloads includes 1Password's service in a way that the user-vault model does not.

Capy's architecture is the same in every direction. Every value (whether a developer is reading it interactively, a CI runner is fetching it for a deploy, or a teammate is syncing it onto a new laptop) is encrypted on the producing client and decrypted on the consuming client. The Capy service holds ciphertext and the outer wrap of each member's key. Decryption requires the inner wrap, which lives only on the member's device. There is no separate service-account path with a different trust model.

How the workflow differs

1Password treats secrets as items in a vault. You add a value through the 1Password app or the CLI; you reference it from your code via a secret reference like op://vault/item/field; op run -- ./your-app resolves those references and injects them. The mental model is the password manager extended to env vars.

Capy treats secrets as values in a .env file. You edit the file directly; Capy encrypts each value on save and syncs the ciphertext through the service. You run your app with capy run -- ./your-app and the values land in process.env. The encrypted file itself is committable; the .keep manifest in your git repo lists hash references rather than values, so a PR diff shows which secrets changed without exposing them; branches in Capy pin to your git branches.

Neither model is universally better. The vault model centralizes everything in 1Password's product surface; the file model keeps the engineering workflow the way developers already work.

On the AI-agent question

1Password's Unified Access positions AI agent security as discover, vault, audit: find credentials sitting in plaintext .env files, vault them, audit which agent used which credential when. The strategy is governance-oriented and fits a security or platform team that wants visibility into how AI agents use credentials across the organization. The partnership posture in March 2026 (Anthropic browser extension and Claude Code, Cursor agent hooks, GitHub Actions, OpenAI IDE integrations) is a real strength.

Capy's approach is structural rather than governance-based. The architecture limits what an AI agent can decrypt at any given moment to the values currently in scope of an active capy run -- invocation; the rest of the project's .env stays as ciphertext on disk that the agent's process cannot strip alone. The comparisons overview explains the reasoning.

The two approaches are not exclusive. A team can use 1Password Unified Access to discover and audit credential usage across the organization, and use Capy for the engineering team's .env workflow specifically, much as most teams already use 1Password for human passwords regardless of what they use for .env.

When Capy is the better 1Password CLI alternative

1Password fits when one vault for humans, machines, and AI agents is the goal: when the buying decision sits with a security or IT team that wants centralized governance, and when 1Password is already standard in your organization. The integrations, audit, and partnership work they have shipped in 2026 are genuine strengths.

Capy fits when the engineering team's .env workflow is the surface you are trying to improve: when you want secrets to live as values in a .env file and a .keep manifest in git rather than as items in a vault, when ciphertext-only storage on the service is a built-in property rather than a configuration choice, and when removing a teammate should be a single command that doesn't require rotating values or revoking tokens. Teams that use both typically run Capy for the engineering workflow and 1Password for human passwords, with no overlap between the two.