# bitwarden/clients: the monorepo behind Bitwarden's web, browser, desktop and CLI apps

> bitwarden/clients holds every Bitwarden client except the mobile apps. It is a contributor-facing Nx monorepo, not an installable product, and the README points developers elsewhere for build instructions.

**bitwarden/clients** — Bitwarden client apps (web, browser extension, desktop, and cli).

- Repository: https://github.com/bitwarden/clients
- Website: https://bitwarden.com
- Stars: 13,799 · Forks: 2,024
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-08-24 · Updated: 2026-08-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/bitwarden-clients

## What bitwarden/clients actually is, and who it is for

This is the source repository for Bitwarden's client applications: the web vault, the browser extension, the desktop app and the CLI. The README states plainly that it houses all Bitwarden client applications except the mobile applications, which live in bitwarden/ios and bitwarden/android. The package.json names the workspace @bitwarden/clients and describes it as "Bitwarden Client Applications".

The audience is narrow. Someone who wants a password manager does not need this repository; they need a released build. Someone who wants to change how the browser extension autofills a form, or who wants to read the code that decrypts a vault, does need it. The README is explicit about where to start: refer to the Clients section of the Contributing Documentation for build instructions, recommended tooling and code style tips. That link, not this README, is the entry point.

The repository also carries a hiring notice and a contribution section. That is a signal about who the maintainers expect to show up: people filing pull requests against main, not people looking for a download link. If you arrived here from a search for a Bitwarden installer, you are in the wrong place.

## One Nx workspace, four apps, and a shared libs layer

The layout is the mechanism. apps/ holds the four client applications. libs/ holds shared code that those applications consume. nx.json, angular.json and tsconfig.base.json sit at the root and define how the workspace is wired together, which is why the repository is best understood as a build graph rather than a folder of unrelated projects.

The root package.json exposes the tasks you would expect from that arrangement. test runs jest. lint runs eslint and prettier together. test:types runs a script that checks types across the workspace. There are separate scripts for Rust linting and for locale testing, which tells you the client code is not purely TypeScript in practice even though TypeScript is the primary language.

The presence of bitwarden_license/ as a top-level directory is the detail worth pausing on. Shared code and licensed code sit side by side in one workspace, which is convenient for the maintainers and mildly confusing for anyone trying to work out what they may reuse. The repository root carries LICENSE.txt, LICENSE_GPL.txt and LICENSE_BITWARDEN.txt, three files rather than one.

## Getting the workspace running and making a first change

The README gives no build commands. It redirects to the Clients section of contributing.bitwarden.com for build instructions and recommended tooling, so treat that page as authoritative and treat anything below as orientation only.

What the repository itself confirms is the toolchain. The root package.json declares GPL-3.0 as its licence and uses npm scripts, and .nvmrc pins a Node version, so the first move is to match that version rather than whatever Node you happen to have.

```bash
git clone https://github.com/bitwarden/clients.git
cd clients
nvm use
npm ci
```

After dependencies install, the scripts in package.json are what you run. Linting and tests are the two commands a new contributor will reach for first, and both are defined at the workspace root rather than per app.

```bash
npm run lint
npm test
```

The component work has a live preview path. Storybook is wired in through the workspace, with a script named storybook that runs the components target and additional scripts for the autofill components under apps/browser. If you are changing UI rather than logic, that is the loop to use.

```bash
npm run storybook
```

For anything beyond this, follow the contributing documentation. The repository is not self-describing about how to produce a working browser extension or desktop build.

## Where bitwarden/clients is the wrong repository to open

If you want to run a Bitwarden server, this is not it. The README lists bitwarden/server as the core infrastructure backend covering API, database and Docker. Cloning the clients repository and looking for a server to start will not work, and nothing in the README suggests otherwise.

If you want the mobile apps, the README sends you to bitwarden/ios and bitwarden/android. The clients repository deliberately excludes them, so an Android bug is not fixable here.

The sharper limitation is documentation. The README is a signpost, not a manual. It contains no build steps, no architecture description and no explanation of how the four apps relate to the shared libraries. Everything substantive lives on contributing.bitwarden.com, an external site. If that site is unavailable or out of date relative to main, the repository gives you almost nothing to fall back on. For a codebase of this size, that is a real cost for a newcomer.

There is also the licence question. The package.json declares GPL-3.0, but the repository root carries LICENSE_GPL.txt and LICENSE_BITWARDEN.txt alongside LICENSE.txt, and there is a bitwarden_license/ directory. Anyone planning to reuse client code in another product needs to read those files rather than trusting the single field in package.json.

## How this differs from bitwarden/server

The two repositories split the product along a clean line. bitwarden/server is the backend: API, database, Docker packaging. bitwarden/clients is the front end that talks to it, spread across four app targets and a shared library layer in one Nx workspace.

That split matters when you are deciding where a change belongs. A bug in how a vault item is displayed belongs in clients. A bug in how that item is stored or returned by the API belongs in server. The README's Related projects list makes the boundary explicit and also names bitwarden/directory-connector, a separate tool for syncing a directory such as AD, LDAP, Azure, G Suite or Okta into an organization. That is a third repository again, and it is not part of the client workspace.

The practical difference in approach is that server is a deployable service and clients is a build graph producing four artifacts. You can run a server. You build clients.

## Maintenance, releases and the cost of tracking main

The repository is not archived, and the last push was on 2026-08-19. Releases are versioned per application rather than as one product: web-v2026.8.0, cli-v2026.8.0 and desktop-v2026.8.0 all landed in August 2026. The separate tags tell you the four clients are not shipped in lockstep, which is worth knowing if you are pinning a version.

For a contributor, the upgrade cost is mostly toolchain churn. The workspace pins Node through .nvmrc and dependencies through package-lock.json, so npm ci gives you the versions the maintainers expect. The lint and test scripts are centralised, which means a change in eslint.config.mjs or jest.preset.js affects every app at once. That is efficient for the maintainers and occasionally disruptive for a fork that has diverged.

On licensing, package.json declares GPL-3.0, and the root also holds LICENSE.txt, LICENSE_GPL.txt and LICENSE_BITWARDEN.txt with a bitwarden_license/ directory. The README does not explain how those files divide the codebase. Read them before you plan to redistribute anything; this is a factual gap in the documentation, not a legal opinion.

## Conclusion

Adopt this repository if you are contributing to a Bitwarden client or auditing how the clients are assembled; if you only want a password manager, install a released build instead. Before cloning, read the Clients section of contributing.bitwarden.com, since the README here gives no build steps, and check LICENSE.txt alongside LICENSE_GPL.txt and LICENSE_BITWARDEN.txt rather than assuming a single licence covers everything under apps/ and bitwarden_license/.

## FAQ

### What is bitwarden/clients?

It is the repository that houses all Bitwarden client applications except the mobile apps, covering the web vault, browser extension, desktop app and CLI. The README points to the Clients section of the Contributing Documentation for build instructions.

### Does bitwarden/clients include the mobile apps?

No. The README states the repository houses all Bitwarden client applications except the mobile applications, and links to bitwarden/ios and bitwarden/android separately.

### How do I build bitwarden/clients?

The README does not give build steps. It refers readers to the Clients section of the Contributing Documentation at contributing.bitwarden.com for build instructions, recommended tooling and code style tips.

### What licence does bitwarden/clients use?

package.json declares GPL-3.0. The repository root also contains LICENSE.txt, LICENSE_GPL.txt and LICENSE_BITWARDEN.txt along with a bitwarden_license/ directory, and the README does not explain how those apply to different parts of the code.

## Sources

- [Official documentation](https://bitwarden.com)
- [Official README](https://github.com/bitwarden/clients#readme)
- [Project repository](https://github.com/bitwarden/clients)
- [Release notes](https://github.com/bitwarden/clients/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bitwarden-clients