Open-source alternatives to 1Password: 4 password manager tools compared
A hosted password manager gives you sync and a phone client and takes away the ability to keep secrets inside your own network, so every option here trades one for the other. dani-garcia/vaultwarden is the one most readers should look at first, because the official Bitwarden clients work against it.
What 1Password does, and why people look elsewhere
1Password is a hosted password manager: encrypted vaults synced across devices, browser autofill, shared vaults for teams and passkey support.
- subscription-only; the vault sync depends on the vendor's service
- the encrypted vault is stored on the vendor's servers
- a team that must keep secrets inside its own network cannot use it
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install |
|---|---|---|---|---|---|
| dani-garcia/vaultwarden | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last dayLast push October 25, 2026 | Rust | 69,658 | See analysis |
| bitwarden/server | Custom licenceCustom licence: read the LICENSE file | Commits in the last dayLast push October 25, 2026 | C# | 20,477 | Command documented |
| keepassxreboot/keepassxc | Custom licenceCustom licence: read the LICENSE file | Commits in the last six monthsLast push October 23, 2026 | C++ | 29,480 | See analysis |
| passbolt/passbolt_api | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last six monthsLast push October 20, 2026 | PHP | 6,187 | Command documented |
Each alternative in detail
dani-garcia/vaultwardenUnofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs.
- Best for
- You want the Bitwarden client experience on infrastructure you control, and the README states it is compatible with the official Bitwarden clients. The feature list covers personal vaults, Send, attachments, organisations with collections, member roles, groups, event logs, policies and a directory connector, plus YubiKey, FIDO2, Duo and authenticator options for two-factor.
- What you give up
- It is explicitly an unofficial implementation, so support comes from the project's own Matrix room, GitHub Discussions and Discourse forum, and the README tells users not to use the official Bitwarden support channels. The bundled web vault also needs HTTPS and a secure context for the Web Crypto API, which makes a reverse proxy with a real certificate part of the install rather than an option. And AGPL-3.0 is the licence to settle before a company hosts a modified version.
bitwarden/serverBitwarden infrastructure/backend (API, database, Docker, etc).
- Best for
- You want to run the upstream Bitwarden backend rather than an alternative implementation, and you are willing to operate Docker Compose and SQL Server. The README describes it as C# on .NET Core with ASP.NET Core and a T-SQL and SQL Server database, buildable and runnable on Windows, macOS and Linux.
- What you give up
- It is much heavier than the alternative implementations here, with SQL Server plus a set of production services that the README lists per cluster, including API, Identity, Events, EventsProcessor, Notifications, SSO and SCIM. Our analysis of bitwarden/server says not to adopt it if you only want a password manager for a handful of people, because the hosted service removes that entire operational surface. The licensing needs reading too: three licence files at the repository root plus LICENSE_FAQ.md, and GitHub cannot classify the repository from its metadata.
- First install step
- Full setup guide
curl -s -L -o bitwarden.sh \ "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" \ && chmod +x bitwarden.sh ./bitwarden.sh install ./bitwarden.sh start
keepassxreboot/keepassxcKeePassXC is a cross-platform community-driven port of the Windows application “KeePass Password Safe”.
- Best for
- You want your passwords in a file on your own disk with no account and no sync service, and you want a command line, browser integration, SSH agent integration and Auto-Type. The README also lists passkey support through the browser integration, TOTP storage and generation, and Twofish and ChaCha20 as additional encryption choices.
- What you give up
- There is no hosted sync of its own and no mobile client, so syncing and phone access become your problem, which our analysis of KeePassXC names as the reason to skip it. The database is a KDBX file you copy around, so a phone means a second copy to keep consistent. The release cadence is also the slowest of the four, with 2.7.12 dated 2026-03-10 while the last push was 2026-09-23, and the licence is dual GPL-2 or GPL-3 with separate terms in COPYING for third-party files.
- Moving from 1Password
- The README lists import from 1Password among the supported formats, alongside CSV, Bitwarden, Proton Pass and KeePass1.
passbolt/passbolt_apiPassbolt Community Edition (CE) API. The JSON API for the open source password manager for teams!
- Best for
- You need a team password manager where the server never holds plaintext secrets. The README describes user-owned secret keys and end-to-end encryption, audits several times a year with the findings made public, no collection of personal data or telemetry, and deployment in an air-gapped environment.
- What you give up
- It is a browser extension plus a CakePHP JSON API rather than a REST service for scripts: the API returns OpenPGP-armoured material that the client has to decrypt, and no server-side decryption path is documented, so anything automating secret retrieval has to do that cryptography itself. Running the extension is part of the workflow for every user, and the README links to the install pages on passbolt.com instead of embedding the steps.
- First install step
- Full setup guide
npm run copy:dependencies npm run copy:styleguide npm run copy:locales npm run lint
A file on your disk, two Bitwarden-shaped servers and a browser extension
1Password is a hosted password manager: encrypted vaults synced across devices, browser autofill, shared vaults for teams and passkey support. The reasons people look elsewhere are specific. It is subscription only. The vault sync depends on the vendor's service. The encrypted vault sits on the vendor's servers. And a team that must keep secrets inside its own network cannot use it at all.
Those last two reasons point in opposite directions, and that is why the four projects here are not interchangeable.
keepassxreboot/keepassxc answers by removing the server. It stores everything in a KDBX file on your disk, and the README is explicit that it has no hosted sync of its own. There is no account, nothing to operate as a service, and the file can sit wherever you like. What you get in exchange is a command line, browser integration across the major Chromium and Firefox browsers, SSH agent integration, Auto-Type, TOTP, and passkeys through the browser integration.
The other three all run a server.
dani-garcia/vaultwarden is an alternative implementation of the Bitwarden Client API written in Rust, and the README says the official Bitwarden clients work with it. That compatibility is the whole argument: your users install a normal client and the data lands on your hardware. The feature list covers personal vaults, Send, attachments, organisations, collections, member roles, groups, event logs, policies, a directory connector, emergency access and an admin backend, with a modified web vault bundled in the containers.
bitwarden/server is the upstream original rather than an alternative. The README describes the C# and .NET Core backend that every Bitwarden client talks to, with a T-SQL and SQL Server database, packaged for self-hosting through Docker Compose.
passbolt/passbolt_api is a different shape again. It is a CakePHP JSON API built around user-owned secret keys and end-to-end encryption, and the workflow assumes a browser extension on every user's machine plus a server that never sees plaintext.
What is absent, and worth saying: a self-hosted secrets manager that also does a polished mobile client, and the hardware key and SSH certificate tooling that separate products in this category. Neither is what this page is for.
Why LastPass and Dashlane are not on this list
LastPass and Dashlane are the two names that come up next to 1Password in most of these searches, and neither is here, because both are hosted services. That is the same property that makes 1Password the product being replaced.
Neither should be dismissed. A hosted password manager does two things self-hosted software on this page does not: it keeps the vault in sync across devices without you operating anything, and it maintains clients for phones that the projects here do not all provide. For a person who wants those two things and has no network boundary to defend, a hosted service remains a reasonable answer, and nothing here argues otherwise.
What changes when the reason for looking is the one in the brief, which is that secrets have to stay inside a network you control. At that point the hosted option is not merely different, it is disqualified, and the choice becomes which server to run.
Also missing from this page are the enterprise password managers built for rotation and approval workflows, and the dedicated secret managers aimed at infrastructure rather than people, such as the tools that inject credentials into running services. Those solve adjacent problems. The four projects here are about holding human credentials, which is what a password manager does.
One more absence worth naming is a hosted team service built on the open source implementations below. Those exist, and choosing one keeps your data off your own hardware, which is the whole reason for reading this page.
Choosing by scenario: one person, a small team, a company that must keep secrets inside its network
The four differ most in who has to touch the thing when it breaks.
One person, on one or two computers, is the case KeePassXC was built for. A local encrypted file needs no server, no domain and no certificate, and the import path means an existing export can be loaded directly. Our analysis of KeePassXC points out the condition: you accept that syncing and mobile access are your problem, and that you can operate a second copy of the database on a phone if you want one there.
A small team that wants shared vaults and the familiar client apps is the case for dani-garcia/vaultwarden. The official clients work against it, so adoption is an install rather than a retraining. Two things have to be right before anyone signs in: the domain has to terminate real HTTPS, because the bundled web vault needs a secure context, and the volume mounted at /data has to be on storage you actually back up.
A company that must keep secrets inside its own network has a longer list. passbolt/passbolt_api is built for teams rather than individuals, with policies, sharing and an audit trail, and the README notes it can be deployed in an air-gapped environment, which is the hardest version of that requirement. bitwarden/server is the same requirement at maximum weight, because you are running the upstream backend with SQL Server and a set of services, which suits an organisation with infrastructure staff rather than a team of five.
A developer who needs to fetch a secret from code should notice that none of these is that tool. The API surfaces are designed for a client that holds the key, not for a script that expects a password back, which is a limitation worth checking before anyone builds on top of one of them.
What each one costs to operate and, more importantly, to back up
A password server holds the thing you cannot afford to lose, so the backup question comes before the uptime question.
dani-garcia/vaultwarden is the smallest of the servers. The command on this page pulls a container, sets DOMAIN to the URL, mounts a host volume at /data, restarts unless stopped, and publishes the port to loopback only. The whole state is that volume, which makes the backup story short and the consequences of getting the path wrong severe. The README is explicit that the web vault needs HTTPS, and it recommends a reverse proxy rather than exposing the service directly.
bitwarden/server is the largest. The command downloads a shell script that installs and starts the deployment, and the README lists Docker and Docker Compose as the only requirements. Underneath there is a SQL Server database, and the README's production cluster tables name the services, among them Admin, API, Billing, Events, EventsProcessor, Identity, Notifications, SCIM and SSO. Nine services, two database replicas in a normal production shape, and a data directory each. That is a platform, and it is the right answer only if somebody is going to own it.
passbolt/passbolt_api has no install command in our analysis, because the README links to the install pages on passbolt.com rather than embedding steps, and it offers Docker, Kubernetes and native packages across a long list of distributions. What it runs is a PHP application and a database, so the backup and upgrade work is yours, and the browser extension on every workstation is a second thing to keep current.
keepassxreboot/keepassxc has no install command in our analysis and needs no server, but it has the opposite problem: the database is a file, and a file that exists in one place is a single point of failure. The README documents export to CSV, XML and HTML, which is the safety net, and syncing it across devices is a decision you have to make rather than one the project makes for you.
Licences: two AGPL-3.0, a dual GPL and a repository with three licence files
Two of these are AGPL-3.0, one is dual GPL, and one GitHub cannot classify. The differences matter more here than in most categories, because the thing you are running holds secrets.
dani-garcia/vaultwarden and passbolt/passbolt_api are both AGPL-3.0. For a company running either on its own network, the practical question is whether you modify it. If you do not, internal use is unremarkable. If you do, hosting the modified version means the source is owed to the people who reach it over that network, which is a condition worth putting in writing before the first change rather than after.
keepassxreboot/keepassxc is GPL-2 or GPL-3, and the README points to COPYING for the additional licensing of third-party files. The distinction matters if you redistribute the application, which most people do not, and it is the friendliest arrangement of the four for internal use.
bitwarden/server is the one to slow down on. The repository carries three licence files at its root plus LICENSE_FAQ.md, and our analysis of bitwarden/server tells you to read the FAQ together with the three files before deciding how the code can be used. Multiple licence files at the root of a commercial-adjacent product usually means different components under different terms, and the question of which service is under which licence is the one to answer first.
One point that applies to all four. Self-hosting a password manager is a statement about where the ciphertext and the keys live, and the licence governs the software that does it. Neither of those is settled by a permissive licence, and reading the terms carefully does not substitute for a backup you have tested restoring.
Bottom line
Pick keepassxreboot/keepassxc for one person who wants a local file and no server, dani-garcia/vaultwarden for a team that wants the official Bitwarden clients against a container you run, passbolt/passbolt_api for a company that needs team policies and an audit trail with the server holding no plaintext, and bitwarden/server when you want the upstream backend and have the staff to operate SQL Server and nine services. Before committing, put real HTTPS on the domain, confirm the data directory is on storage you back up, and read the licence files at the repository root.
Sources
Was this useful?