loke.dev
Two developer security toolchains branching toward an integrated hosted workflow and a modular self-hosted workflow

1Password vs Bitwarden for Developers: Choose by Workflow

Compare 1Password and Bitwarden for developer workflows: SSH agents, CLIs, local and CI secrets, self-hosting, EU regions, pricing, and recovery.

Published 11 min read

The useful 1Password versus Bitwarden decision is no longer “developer tools or no developer tools.” Both products now have a password-vault CLI, an SSH agent, passkey support, EU hosting choices, and a separate path for machine secrets. The difference is how those parts fit together, what they cost, and how much infrastructure you want to own.

The short answer

Choose Bitwarden when a permanent free tier, lower personal price, published source, or supported self-hosting is a hard requirement. Its developer story is real, but Password Manager and Secrets Manager are separate products with separate CLIs and access models.

Choose 1Password when you want one polished account and desktop workflow spanning website credentials, SSH and Git signing, the op CLI, local secret references, service accounts, and newer agent integrations. You pay more and use its hosted account model.

For a team, do not buy from a feature checklist. Pilot the exact browser, operating system, Git client, SSH hosts, local scripts, CI runner, recovery process, and EU account region you will actually use.

Decide across four boundaries

A developer password manager touches four different security boundaries. A product can be strong at one and awkward at another.

  • Daily vault: browser autofill, mobile use, passkeys, sharing, recovery, and family or team adoption.
  • Workstation identity: SSH authentication, Git commit signing, client compatibility, and approval prompts.
  • Local application secrets: CLI access, environment injection, templates, and what an authorized process can read.
  • Unattended workloads: machine identity, CI integrations, bootstrap tokens, audit records, and revocation.

Score both products at each boundary. Do not let an attractive SSH demo decide whether your non-technical family can recover an account, or let a low personal price decide how production secrets enter CI.

The pricing gap is real

On 24 July 2026, Bitwarden's official pricing page listed a permanent free password-manager tier, Premium at $19.80 USD per year, Families at $47.88 per year, Teams at $4 per user per month, and Enterprise at $6 per user per month, all before tax where applicable.

The 1Password pricing page offered a 14-day trial rather than a permanent free plan. It displayed promotional and standard prices, plus Teams Starter Pack at $24.95 per month for 10 members and Business at $8.99 per user per month on annual billing.

Do not compare a first-year promotion with a renewal price. In Sweden, switch both sites to EUR where available, add VAT treatment, and keep the checkout or written quote used for the decision. Prices and packaging can change after this article date.

Bitwarden's lower entry price is not a minor detail for a solo developer or family. 1Password needs to earn the gap through workflow fit, support, recovery, or administration that you actually value.

Both now have an SSH agent

Older comparisons often give 1Password an automatic win because Bitwarden lacked an SSH agent. That is stale. Both current desktop apps can keep private keys in the vault and answer signing requests over a local agent interface.

Where 1Password is more configurable

The 1Password SSH agent documentation supports Ed25519 and RSA keys on macOS, Windows, and Linux. An optional agent.toml file can restrict which keys are offered and their order. SSH config or bookmarks can map a public key to a host.

Its authorization model can approve a key per application, per terminal session, or more broadly for the agent session. The prompt can identify the requesting process and key.

That model is useful when you keep several client, work, and personal keys or want a clear approval boundary between a terminal, IDE, and Git GUI. It still depends on the desktop app, a supported client path, lock behavior, and a recovery plan.

Where Bitwarden works and where it is narrower

The current Bitwarden SSH documentation supports Ed25519 and RSA keys, signing requests, agent forwarding, and organization-owned SSH key items.

Bitwarden also documents important limitations: no ssh-add key management, no direct per-request key selection, and an agent that may try multiple vault keys until one succeeds. Its workaround uses IdentityFile in SSH configuration. Imported PuTTY keys are not supported.

A public Bitwarden client issue from 2025 records Windows Git-signing failures tied to which OpenSSH installation Git used. That does not prove the current release fails, but it is a good reason to test the exact Git for Windows and desktop-app path before migration.

If SSH and Git signing are the main reason you are leaning toward 1Password, use the 1Password SSH migration guide for a fingerprint, client, rollback, and recovery test.

The CLI comparison is really three CLIs

1Password uses op for vault items, secret references, local process injection, Connect, service accounts, and other developer tasks. Bitwarden uses bw for the password vault and bws for Secrets Manager. Treating bw and bws as one interchangeable interface hides an important product boundary.

1Password op

With 1Password secret references a checked-in value such as op://development/database/password can be resolved by op read, op run, or op inject. op run supplies selected values to a child process and masks matching output by default.

The desktop integration can authorize interactive op use. A service account can give a nonhuman process access to selected vaults or Environments. The same URI model appears across local scripts and several deployment integrations.

Bitwarden bw and bws

The Bitwarden Password Manager CLI exposes most vault operations through bw. It uses authenticated and decrypted session state, and can connect to the US cloud, EU cloud, or a self-hosted server.

The separate Bitwarden Secrets Manager CLI uses bws, machine-account access tokens, projects, and commands such as bws run for process injection. It supports Windows, macOS, Linux, Docker, EU cloud, and self-hosted server configuration.

The split is not inherently bad. It can make human credentials and workload secrets easier to separate. It does mean a team must design two access models instead of assuming every password-vault user should read deployment secrets.

Both CI paths still need a bootstrap credential

A secret manager does not make GitHub Actions credential-free. 1Password commonly starts with OP_SERVICE_ACCOUNT_TOKEN. Bitwarden's integration starts with a machine-account access token such as BW_ACCESS_TOKEN. GitHub must protect that initial credential before either manager can resolve application secrets.

