How to Self-Host Vaultwarden: Complete Guide to Installation, HTTPS, Security, and Remote Access

What Vaultwarden is, and what it is not

Vaultwarden, formerly called bitwarden_rs, is an alternative server implementation of the Bitwarden Client API written in Rust. It is not produced by or affiliated with Bitwarden, Inc. The project provides its own server, a modified web vault bundled with its container images, and support for many familiar Bitwarden capabilities.

The project describes its API implementation as nearly complete. That distinction matters. Official Bitwarden browser extensions, mobile applications, and desktop clients are commonly used with Vaultwarden, but compatibility should not be treated as universal or permanent. A newly released client feature can depend on an API behavior that Vaultwarden has not implemented yet. Test the specific clients and workflows your users need before treating an upgrade as production-ready.

Vaultwarden recommends its published container images for installation. Community packages and source builds are alternatives, but a community package may lag behind current releases or change configuration conventions. This tutorial therefore uses the official Vaultwarden container image with Docker Compose and a persistent host directory.

Durable deployment distinctions

The meaningful choice is not a volatile price or container count. It is who operates the server, who supports it, and who is responsible for recovery. Product pricing, resource requirements, feature entitlements, and supported deployment methods can change, so they should be checked directly before making a long-term decision.

Self-hosting gives you operational control, but it also makes availability and recovery your job. A database on hardware you control is not automatically private, secure, or resilient. Host compromise, weak credentials, an exposed administration panel, an untrusted backup destination, or an untested restore can still put the vault at risk.

HTTPS, secure contexts, and the actual trust boundary

Vaultwarden's web vault uses browser cryptography and requires HTTPS and a secure context. Browsers generally treat a valid HTTPS origin as potentially trustworthy. Loopback origins such as http://localhost also receive special secure-context treatment in common browsers, which is useful for same-machine testing. An ordinary LAN address such as http://192.168.1.20 is not equivalent to localhost and should not be used as the remote web-vault address.

The phrase “any HTTPS URL works” is too broad. The certificate must be valid for the requested hostname and trusted by the device. An expired certificate, hostname mismatch, incomplete certificate chain, or untrusted private certificate authority can produce warnings or prevent a native client from connecting. Never instruct users to ignore a certificate warning for a password manager.

HTTPS options

Where TLS ends in this tutorial

This deployment intentionally binds Vaultwarden to 127.0.0.1:8080. A remote Bitwarden client connects to the assigned Localtonet HTTPS endpoint. HTTPS is terminated at the public tunnel edge, and traffic is carried through the outbound Localtonet tunnel to the Localtonet client. The final connection from that client to http://127.0.0.1:8080 is local HTTP.

That is not the same as TLS terminating inside Vaultwarden. The trust boundary includes the public tunnel endpoint, relay path, Localtonet client process, host operating system, Docker runtime, and Vaultwarden container. Keeping the Localtonet client and Vaultwarden on the same trusted host confines the final HTTP hop to loopback. If the client forwards to a different machine on a LAN, that final hop crosses the LAN in clear HTTP unless you independently add TLS there.

Prerequisites and supported installation scope

This tutorial covers a 64-bit Linux host, including a supported 64-bit Raspberry Pi installation, with Docker Engine and the Docker Compose plugin. Docker and Compose must be installed using the supported method for your operating system. The convenience script previously shown in this article is intentionally omitted because Docker documents caveats for that route and it should not be presented as the default production installation method.

• A maintained 64-bit Linux distribution supported by Docker Engine.
• Docker Engine and Docker Compose v2 installed from the appropriate package repository or supported platform package.
• A non-root administrative account with controlled Docker access.
• A persistent filesystem with enough capacity for the database, attachments, Sends, logs, and backup staging.
• A Localtonet account and an installed Localtonet client on the same host for the loopback design used here.
• A password manager or offline method for storing the distinct Vaultwarden admin credential, master password, two-factor recovery codes, device token, and backup-encryption key.

Use Docker's operating-system-specific Engine installation instructions and Compose installation instructions. Package names and repository setup differ by distribution, so this guide does not substitute a generic shell pipeline for those checks.

docker --version
docker compose version
docker info

All three checks should complete without an unexpected connection or permission error. Membership in the Docker group is effectively privileged host access because a user who controls Docker can mount host paths and start privileged containers. Grant it only to administrators who require it.

Install Vaultwarden with Docker Compose

