1Password vs Bitwarden Secrets Manager for developers

1Password and Bitwarden Secrets Manager are built on the same promise, encryption and decryption on your devices, so the difference for developers is not who can read secrets but how each one gets them to code. 1Password gives developers Environments, a CLI, Connect servers inside your infrastructure and, in public preview, sign-in for GitHub Actions with the job's OIDC token. Bitwarden Secrets Manager is a separate product from Bitwarden's password manager, with machine accounts and access tokens, a cross-platform CLI, public source code and a free plan.

Most comparisons of these two look at password managers. This one looks only at the developer side: CI, tokens, environments, self-hosting and what happens when someone leaves.

Who each one fits

1Password fits companies that already use 1Password Business for logins and want developer secrets in the same place, under the same admins, single sign-on and provisioning. Its developer tools include Environments with locally mounted .env files that are never written to disk, service accounts, Connect servers that cache secrets in your infrastructure, and Kubernetes integrations.

Bitwarden Secrets Manager fits teams that want a lower-cost start and public code. The free plan covers up to 2 users, 3 projects and 3 machine accounts. Paid plans are priced per user and include machine accounts: up to 20 on Teams and up to 50 on Enterprise. Enterprise organizations can self-host it with Docker on Linux and Windows.

CI and machine access

This is the area where the two products differ most for developers. 1Password's standard GitHub Actions guide stores a service account token in a repository secret named OP_SERVICE_ACCOUNT_TOKEN, and notes that setting it in the configure step "makes the value available to all subsequent steps". Its newer Credential Broker lets GitHub Actions jobs use their OIDC token instead, without managing service account tokens. That feature is in public preview, custom OIDC workflows are in public beta, and both need 1Password Business. Service accounts have hourly and daily rate limits; Connect servers avoid them after the first fetch, because they cache data in your infrastructure.

Bitwarden's GitHub Actions guide saves a machine account access token as a GitHub encrypted secret, and no OIDC sign-in is documented. Access tokens are created with an expiry that defaults to "Never". When you revoke one, Bitwarden says new sign-ins stop at once, but "a machine that has already authenticated may continue to retrieve and decrypt secrets for up to one hour". The bws CLI runs on Windows, macOS and Linux, and bws run passes secrets to a command as environment variables.

Environments and removing people

Neither product has a separate key per environment out of the box. In 1Password, each vault has its own key, so keeping production in its own vault gives it its own key; Environments group project variables on top. In Bitwarden Secrets Manager, projects group secrets for access, "each secret can only be associated with a single project at a time", and one organization key decrypts all secrets.

On removal, 1Password's white paper is unusually frank: removing someone from a vault "isn't cryptographically enforced" and keys are not changed, though the server stops sending them data. Its suggested mitigation is to move items to a new vault, which has a new key. Bitwarden does not document what happens to keys when a member leaves. In both cases, values the person already saw should be reissued at the provider.

Where 1Password is stronger

• One tool for the whole company. Logins, passkeys and developer secrets in one place, with SSO through an OIDC identity provider and SCIM provisioning on Business.
• OIDC for GitHub Actions. Credential Broker removes the stored service account token, even if it is still in preview.
• Local .env files without disk writes. Environments can mount .env files locally without writing credentials to disk.
• Connect servers. A cache inside your infrastructure that serves unlimited re-requests after the first fetch.

Where Bitwarden Secrets Manager is stronger

• Cost to start. A free plan for 2 users, and paid plans that include machine accounts.
• Public source code and self-hosting. The code is public, and Enterprise organizations can run it on their own servers.
• Cross-platform CLI. One bws binary for Windows, macOS and Linux, also available from GitHub releases.
• Event log retention. Event logs are exportable and retained indefinitely on paid plans.

A third option: Crunu

Crunu, which wrote this page, shares the same basic promise as both products: values are encrypted in the browser and the crunu agent, and the server stores only ciphertext. Crunu's sign-in model, a password plus a Secret Key, follows the design in 1Password's white paper. Where it differs is in the developer details. Each environment has its own key, sealed separately to each person, machine and pipeline. CI uses service tokens bound by OIDC to a repository, branch and deployment environment on GitHub Actions, GitLab CI, Bitbucket Pipelines or any OIDC issuer. Removing someone rotates the keys of every environment they could read and lists the values to reissue. You can use the Crunu cloud or, on the Enterprise plan, host the server yourself. It is free during early access. The server still sees metadata such as names, email addresses and timestamps, as the limitations page explains.

Crunu is not a fit if you also need a password manager, browser autofill, mobile apps, SSO, SCIM, a Windows agent, SDKs or Kubernetes integration; it has none of these. The full comparisons are Crunu vs 1Password and Crunu vs Bitwarden Secrets Manager.