# bitwarden/server: self-hosting the Bitwarden backend with Docker

> The C# and SQL Server backend behind every Bitwarden client, packaged for self-hosting through Docker Compose. It is infrastructure for people who need to run their own vault service, not a library you drop into an app.

**bitwarden/server** — Bitwarden infrastructure/backend (API, database, Docker, etc).

- Repository: https://github.com/bitwarden/server
- Website: https://bitwarden.com
- Stars: 20,222 · Forks: 1,780
- Language: C#
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/bitwarden-server

## What bitwarden/server actually is, and who needs it

This repository is the backend half of Bitwarden. The README states that it contains the APIs, database, and other core infrastructure items needed for the "backend" of all Bitwarden client applications. The clients themselves live elsewhere. Nothing here renders a vault UI.

The audience is narrow and specific. First, people who want their password vault to sit on hardware they control, which is the self-host path the README points at. Second, contributors: the README sends developers to the Server Setup Guide in the Contributing Documentation for build instructions, tooling and code style. Third, anyone integrating against the API, since the API surface is defined in this codebase.

If you are evaluating password managers as a user, this repository is the wrong entry point. The useful question is not what the backend does but whether you are willing to operate it. The project ships a deployment script precisely because that operation is not trivial, and the script is the intended interface for self-hosters rather than a raw docker compose file.

## The service split behind a single Bitwarden login

The README's production image tables enumerate the components: Admin, API, Billing, Events, EventsProcessor, Identity, Notifications, SCIM, and SSO. They are published per cluster, with separate tables for the US and EU production clusters, and each entry is rendered from a JSON file under a metadata branch of this repository. That layout tells you the deployment is a set of cooperating services, not one process.

The stack is C# on .NET with ASP.NET Core, and the database is T-SQL on SQL Server. The repository topics confirm the same shape: aspnetcore, signalr, sql, sql-server. SignalR is the realtime channel, which is what the Notifications service exists to serve, so a client learns about vault changes without polling. Identity handles authentication separately from API, which is why a self-hosted install has more than one HTTP endpoint to think about.

The practical consequence is that backup and restore are database problems, not file-copy problems. Anyone treating the container volumes as the unit of backup is looking at the wrong layer. The README does not document rollback or downgrade for a self-hosted instance, and the help center article it links to is where deployment documentation lives.

## Installing bitwarden/server with the self-host script

The README gives two paths, one for Linux and macOS and one for Windows. Both download a helper script rather than asking you to clone and build. On Linux and macOS, the documented sequence fetches bitwarden.sh from func.bitwarden.com, makes it executable, then runs install and start:

```sh
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
```

The install step is interactive in the documented flow; it is where you supply the hostname and other settings the instance needs. The start step brings the containers up. The README does not enumerate the prompts, so treat the script's own output as the source of truth during install.

On Windows the equivalent uses PowerShell and the same download endpoint with a different platform parameter:

```cmd
Invoke-RestMethod -OutFile bitwarden.ps1 `
    -Uri "https://func.bitwarden.com/api/dl/?app=self-host&platform=windows"