The following deployment follows Vaultwarden's documented container pattern: a persistent /data mount, a loopback-only published port, a configured public domain once one is assigned, and a restart policy. Review the current Vaultwarden release notes and container-tag guidance before production use. The moving latest tag is convenient for an initial setup, but it should not be pulled automatically without review.

mkdir -p "$HOME/vaultwarden/vw-data"
cd "$HOME/vaultwarden"
chmod 700 "$HOME/vaultwarden" "$HOME/vaultwarden/vw-data"

docker run --rm -it vaultwarden/server:latest /vaultwarden hash

umask 077
cat > .env <<'EOF'
ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$replace_with_generated_salt$replace_with_generated_hash'
SIGNUPS_ALLOWED=true
TZ=Etc/UTC
EOF
chmod 600 .env

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    env_file:
      - .env
    volumes:
      - ./vw-data:/data
    ports:
      - "127.0.0.1:8080:80"

docker compose config --quiet
docker compose up -d
docker compose ps
docker compose logs --tail=100 vaultwarden

curl -I http://127.0.0.1:8080/
docker compose ps
docker compose logs --tail=100 vaultwarden

Create the Localtonet HTTPS access path

Localtonet exposes a service through an outbound connection from the client device to a Localtonet relay server. It does not require inbound router port forwarding, a public IP address, firewall changes, or VPN setup. For this deployment, create an HTTP tunnel whose local target is 127.0.0.1 on port 8080.

HTTP tunnels can use a generated subdomain, a custom subdomain where supported, or a custom domain. All three process types serve the target at a public HTTPS address. Do not assume a fixed hostname pattern. Use the exact URL assigned by the current dashboard.

cd "$HOME/vaultwarden"
printf '\nDOMAIN=https://your-exact-assigned-hostname\n' >> .env
chmod 600 .env
docker compose up -d
docker compose logs --tail=100 vaultwarden

Access controls and client compatibility

Where your selected Localtonet configuration supports them, IP allowlisting and related access controls can reduce exposure. Apply least privilege and test every required client network. A narrow home IP allowlist, for example, may block a phone when it switches to mobile data.

Be careful with an additional HTTP Basic Authentication, SSO, or interactive authentication layer in front of Vaultwarden. A browser can display an extra login prompt, but a Bitwarden native client may not know how to complete that challenge for API and synchronization requests. Do not enable an outer authentication layer until you have tested login, synchronization, attachments, Sends, and every required client.

First login and security hardening

Create the initial account and close registration

Open the assigned HTTPS URL and confirm that the browser reports a valid certificate for the exact hostname. Create the intended account with a unique master password. After all authorized initial accounts are created, change SIGNUPS_ALLOWED to false and recreate the container:

cd "$HOME/vaultwarden"
sed -i 's/^SIGNUPS_ALLOWED=.*/SIGNUPS_ALLOWED=false/' .env
docker compose up -d
docker compose logs --tail=100 vaultwarden

Then use a private browser window to confirm that public registration is no longer available. Do not rely only on the value in the file. A persisted administration configuration can affect effective settings, so test the actual public behavior after every security change.

Protect or disable the administration panel

The administration endpoint controls server settings and user administration. At /admin, enter the original administration password used to generate the Argon2 hash, not the PHC string stored in .env.

Use an administration password unrelated to every vault master password. Do not expose the administration endpoint more broadly than necessary. If you do not need ongoing web administration, consider disabling it by removing the admin token after completing required configuration. If you retain it, combine a strong credential with compatible tunnel restrictions and monitor access attempts.

Enable two-factor authentication and preserve recovery material

Enable a supported two-step login method for each account. Vaultwarden currently implements multiple authentication options, including authenticator-based codes and FIDO2 WebAuthn. Availability and behavior can vary by client and configuration, so enroll and test at least two client sessions before declaring the setup complete.

Store recovery codes outside the vault in a physically or cryptographically protected location. A recovery code kept only inside the vault is unavailable precisely when it is most needed. Do not assume the server administrator can decrypt a user's vault or reset a forgotten master password. Some organization and client recovery workflows may exist when configured in advance, but they are not a universal operator override.

Secure the host and secrets

Why this guide does not publish a Fail2Ban sidecar

A working Fail2Ban design requires the application log to contain the real client IP, a verified trusted-proxy configuration, and a ban action that can actually block the traffic path. With a relay or reverse proxy in front of Vaultwarden, the observed address may be a relay or proxy address instead of the user. A mistaken filter can ban infrastructure, ban nothing useful, or create a false sense of protection.

The previous configuration also granted a floating third-party container NET_ADMIN and NET_RAW capabilities. Those privileges materially increase its impact if compromised. This revision removes that configuration. Do not deploy Fail2Ban for this architecture until you have verified real client-IP propagation end to end, documented which proxy addresses are trusted, tested the exact Vaultwarden log format, pinned and reviewed the filtering software, and proved that a test ban blocks only the intended client.

Connect and test Bitwarden clients

Install an official Bitwarden client from its normal distribution channel. Before logging in, select the client's self-hosted server option and enter the exact Localtonet HTTPS URL. Labels and menu placement can change between browser, desktop, iOS, and Android releases, so use the current self-hosted server field rather than relying on a fixed sequence of UI labels.

If a newly updated client behaves differently, check Vaultwarden's current compatibility discussions before changing security settings. “Compatible with official clients” does not guarantee that every new official feature is available immediately.

Verify the complete deployment

A successful container start is only the first check. Complete the following acceptance tests before importing real credentials or depending on the service.

Raspberry Pi deployment and safe external storage

Vaultwarden publishes container images intended for self-hosted use, but support for a particular Raspberry Pi depends on the current image architecture, the installed 64-bit operating system, Docker support, and available storage. Check the host architecture before pulling the image:

uname -m
docker info --format '{{.Architecture}}'
lsblk -f

An ARM64 system commonly reports aarch64. Do not rely on old memory figures or assume that every Pi model and operating-system combination is supported. Verify the current Vaultwarden image tags and Docker platform support for your hardware.

Move existing data to an external drive safely

Never assume the external disk is /dev/sda1, never assume its filesystem is ext4, and never edit /etc/fstab before validating the correct filesystem and UUID. Changing the Compose mount without copying existing data can make an established vault appear empty because Vaultwarden starts against a new blank directory.

lsblk -f
sudo blkid
findmnt

cd "$HOME/vaultwarden"
docker compose down

sudo mkdir -p /mnt/vault-storage
sudo mount /dev/verified-partition /mnt/vault-storage
findmnt /mnt/vault-storage
df -h /mnt/vault-storage

sudo mkdir -p /mnt/vault-storage/vw-data
sudo rsync -aHAX --numeric-ids "$HOME/vaultwarden/vw-data/" /mnt/vault-storage/vw-data/
sudo rsync -aHAXn --delete --numeric-ids "$HOME/vaultwarden/vw-data/" /mnt/vault-storage/vw-data/

sudo cp /etc/fstab /etc/fstab.pre-vaultwarden
sudoedit /etc/fstab
sudo umount /mnt/vault-storage
sudo mount -a
findmnt /mnt/vault-storage

volumes:
  - /mnt/vault-storage/vw-data:/data

docker compose up -d
docker compose ps
docker compose logs --tail=100 vaultwarden

Back up and restore Vaultwarden correctly

Backups must cover more than db.sqlite3. A recoverable Vaultwarden set includes a consistent SQLite snapshot, attachments, Sends, signing keys, persisted configuration, and the secrets needed to reconstruct the deployment. The environment file, SMTP credentials, device tokens, and backup keys are sensitive and should not be copied into an unencrypted backup directory.

Install the backup prerequisites

The host needs the sqlite3 command-line client and rsync. Install those packages from your operating system's signed package repository. Verify them before scheduling a backup:

sqlite3 --version
rsync --version

Create a consistent backup set

The SQLite .backup command creates a consistent database snapshot while Vaultwarden is running. The other directories can still change during a live copy, so schedule backups during a quiet period. For the strongest cross-file consistency, stop Vaultwarden briefly before copying attachments, Sends, keys, and configuration, or use a storage snapshot mechanism whose consistency you have tested.

#!/bin/sh
set -eu
umask 077

PROJECT="$HOME/vaultwarden"
DATA="$PROJECT/vw-data"
ROOT="$HOME/vaultwarden-backups"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
DEST="$ROOT/$STAMP"

command -v sqlite3 >/dev/null
command -v rsync >/dev/null

mkdir -p "$DEST"

sqlite3 "$DATA/db.sqlite3" ".timeout 10000" ".backup '$DEST/db.sqlite3'"

for directory in attachments sends; do
  if [ -d "$DATA/$directory" ]; then
    rsync -aH --numeric-ids "$DATA/$directory/" "$DEST/$directory/"
  fi
done

if [ -f "$DATA/config.json" ]; then
  cp -p "$DATA/config.json" "$DEST/config.json"
fi

