The Bitwarden self-host repository is where the images and install scripts live

A packaging repository rather than the server source

bitwarden/self-host is described as Bitwarden's dedicated self-hosted release repository, and it holds the installation scripts and container images for the self-host project. That definition sets expectations correctly. There is no application source here, no database schema and no server code to review, which means there is also nothing in this repository you can usefully patch yourself. The primary language recorded for the repository is Shell, which reflects what the top-level entries actually are: bitwarden.sh and bitwarden.ps1 for Linux and macOS and Windows respectively, run.sh and run.ps1 as the entry points that drive them, version.json carrying the version, and a bitwarden-lite directory. Around those sit the marketplace listings, with directories for AWSMarketplace, AzureMarketplace, CommonMarketplace and DigitalOceanMarketplace, which is how the same product is published to several cloud marketplaces from one place. The repository also carries the administrative files you would expect from a project of this kind, with CONTRIBUTING.md, SECURITY.md, a CLAUDE.md and an MIT-style editor configuration. For an operator, the useful question is not what is in this repository but which of its artefacts you will use.

Cosign keyless signing is the provenance check

The container images are published to the ghcr.io registry as OCI-compliant images, and every image published there is signed with Cosign's keyless signing, which binds the signature to the GitHub Actions workflow that built it. The README gives the verification command, and it is worth reading closely because the identity regexp encodes where the build is supposed to have happened:

$ cosign verify ghcr.io/bitwarden/$IMAGE_NAME:latest --certificate-identity-regexp="https://github\.com/bitwarden/deploy/\.github/workflows/release-self-host\.yml@.*" --certificate-oidc-issuer="https://token.actions.githubusercontent.com"

You set $IMAGE_NAME to an image in the repository and the command checks the certificate identity against the deploy repository's release-self-host workflow, plus the OIDC issuer of the GitHub Actions token endpoint. The point of keyless signing here is that there is no long lived signing key to distribute or rotate. The trust anchor is the workflow path and the issuer, so a signature from some other pipeline fails the check. For a credential vault, that is the right shape of guarantee, and it costs one command and a Cosign binary to check.

Images before 2026.4.1 need a different identity regexp

There is a wrinkle that will bite anyone who verifies an older image with the current command. The documentation states that images released before 2026.4.1 were signed by a release workflow that lived in this repository, and to verify those you must use the self-host repository's own workflow path instead:

--certificate-identity-regexp="https://github\.com/bitwarden/self-host/\.github/workflows/release\.yml@.*"

The workflow was moved, and the signing identity changed with it, so the verification recipe is version dependent even though the trust model is the same. The practical consequence is that a pin-and-verify script has to know something about when the image was built, or it has to try both identities. This is exactly the kind of detail that belongs in a runbook, and the README states it in a single sentence that is easy to skim past. It is also a small reminder that a self-hosted deployment inherits a moving set of artefacts, and the older the tag you run, the more likely it is to have been signed under the previous arrangement.

Four deployment paths with different commitments

The repository offers several ways to get a running instance, and they are not equivalent. The quickest path is the one-click deploy buttons, with a Deploy to DigitalOcean badge pointing at the marketplace listing and a Deploy to Azure badge pointing at the Azure portal entry, both presented as buttons in the README. For Kubernetes, the documented route is a Helm chart maintained in a separate repository, bitwarden/helm-charts, whose chart README is linked from the self-host README. The third path is the shell installers in this repository, which are what the marketplace listings and the run scripts use under the hood, and the fourth is running the published container images yourself with any orchestrator you prefer. The difference in approach is where the state of your deployment lives. A marketplace app or a Helm release owns its own upgrade path, and you accept the terms of that platform. The container images leave you in charge of pulling, pinning and upgrading, which is more work and more control. The install scripts sit in between, writing a configuration and pulling images for you on a host you control.

Release tags follow a date-based version scheme

The release history explains the versioning without needing a changelog. Tagged releases include v2026.9.0 on 2026-09-17, v2026.9.1 on 2026-10-01 and v2026.10.0 on 2026-10-15, and the last push to the repository was on 2026-10-16. The scheme is a year and month with a patch counter, which is a sensible choice for a self-hosted product because the number tells an operator which monthly image they are on without needing to look anything up. The monthly cadence also means the cost of self-hosting is a recurring one: a security fix arrives as a new tag, and the work of pulling it, checking the signature and restarting the services happens every month whether you wanted it or not. The version.json file in the repository root is the natural place to look for the version the scripts expect, and bitwarden-lite suggests a lighter variant is part of the same packaging tree, though the documentation in the README does not describe what separates it from the standard deployment. The repository also redirects questions about specific client applications to the bitwarden/clients repository, which keeps support traffic for the desktop and mobile apps out of the release repository.

Editorial conclusion

Adopt this repository if you run Bitwarden yourself and want to pull official images and confirm their provenance, since the verification recipe in the README is short and the image tags track monthly releases. Do not treat it as a place to file product issues, because the documentation redirects client questions to the bitwarden/clients repository, and do not assume the images are the whole server, since this repository holds packaging rather than the application source. Before you deploy, check which signing workflow your image used, since images released before 2026.4.1 need a different certificate identity, and decide between the marketplace one-click paths, the Helm chart and the shell installers, because each commits you to a different upgrade path.

Frequently asked questions

Official sources

1. bitwarden/self-host on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases