Vaultwarden runs a Bitwarden-compatible password server on small hardware, and the security work is yours

01A compatible server, not the official one

The README describes Vaultwarden as an alternative server implementation of the Bitwarden Client API, written in Rust and compatible with the official Bitwarden clients, aimed at self-hosted deployments where running the official, resource-heavy service may not be ideal. It implements most of the API: personal vaults, Send, attachments, website icons, personal API keys, organizations with collections, groups, member roles, event logs, policies and admin password reset, emergency access, and two-factor methods including authenticator apps, email, FIDO2 WebAuthn, YubiKey and Duo.

The disclaimer is explicit that the project is not associated with Bitwarden, Inc., although one active maintainer is employed by Bitwarden and contributes on their own time, with that work reviewed by other maintainers. The README asks users to report bugs to Vaultwarden directly and not to use Bitwarden's support channels. The project was previously called Bitwarden_RS and was renamed to avoid confusion with the official server. Compatibility depends on keeping up with client changes, which is why update discipline is part of running it.

02HTTPS is required

The README states that the web vault requires HTTPS and a secure context for the Web Crypto API, so it only works once HTTPS is enabled. Vaultwarden is built on the Rocket web framework, which can serve TLS itself, but the project recommends a reverse proxy and keeps proxy examples in its wiki. Its sample docker run command publishes the container's port only on 127.0.0.1:8000, which keeps the plain HTTP port off the network and leaves the proxy as the only way in.

Set DOMAIN to the exact HTTPS address clients will use, as the README's examples do. Use the reverse proxy for TLS, rate limiting and access logs. Decide whether the vault needs to be reachable from the internet at all; many households can keep it on a home network or behind a VPN, which removes most of the exposure. If it must be public, keep the proxy and the host operating system patched as carefully as Vaultwarden itself.

03Close registration

By default, anyone who can reach a Vaultwarden instance can register a new account. The wiki page on disabling registration gives the fix: set SIGNUPS_ALLOWED to false. Even then, an existing organization owner or admin can still invite new users, and the Vaultwarden admin can invite anyone from the admin page. If SIGNUPS_DOMAINS_WHITELIST is set, it takes precedence and SIGNUPS_ALLOWED is ignored.

The safe order is to start the server, create the accounts that should exist, then turn sign-ups off and recreate the container with the new setting. Review invitation rights in each organization, since an invitation is still a way into the server. Keep a list of expected accounts and compare it with the admin page from time to time. An unexpected account on a password server is an incident to investigate.

04The admin page and its token

The optional admin panel lets the server administrator configure Vaultwarden, view and delete users and organizations, invite users while registration is closed and generate a support string for diagnostics. It is enabled by setting ADMIN_TOKEN, which acts as the admin password. The wiki recommends a long random value, warns that configuration is usually stored in plain text, and documents hashing the token as an Argon2id PHC string with the built-in vaultwarden hash command, which uses Bitwarden's defaults and also offers an OWASP preset.

Signing in to the admin page issues a JSON Web Token with a default session length of 20 minutes, and the wiki notes there is no further session handling, so changing the token does not end sessions already issued; deleting rsa_key.pem and restarting does. If the admin page is not needed day to day, leave it disabled by setting neither ADMIN_TOKEN nor DISABLE_ADMIN_TOKEN and removing any admin_token entry from config.json. Disabling the token requirement gives unrestricted access to the panel, which has no place on a reachable instance.

05The data folder is the vault

Vaultwarden keeps its state in a data directory that the DATA_FOLDER variable can move. With the default SQLite backend, db.sqlite3 holds almost all important data. The backup wiki recommends the SQLite .backup command, which uses SQLite's online backup API, or VACUUM INTO, and since version 1.32.1 a built-in /vaultwarden backup command that also works through docker exec. Attachments are stored as separate files and must be backed up as well. config.json and the rsa_key files are recommended; the icon cache and Send attachments are optional.

The wiki points out two traps. The Docker image contains neither an sqlite3 binary nor a cron daemon, so scheduled backups usually run on the host. When restoring a backup made with .backup or VACUUM INTO, delete any existing db.sqlite3-wal file first, or SQLite may try to recover with a mismatched write-ahead log and corrupt the database. config.json can hold the admin token and SMTP credentials in plain text, and rsa_key.pem could in principle help forge sessions, so encrypt any backup that leaves the machine.

• Back up db.sqlite3 with a supported method, never by copying it alone while the server runs.
• Include attachments, config.json and the rsa_key files in every backup set.
• Restore to a spare machine regularly and sign in with a real client to prove it works.

06Security releases need applying

The GitHub releases API listed 1.37.4, published October 5, 2026, as the latest release when this guide was checked. Its notes list fixes for seven advisories, covering organization member revocation (rated high), two-factor authentication, organization invitations, attachments, organization event logs, cipher sharing and the organization API key, and they strongly advise updating as soon as possible. They also suggest rotating an organization's API key after updating if its admins are not fully trusted.

A password server cannot sit on an old version. The wiki's container image page gives a second reason: Bitwarden controls client releases, and mobile apps and browser extensions update themselves, so an outdated server can suddenly become incompatible with its clients. Watch the releases, use the latest tag or a pinned version that someone actively bumps, and keep a short checklist for each update: back up, pull, restart, sign in from each client type and check the admin diagnostics.

07Image tags and installation choices

Container images are published to ghcr.io, docker.io and quay.io. The latest tag tracks the newest released version and is recommended for most users, testing tracks the latest commits, and Alpine-based variants such as latest-alpine are functionally the same on a smaller base. The README also mentions community packages, which may lag behind or configure Vaultwarden differently, and building the binary from source. A Docker Compose example in the README mirrors the docker run command.

Prefer the official images unless a distribution package is maintained by someone you trust to ship security fixes quickly. Keep the compose file and non-secret settings in version control, and keep the admin token hash and SMTP credentials in a secret store. If the database moves to MySQL or PostgreSQL, the backup plan changes: the wiki notes that those need their own dumps in addition to the data folder.

08License and fit

Vaultwarden is licensed under the AGPL-3.0, and its containers bundle a modified build of the Bitwarden web vault maintained in a separate repository. The AGPL's source-sharing conditions are written around offering modified versions to users over a network, so they matter most to someone who changes the server and runs it for other people.

Vaultwarden fits people who want Bitwarden's clients with a light server they control, and who will patch it, back it up and watch who has accounts. The README's own disclaimer says the maintainers cannot be held liable for data loss and recommends regular backups of files and database. Organizations with compliance requirements or a need for vendor support should weigh that against the official offering before choosing.