Bitwarden documents a GitHub Actions integration for retrieving Secrets Manager values. 1Password documents load-secrets-action with service accounts or Connect.

The same safe design applies to both: untrusted pull requests get no secret-manager token; deployment runs trusted code; the machine identity sees only one environment; and the token reaches only the resolving step.

The 1Password GitHub Actions boundary guide explains the fork, environment, output, log, and rotation controls. Substitute Bitwarden's machine account and action only after verifying their current syntax and release.

Bitwarden has the clearer self-hosting branch

If supported self-hosting is mandatory, Bitwarden is the practical choice between these two. Bitwarden documents cloud, Docker, offline, and Kubernetes deployment paths. Its official clients can connect to a self-hosted server.

Bitwarden's own self-host setup checklist assigns responsibility for servers, databases, TLS, monitoring, upgrades, backups, restore tests, disaster recovery, identity integration, and security review. Self-hosting moves those duties to you; it does not remove them.

1Password accounts use a hosted region. The official region list offers United States, Canada, and European Union accounts. If you need an official on-premises password-vault server, that hosted model does not meet the requirement.

Do not choose self-hosting only because it feels more private. Choose it when your organization has a named operations owner, patch schedule, tested restore, monitoring, incident path, and a reason cloud regions cannot satisfy.

Sweden and the EU do not force one winner

1Password says its EU region uses EUR and hosts secure account data in the European Union. Changing region later requires moving data to a new account.

Bitwarden documents US and EU cloud geographies and lets self-hosted customers choose their own infrastructure. Its security FAQ says its cloud service operates in both US and EU Azure regions.

For a Swedish person or company, choose the intended region before importing or inviting anyone. Then review the data processing terms, subprocessors, support access, logs, retention, employer policy, and who controls recovery. EU hosting alone is not a complete GDPR decision.

Bitwarden Secrets Manager changes the cost comparison

Do not compare only the password-manager subscription if the goal includes CI or agent secrets. Bitwarden Secrets Manager has its own plans even though a small free tier exists.

On 24 July 2026, the Bitwarden Secrets Manager pricing page listed Free with up to two users, three machine accounts, and three projects; Teams at $6 per user per month with 20 machine accounts; and Enterprise at $12 per user per month with 50 machine accounts, under annual billing.

1Password includes developer tools in its password-manager plans, but automation limits and administrative controls still differ by plan. Compare the complete system: password seats, secrets seats, machine identities, audit requirements, rollout work, and renewal pricing.

For a 1Password team, the Teams versus Business calculator covers current quotes, control gates, member counts, and rollout time.

Do not turn openness into a one-word security verdict

Bitwarden publishes source for review and also ships some builds with commercial modules. 1Password publishes security design material and audit information but does not use Bitwarden's open-source product model. Source availability can be a legitimate procurement requirement, especially for self-hosting.

It is not enough to declare one product secure and the other insecure. Review encryption design, account recovery, build provenance, audit reports, update process, device security, organization policies, and how your users behave. Most teams will create more risk through poor sharing and recovery than through a theoretical feature-count difference.

Run a seven-day developer pilot

A short pilot can settle more than another comparison page. Use fake or low-impact credentials and record friction rather than relying on memory.

  • Day 1: import a disposable set of logins, test browser and mobile autofill, then export it again.
  • Day 2: create one SSH key, authenticate to a test host, deny a request, lock the app, and restart the machine.
  • Day 3: sign a Git commit from the terminal and the actual IDE or Git GUI you use.
  • Day 4: inject a fake API token into a small local process without committing plaintext.
  • Day 5: resolve one non-production CI secret with a narrowly scoped machine identity.
  • Day 6: test recovery, a lost device, another family or team member, and account removal.
  • Day 7: price the real EUR plan, document the region and renewal terms, and list every unresolved workflow.

Do not migrate production SSH keys or deployment credentials until the new path has passed denial, lock, restart, and revocation tests.

Choose Bitwarden when

  • the permanent free tier or lower personal price is decisive
  • published source is a policy or procurement requirement
  • supported self-hosting is required and you can operate it
  • the bw and bws product split matches how you separate people and workloads
  • the SSH agent limitations do not affect your real key inventory and clients

Choose 1Password when

  • you value one integrated developer workflow across vault, SSH, Git, CLI, and service accounts
  • per-application or per-terminal SSH approval and key ordering solve a real workstation problem
  • the desktop app and hosted regional account fit company policy
  • your household or team accepts the workflow enough to use it consistently
  • the measured time and administration savings justify the higher price

My recommendation

For a cost-sensitive solo developer, start with Bitwarden and test its current SSH agent and bw CLI. The free tier makes the decision reversible. Add Secrets Manager only when a real project needs machine access.

For a developer who already likes 1Password, uses several SSH identities, wants op secret references, or plans to connect local development and CI through one vendor, staying with 1Password is reasonable. That is the path I personally prefer, but the preference is not a substitute for your pilot.

For a Swedish team, run both in the EU region, include recovery and one non-technical user, and compare the complete annual cost. Self-host Bitwarden only when owning the service is an explicit requirement with an operations budget.

If 1Password fits your result, check its current plans. This direct tracked link currently earns no commission.

If Bitwarden fits better, check Bitwarden's current plans directly. This is also a noncommissioned link.

Primary sources checked

  • 1Password pricing, regions, SSH agent, SSH authorization, CLI secret references, and service accounts
  • Bitwarden Password Manager pricing, Password Manager CLI, SSH agent, server geographies, and self-host operations
  • Bitwarden Secrets Manager overview, CLI, pricing, machine accounts, and GitHub Actions integration
  • Public Bitwarden client issue reports used only to identify pilot cases, not as proof of current product behavior