Vaultwarden: A Bitwarden-Compatible Server for Self-Hosting

What it is for

Vaultwarden is an unofficial implementation of the Bitwarden Client API written in Rust, and it can work with official Bitwarden clients. It is a server-side option for self-hosters who want to manage their own deployment, data storage, and upgrade arrangements. Repository metadata identifies its license as AGPL-3.0.

The support boundary matters before adoption. The project states that it is not associated with Bitwarden or Bitwarden, Inc. It asks users to send bugs and suggestions to Vaultwarden’s own community and project channels, rather than to official Bitwarden support, regardless of whether a mobile, desktop, or browser client is in use. Teams that need vendor-backed support, established service processes, or particular compliance materials should account for that distinction.

Documented capabilities

The README calls Vaultwarden a “nearly complete” implementation of the Bitwarden Client API. Its listed personal features include a personal vault, Send, attachments, website icons, and a personal API key.

The organization feature list includes collections, password sharing, member roles, groups, event logs, administrator password reset, Directory Connector, and policies. Listed multi-factor or two-factor authentication methods include an authenticator, email, FIDO2 WebAuthn, YubiKey, and Duo. The project also lists emergency access, a Vaultwarden admin backend, and a modified Web Vault client bundled with its containers.

These are capabilities documented by the project; they do not establish that every combination of client version, authentication method, and deployment arrangement has been validated in the same way. Before using it in an operational environment, confirm the sign-in, organization, attachment, and recovery workflows required for your own use case.

Deployment considerations and limits

The README recommends the project’s container images published on ghcr.io, docker.io, and quay.io. It also mentions community-maintained packages and self-built deployments, while warning that community packages can lag behind the project version or differ in configuration. When using such packages, operators need to verify their maintainer, update path, and configuration differences.

The Web Vault requires HTTPS and the secure context needed by the Web Crypto API. The README explicitly says that the Web Vault will not work without HTTPS, and it recommends a reverse proxy. Its container example also mounts a host data directory for persistent data. Deployment planning should therefore cover data location, backup and recovery arrangements, domain configuration, and certificate maintenance.

Client compatibility also needs attention. The 1.37.2 release notes say that this update is required for support with clients version 2026.8.0 and later. During upgrades, check both the server release and the client versions in use, and consult the project’s issues and discussions rather than updating only one side. The supplied sources provide no minimum hardware requirements, performance figures, availability commitments, or security conclusions, so none are inferred here.

Who should consider it

Vaultwarden is better suited to self-hosters prepared to maintain containers or a private service and to handle HTTPS, reverse proxies, persistent data, backups, and upgrades themselves. It warrants careful evaluation for people who primarily expect official Bitwarden support channels or do not want the operational responsibility of running a password-vault service.

Before production use, test client sign-in, the organization functions you need, two-factor authentication, attachment access, and recovery steps with non-critical data. Record server and client versions, backup status, and the recovery procedure so that configuration, version, and client relationships can be examined during upgrades or troubleshooting.

Sources

• GitHub repository metadata
• Project README
• Official release
• Official project page

Sources checked: 2026-09-12