for key in "$DATA"/rsa_key*; do
  if [ -e "$key" ]; then
    cp -p "$key" "$DEST/"
  fi
done

sqlite3 "$DEST/db.sqlite3" "PRAGMA integrity_check;"
find "$DEST" -maxdepth 2 -type f -print
echo "Backup staging set created at: $DEST"

The integrity check must report ok. Save this script outside the public service path, make it executable only by its owner, and run it manually before scheduling it.

Back up .env, compose.yaml, Localtonet recovery information, and any SMTP configuration only inside the encrypted archive or secret-management system. Do not mix unencrypted secret copies into the ordinary backup staging directory. Define retention based on your recovery objectives, available storage, and need to recover from delayed corruption or accidental deletion.

Restore into an isolated test location

A backup is not proven until it has been restored. The safest recurring test uses an isolated host or a separate project directory and port. Never point a test container at the production data directory.

sqlite3 /protected/restore-source/db.sqlite3 "PRAGMA integrity_check;"

cd "$HOME/vaultwarden"
docker compose down
mv vw-data "vw-data.before-restore.$(date -u +%Y%m%dT%H%M%SZ)"
mkdir vw-data
chmod 700 vw-data

cp -p /protected/restore-source/db.sqlite3 "$HOME/vaultwarden/vw-data/"
rsync -aH --numeric-ids /protected/restore-source/attachments/ "$HOME/vaultwarden/vw-data/attachments/"
rsync -aH --numeric-ids /protected/restore-source/sends/ "$HOME/vaultwarden/vw-data/sends/"
cp -p /protected/restore-source/config.json "$HOME/vaultwarden/vw-data/"
cp -p /protected/restore-source/rsa_key* "$HOME/vaultwarden/vw-data/"

ls -la "$HOME/vaultwarden/vw-data"
find "$HOME/vaultwarden/vw-data" -maxdepth 2 -printf '%M %u:%g %p\n'

docker compose up -d
docker compose ps
docker compose logs --tail=200 vaultwarden

Migrate an existing Bitwarden vault carefully

Review the current export choices in the Bitwarden client before creating a migration file. Encrypted JSON exports can use different protection models. A password-protected encrypted export is designed to be unlocked with the export password and is the appropriate encrypted form when portability is required. An account-restricted encrypted export is tied to the originating account and is not interchangeable with a portable password-protected export.

If the target importer does not support the selected encrypted format, a plaintext export may be required. Perform that operation only on a trusted, patched device, keep the file on encrypted storage, disconnect unnecessary synchronization or backup software, import it promptly, and securely remove temporary copies afterward. Confirm the import before deleting the source account.

Vault exports may not include every service object. Attachments and Sends require separate handling, and organization data can have its own export and import rules. Compare item counts and manually verify representative logins, secure notes, identities, cards, custom fields, organization collections, attachments, and two-factor records. There is no reliable universal migration-duration estimate.

Routine operation, updates, and rollback planning

Daily and weekly checks

• Confirm the Vaultwarden container is running and review new startup or authentication warnings.
• Confirm the Localtonet device is connected and the tunnel is started.
• Test the public URL and certificate before certificate expiry becomes urgent.
• Confirm scheduled backups completed, were encrypted, and reached the off-host destination.
• Monitor disk capacity for the data directory, Docker storage, logs, attachments, and backup staging.
• Review account enrollment, administration access, and whether public registration remains closed.

Review updates before applying them

A moving image tag changes when pulled. Before an update, read Vaultwarden release notes, check client-compatibility reports relevant to your environment, create and verify a fresh backup, and record the current image identifier:

cd "$HOME/vaultwarden"
docker compose images
docker image inspect vaultwarden/server:latest --format '{{index .RepoDigests 0}}'
docker compose logs --tail=100 vaultwarden

During a maintenance window, pull the reviewed image, recreate the service, and inspect logs:

docker compose pull vaultwarden
docker compose up -d vaultwarden
docker compose ps
docker compose logs --tail=200 vaultwarden

Then repeat certificate, login, synchronization, registration, and attachment tests. Do not automate unattended pulls for a password manager unless your organization has a tested update, monitoring, and rollback process.

Plan rollback before updating

Retain the previous image reference and the pre-update backup. Database migrations can make a simple image downgrade unsafe. If the new release changes the database in an incompatible way, rollback may require stopping the service, restoring the complete pre-update data set and required secrets, and starting the previously tested image. Document that process before the maintenance window.

Understand outage behavior

Evidence-based troubleshooting

Frequently asked questions