Bitwarden offers a useful free password-manager tier, but some users prefer to operate the server that stores their encrypted vault. That preference for control is the starting point of this article. Vaultwarden offers an alternative server with familiar Bitwarden clients, while making maintenance and recovery your responsibility. Self-hosting changes who operates the service; it does not make attacks or mistakes impossible.

What is Vaultwarden?

Vaultwarden, formerly bitwarden_rs, is an unofficial, community-maintained Bitwarden-compatible server written in Rust. It implements much of the client API, including personal vaults, organisations, collections, sharing, attachments, Send, emergency access and supported two-factor methods. It is not an official Bitwarden server or an assurance that every new client feature will work immediately.

The project asks users to report Vaultwarden problems to its own maintainers rather than Bitwarden's support. Compatibility remains a reason to follow both server releases and client updates. Start by checking the actual clients your household uses instead of assuming identical behaviour across all apps and versions.

Pricing, hosting costs and the original preference

The original article quoted Bitwarden Premium at US$10 per year and Families at US$40. Those were historical figures. The current pricing page lists Premium at US$19.80 annually and Families at US$47.88 annually for up to six users. Check checkout terms and local taxes before making a financial comparison.

The Free plan still provides core password management without purchasing Premium. Paid plans add features such as the integrated authenticator, attachments, emergency access and additional security reporting. “Vault health reports” is not a blanket description of everything available free; inspect the particular report and plan. Bitwarden also has official self-hosting options, so the choice is broader than its cloud service versus Vaultwarden.

The article's favourable view of operating your own service remains, as does its recognition that supporting Bitwarden funds the upstream product. Vaultwarden has no per-user software subscription, but the server, electricity, backups, domain and your time can have real costs. Compare those with the subscription you would actually buy. An already-running home server may make hosting inexpensive; a newly purchased server changes that calculation.

How self-hosting fits into a homelab

The companion Build Your Own Homelab series discusses the Docker instance and Portainer. The official Vaultwarden wiki provides installation and configuration guidance. The standalone example below has its own stated assumptions; do not paste it over an existing deployment or assume every historical screenshot uses the same version.

Vaultwarden commonly uses SQLite and a persistent data directory. The database contains encrypted vault records and server state; attachments and other files also live outside database tables. A container is disposable, while its mounted data must survive replacement. No fixed “under 25 MB RAM” figure establishes capacity for every installation.

A private fresh-install Compose example

The example uses the verified 1.37.4 security release and a reverse proxy running on the same Docker host. The proxy must already provide a valid HTTPS name and support the project's HTTP/WebSocket proxy configuration. Its backend is 127.0.0.1:8085. A proxy in another container cannot reach this host-loopback address as its own localhost; use the documented shared-container-network arrangement for that layout.

In a new project directory, create a .env file with VW_DOMAIN set to the complete HTTPS URL you own and have configured. For example, replace https://vault.example.com with that real address. Compose refuses to start this example if VW_DOMAIN is unset. Keep the URL stable and reachable by your clients. Limit access to your own devices during account creation.

services:
  vaultwarden:
    image: vaultwarden/server:1.37.4
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "${VW_DOMAIN:?Set VW_DOMAIN to your configured HTTPS URL}"
      SIGNUPS_ALLOWED: "true"
      INVITATIONS_ALLOWED: "false"
    volumes:
      - ./vw-data:/data
    ports:
      - "127.0.0.1:8085:80"

This first-run template temporarily allows registration so intended users can create accounts. Keep it private; do not leave open registration exposed. Validate and start it:

docker compose config --quiet
docker compose up -d
docker compose ps

After creating the intended accounts, change SIGNUPS_ALLOWED to false and run docker compose up -d again to apply it. Confirm a new uninvited account cannot register. Organisation invitations are a separate setting; the example disables those as well. If you enable them later, read the registration and invitation rules.

No admin token is set in this fresh example, so the administration page remains disabled. If an existing deployment previously saved settings in config.json, those values can override environment variables and the page may remain enabled. Follow the admin-page guide for intentional configuration. Its Argon2 hash procedure creates a real PHC string; a truncated sample token is not usable protection. Never disable the token requirement to fix a login problem.

HTTPS and account protection

The web vault requires a secure browser context for Web Crypto. Plain HTTP to a LAN IP is not equivalent to trusted HTTPS; localhost is a special browser exception on the computer running the browser. The Web Crypto requirement specifically concerns the web client, rather than a claim that native apps run their encryption through a browser API.

Use the project's proxy guidance, strong master passwords and supported two-factor authentication. Certificate issuance and application reachability are separate: a DNS challenge can obtain a certificate without publishing the vault, but clients still need a working private or public route. Test sign-in, sync and a harmless new item on each intended client, then confirm the item appears on a second client.

Backups and offline access

The backup guide distinguishes a consistent SQLite backup from copying a live database arbitrarily. Current Vaultwarden has a built-in database backup command:

docker exec vaultwarden /vaultwarden backup

This does not by itself create a complete off-server recovery set. Protect attachments, relevant Send files, signing keys and configuration, plus the Compose/proxy configuration. For a simple consistent full-directory copy, schedule downtime, stop writes by stopping the container, copy its entire data directory to independent protected storage, and restart the service. For online backups, coordinate database and file consistency using the documented method.

Test restoration into a separate directory and isolated instance before relying on it. Retain the original data, stop the restore target and follow the guide's database/WAL rules; mixing an older database with an unrelated WAL file can corrupt recovery. Check an actual vault item and attachment, not just whether the login page appears.

Bitwarden documents read-only offline use of an unlocked app. Prepare and test that state before travel. It is not a guarantee that every device, logged-out client, attachment or unsynchronised item remains available when the home server fails. Keep recovery codes accessible independently of the vault they protect.

A useful choice when you can operate it

Vaultwarden remains a compelling option for the article's preference for control and familiar clients. Treat maintenance as part of that control: read security releases, back up before planned upgrades, verify client compatibility afterward and keep an independent recovery path. Owning the server and paying no per-user licence fee are meaningful advantages; they do not eliminate the work of keeping a password service available and recoverable.

Related Articles:#Homelab#Docker#Cybersecurity#Network Security