.\bitwarden.ps1 -install
.\bitwarden.ps1 -start
```

Both routes require Docker and Docker Compose, which the README lists as the only dependencies and notes are free to use. Images come from the GitHub Container Registry, linked from the README's Deploy section, and the full deployment documentation is at help.bitwarden.com/article/install-on-premise/.

## Where self-hosting bitwarden/server becomes the wrong answer

The failure mode is operational, not functional. A self-hosted instance is a SQL Server deployment plus nine services, and the README's own structure makes that visible: separate images for Billing, SCIM and SSO mean features that a hosted account gets transparently are separate moving parts you now run. If your team has no one who can patch a database and rotate container images on a schedule, the hosted service is the better choice, and this repository is not a lighter alternative to it.

There is a second boundary worth stating plainly. The repository carries three licence files plus a LICENSE_FAQ.md and a TRADEMARK_GUIDELINES.md at the root, and the GitHub licence field reads NOASSERTION rather than a single SPDX identifier. That means the licensing is not one uniform grant across the tree. The bitwarden_license/ directory at the top level is a visible signal that some code sits under different terms than the rest. Anyone planning to redistribute a modified build, or to embed this backend in a commercial product, has reading to do before writing code, and the repository is telling you so by shipping a FAQ about it.

The README also does not document rollback. If a release breaks your instance, the documented material does not describe a supported way back to the previous version, so the downgrade path is something you establish yourself before you need it.

## bitwarden/server compared with Vaultwarden

The realistic alternative for a small self-hoster is Vaultwarden, an independent reimplementation of the Bitwarden server API. The difference is in what you are running. This repository is the official backend, written in C# on ASP.NET Core against SQL Server, and it is the same code that the production clusters in the README's image tables are built from. Vaultwarden takes the opposite approach: it reimplements the API surface in a different language and targets a much smaller resource footprint, so it can run comfortably on a small VPS where a full SQL Server deployment would not fit.

That trade is not free in either direction. Choosing this repository means your server tracks upstream behaviour by construction, because it is upstream, and the client compatibility question largely disappears. It also means accepting the full service topology, SQL Server, and the licensing structure described above. Choosing Vaultwarden means a smaller machine and a simpler deployment, at the cost of depending on a reimplementation whose correctness is maintained by a separate project. Neither is a drop-in replacement for the other in operational terms.

## Maintenance cadence and what upgrading costs you

The release cadence is monthly and dated. v2026.8.1 was published on 2026-09-02, v2026.8.2 on 2026-09-08, and v2026.9.0 on 2026-09-16, with the last push to the repository on 2026-09-19. The repository is not archived. That pattern means a self-hoster who wants current fixes is signing up for a monthly upgrade, and the version scheme is calendar-based, so the gap between releases is predictable rather than event-driven.

The cost of that cadence lands on the database and the container set, not on a package manager. Because the API, Identity, Billing, SCIM and SSO images move together, a partial upgrade is not a supported posture in anything the README describes. The repository does include a dev/ directory and a perf/ directory, plus an AppHost/ with an .aspire/ folder, which indicates the project maintains its own local orchestration and performance tooling for contributors. Those are development aids, not upgrade machinery for a production self-host.

On licensing, the honest summary is that this is a multi-licence repository and the README does not resolve it. LICENSE_FAQ.md exists for that purpose, and the trademark guidelines sit alongside it. Whether your intended use is covered is a question for that FAQ and, if the answer affects revenue, for a lawyer. The GitHub API's NOASSERTION value is a symptom of the split, not a description of it.

## Conclusion

Adopt bitwarden/server if you need to run the Bitwarden backend on your own hardware and can operate Docker Compose plus SQL Server, or if you are contributing to the upstream project. Do not adopt it if you only want a password manager for a handful of people, because the official hosted service removes the whole operational surface. Verify first that the deployment script and image tags match the release you intend to run, and read LICENSE_FAQ.md together with the three licence files at the repository root before you decide how the code can be used.

## FAQ

### How do I install bitwarden/server on Linux?

The README documents downloading bitwarden.sh from func.bitwarden.com, making it executable, then running ./bitwarden.sh install followed by ./bitwarden.sh start. Docker and Docker Compose are the only listed dependencies.

### Does bitwarden/server include the client apps?

No. The README describes it as the APIs, database, and other core infrastructure items needed for the backend of all Bitwarden client applications, so the clients are separate.

### What database does bitwarden/server use?

The README states the database is written in T-SQL/SQL Server, and the repository topics list sql and sql-server.

### Which services make up a bitwarden/server deployment?

The README's production image tables list Admin, API, Billing, Events, EventsProcessor, Identity, Notifications, SCIM and SSO, published separately for the US and EU production clusters.

### Under what licence is bitwarden/server released?

The repository root contains LICENSE.txt, LICENSE_AGPL.txt, LICENSE_BITWARDEN.txt and a LICENSE_FAQ.md, and the GitHub licence field reads NOASSERTION. The FAQ file is the place the project addresses how the terms apply.

## Sources

- [bitwarden/server on GitHub](https://github.com/bitwarden/server)
- [Issues](https://github.com/bitwarden/server/issues)
- [Project website](https://bitwarden.com)
- [README](https://github.com/bitwarden/server/blob/main/README.md)
- [Releases](https://github.com/bitwarden/server/releases)

---

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