Vaultwarden 1.37.4 on AWS User Guide

Overview

This guide covers launching and using the Vaultwarden 1.37.4 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg identity, secrets and PKI listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Vaultwarden is a lightweight, open source server that implements the Bitwarden password manager API. The official Bitwarden clients (browser extensions, desktop apps, mobile apps and the command-line client) connect to it as a "self-hosted" server, and the bundled web vault gives you the same vault in a browser. Vaults are encrypted on the client: the server only stores encrypted data and never sees your master password.

The cloudimg image is a hardened, ready-to-use Vaultwarden server:

• nginx in front, Vaultwarden behind it. nginx is the only public listener (ports 80 and 443). Vaultwarden listens on 127.0.0.1:8000, the loopback address only. WebSocket notifications (live sync between your devices) run on the same HTTPS address.
• HTTPS from the first boot. nginx serves Vaultwarden with a certificate generated on your instance's first boot (an end-entity certificate, not a certificate authority), and port 80 redirects to HTTPS. The instance's name is set from its own EC2 public DNS name at first boot; you can change it to your own domain.
• Accounts are invite-only. Open registration is off (SIGNUPS_ALLOWED=false), organisation and emergency-access invitations of unknown addresses are off (INVITATIONS_ALLOWED=false), and nginx refuses the registration endpoints on the public address. Only the admin panel invites people, and every account is created through an SSH tunnel to the instance, so nobody on the internet can register an invited address before its owner. For someone who cannot use SSH you can open a short registration window that admits only that person's IP address and closes by itself.
• A per-instance admin token, stored as a hash. The admin panel (/admin) is protected by a random token generated on your instance's first boot. Vaultwarden only ever reads its Argon2id hash, from a file only the vaultwarden user can read; the token itself is in a root-only file for you. Admin sign-ins are rate limited per client address (3 attempts per 5 minutes).
• No default login, nothing shared. The admin token, the RSA key Vaultwarden signs login tokens with, and the TLS key are generated on the first boot of each instance. The image contains no database, no key and no certificate, and Vaultwarden and nginx refuse to start until first boot has created them.
• Real client addresses, fixed host name. nginx passes the real TCP peer to Vaultwarden (it overwrites X-Real-IP and X-Forwarded-For), so rate limits and logs cannot be fooled by forged headers. Vaultwarden is handed the configured name, never the name a client sends; requests for any other host name are dropped.
• Locked down serving. TLS 1.2 and 1.3 only; cross-site requests and WebSocket connections from other websites are refused (the Bitwarden apps and browser extensions are allowed); the website-icon fetcher refuses private, link-local and metadata addresses; nginx's access log records no query strings (they can carry login tokens); no mail server, push relay or single sign-on is configured until you add one; Vaultwarden, nginx and the first-boot service are blocked from the instance metadata service and the AMI requires IMDSv2.
• Your data on its own disk. The database, attachments, the icon cache and the keys live on a separate 20 GiB EBS volume mounted at /var/lib/vaultwarden.
• Built from source, verified, and fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on. See Step 15 for exactly how the binary is built.

What is on the image: Vaultwarden 1.37.4 (a cloudimg build of the upstream 1.37.4 tag, /usr/local/bin/vaultwarden), the official Vaultwarden web vault 2026.7.0 (/usr/share/vaultwarden/web-vault), nginx, Ubuntu 24.04 LTS, cloud-init and the AWS Systems Manager agent.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (or a private route your users and devices use).
• A security group that allows TCP 22 (SSH, also used for the account-creation tunnel) from your own networks only, and TCP 443 (the web vault, the apps and the admin panel) and TCP 80 (redirects to HTTPS) from the networks your users connect from. Do not open 8000: Vaultwarden listens on the loopback address only.
• For production, a DNS name you control (for example vault.example.com) and, ideally, a certificate from a certificate authority. Until then the instance uses its EC2 public DNS name with its own self-signed certificate.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Vaultwarden 1.37.4 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large, your key pair, and a security group as above. The AMI already carries the 20 GiB data volume; you can make it larger on the launch page.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --image-id <ami-id-from-the-listing> --instance-type m5.large \
  --key-name <your-key-pair> --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=vaultwarden}]'

First boot takes a few seconds after the instance is running. If you want the instance to use your own name from the start, put it in /etc/cloudimg/vaultwarden-domain with user data (for example a cloud-init write_files entry); otherwise first boot uses the instance's public DNS name, or its public IP address if it has no DNS name.

Step 2: Connect to your instance

Operating system	SSH user
Ubuntu 24.04	ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

systemctl is-active vaultwarden-firstboot vaultwarden nginx

active
active
active

Only SSH, HTTP and HTTPS are public. Vaultwarden listens on the loopback address:

sudo ss -tln | grep -E ':(22|80|443|8000) '

LISTEN 0      128        127.0.0.1:8000      0.0.0.0:*
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*
LISTEN 0      4096         0.0.0.0:22        0.0.0.0:*
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*
LISTEN 0      511             [::]:80           [::]:*
LISTEN 0      4096            [::]:22           [::]:*
LISTEN 0      511             [::]:443          [::]:*

Vaultwarden answers its health check through nginx, and reports its version and the web vault's:

curl -sk https://127.0.0.1/alive; echo
sudo bash -c 'set -a; . /etc/vaultwarden/vaultwarden.env; /usr/local/bin/vaultwarden --version'

"2026-10-29T02:27:54.375423Z"
Vaultwarden 1.37.4
Web-Vault 2026.7.0

Step 4: Get the admin token and the certificate fingerprint

sudo cat /root/vaultwarden-credentials.txt

The file (root only, mode 0600) gives the web vault and admin panel addresses, this instance's admin token (shown here as <redacted>) and the SHA-256 fingerprint of its certificate, followed by a short how-to:

# Vaultwarden 1.37.4 - generated on first boot by vaultwarden-firstboot.service. Unique to this instance. Store it safely.
vaultwarden.url=https://ec2-54-89-240-83.compute-1.amazonaws.com/
vaultwarden.admin_url=https://ec2-54-89-240-83.compute-1.amazonaws.com/admin
vaultwarden.admin_token=<redacted>
vaultwarden.tls.sha256_fingerprint=A9:64:22:B7:ED:88:BC:4D:2B:F0:11:ED:54:C1:66:6C:B7:A9:F1:60:2C:72:BD:3D:7E:BB:60:E5:55:67:5F:C7

Every instance gets its own token. Vaultwarden itself never holds it: it only has the token's Argon2id hash.

sudo grep -E '^(DOMAIN|SIGNUPS_ALLOWED|SIGNUPS_DOMAINS_WHITELIST|INVITATIONS_ALLOWED|ADMIN_TOKEN_FILE)=' /etc/vaultwarden/vaultwarden.env
sudo stat -c '%a %U %n' /var/lib/vaultwarden/secrets/admin-token.phc
sudo cut -c1-31 /var/lib/vaultwarden/secrets/admin-token.phc

DOMAIN=https://ec2-54-89-240-83.compute-1.amazonaws.com
SIGNUPS_ALLOWED=false
SIGNUPS_DOMAINS_WHITELIST=
INVITATIONS_ALLOWED=false
ADMIN_TOKEN_FILE=/var/lib/vaultwarden/secrets/admin-token.phc
600 vaultwarden /var/lib/vaultwarden/secrets/admin-token.phc
$argon2id$v=19$m=19456,t=2,p=1$

The certificate is self-signed and unique to your instance, so your browser warns about it. Open the certificate details in the browser, check that its SHA-256 fingerprint matches vaultwarden.tls.sha256_fingerprint, and only then continue. Do not add the certificate to your operating system's trust store; for production, replace it with a certificate from a certificate authority (Step 11). The Bitwarden mobile apps and browser extensions need a certificate they trust, so plan a real certificate before you roll the server out to people.

Step 5: Invite yourself in the admin panel

Browse to the vaultwarden.admin_url address and sign in with vaultwarden.admin_token:

Open Users, type your email address under Invite User and choose Invite. No mail server is configured, so nothing is sent: the invitation simply allows that one address to create an account. The user appears as Invited:

The admin session expires after 20 minutes. After three wrong tokens from one address, the panel refuses further sign-ins from that address for five minutes.

Step 6: Create your account through an SSH tunnel

Registration is closed on the public address, even for an invited address. If you try the Create account page at vaultwarden.url, the web vault shows an error, because nginx refuses the request (HTTP 403):

Create the first account through the instance's loopback listener instead, which only your SSH key can reach. On your workstation:

ssh -i <your-key.pem> -N -L 8443:127.0.0.1:443 ubuntu@<public-ip>

Leave it running, browse to https://localhost:8443/#/signup (the same certificate, so check the same fingerprint), enter the address you invited and your name, and choose Continue:

Set a strong master password and choose Create account. The web vault derives your encryption keys from it in the browser; the server never receives it, and nobody (including cloudimg and the admin panel) can recover it:

Accounts stay invite-only even on the tunnel: Vaultwarden itself refuses an address nobody invited. Use the same tunnel for every account you create, not only the first: with no mail server configured an invitation carries no secret, so the person who registers an invited address first chooses its master password.

Step 7: Sign in and use your vault

Close the tunnel and sign in at vaultwarden.url with your email address and master password:

The first time, the web vault offers the Bitwarden browser extension; choose Add it later and Skip to web app if you do not want it now. Choose New, then Login, and save an item:

To use the Bitwarden apps, choose Self-hosted (or the server settings icon) on their sign-in screen and enter vaultwarden.url as the server URL.

Step 8: Add more users

Invite each person in the admin panel (Step 5). The recommended way for them to create their account is the same SSH tunnel (Step 6): either they use it themselves, or you sit with them on a machine that has your key. Registration through the tunnel never needs the public address.

If someone cannot use SSH, open a short public registration window that admits only their IP address (ask them for their public address, for example from a "what is my IP" page), then tell them to sign up at vaultwarden.url:

sudo vaultwarden-signups open 30 --from <their-public-ip>

Public registration OPEN for 203.0.113.25/32 only, for 30 minutes (closes 2026-10-29T02:58:40Z). Invite users in /admin first.

--from is required and takes one IPv4 or IPv6 address or a network of at most a /16 (IPv4) or /48 (IPv6); a window for everyone is refused:

sudo vaultwarden-signups open 30 --from 0.0.0.0/0; echo "exit $?"

0.0.0.0/0 would open registration to everyone
vaultwarden-signups: ERROR: refused --from '0.0.0.0/0'
exit 1

nginx checks the address of the actual network connection, so a forwarded header cannot get round it. Only invited addresses can register even inside the window. The window closes by itself, at any nginx restart, or when you close it:

sudo vaultwarden-signups close
vaultwarden-signups status

Public registration CLOSED (registration through the SSH tunnel still works).
closed

People who already have an account can be added to organisations from the web vault as usual. To remove someone, use Delete User (or Disable User) in the admin panel; the panel asks you to type the user's email address to confirm, and the account can no longer sign in:

Step 9: Check the server from the command line

One command proves the whole chain on the instance: the web vault and health check answer over HTTPS, the admin token signs in (its session cookie is HttpOnly and SameSite=Strict) and a wrong token is refused, public registration is refused by nginx, and Vaultwarden refuses a registration for an address nobody invited:

sudo /usr/local/sbin/vaultwarden-cred-roundtrip.sh

VAULTWARDEN_ROUNDTRIP_OK alive=200 webvault=200 admin=200 users=200 wrong-token=401 public-register=403 uninvited-register=400

The configured name and every name the instance answers to:

vaultwarden-set-domain --show

domain:      ec2-54-89-240-83.compute-1.amazonaws.com
web vault:   https://ec2-54-89-240-83.compute-1.amazonaws.com/
admin panel: https://ec2-54-89-240-83.compute-1.amazonaws.com/admin
also served: ec2-54-89-240-83.compute-1.amazonaws.com 54.89.240.83 172.31.84.251
certificate: SHA-256 A9:64:22:B7:ED:88:BC:4D:2B:F0:11:ED:54:C1:66:6C:B7:A9:F1:60:2C:72:BD:3D:7E:BB:60:E5:55:67:5F:C7

Step 10: Check the security posture

The certificate is an end-entity certificate for the instance's name and addresses (plus localhost for the tunnel), which cannot sign other certificates:

openssl x509 -in /etc/ssl/vaultwarden/vaultwarden.crt -noout -subject -ext basicConstraints,keyUsage,extendedKeyUsage,subjectAltName

subject=CN = ec2-54-89-240-83.compute-1.amazonaws.com, O = cloudimg
X509v3 Subject Alternative Name: 
    DNS:ec2-54-89-240-83.compute-1.amazonaws.com, IP Address:54.89.240.83, IP Address:172.31.84.251, DNS:localhost, IP Address:127.0.0.1
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage: 
    TLS Web Server Authentication

TLS 1.0 and 1.1 are refused by the server, and a request for a host name the instance does not serve gets no answer:

echo | openssl s_client -tls1_1 -cipher 'DEFAULT@SECLEVEL=0' -connect 127.0.0.1:443 2>&1 | grep -o 'alert protocol version' | head -1
code=$(curl -sk -o /dev/null -w '%{http_code}' -H 'Host: evil.example' "https://$(hostname -I | awk '{print $1}')/alive" || true); echo "$code"; [ "$code" = 000 ]

alert protocol version
000

nginx passes the real client address to Vaultwarden and never a client-supplied one:

grep -E 'proxy_set_header +X-(Real-IP|Forwarded-For)' /etc/nginx/sites-available/vaultwarden | sort -u

        proxy_set_header X-Forwarded-For    $remote_addr;
        proxy_set_header X-Real-IP          $remote_addr;

The services are blocked from the instance metadata service. The first command shows the systemd rule on each service; the second makes a metadata request from inside Vaultwarden's own service, as its user, and gets no connection (000):

systemctl show -p IPAddressDeny vaultwarden nginx vaultwarden-firstboot
sudo bash -c 'cg=$(systemctl show -p ControlGroup --value vaultwarden.service); echo $$ > /sys/fs/cgroup$cg/cgroup.procs; setpriv --reuid=vaultwarden --regid=vaultwarden --init-groups curl -s -m 5 -o /dev/null -w "imds from vaultwarden: %{http_code}\n" -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 60" http://169.254.169.254/latest/api/token; true' | grep -x 'imds from vaultwarden: 000'

IPAddressDeny=fd00:ec2::254/128 ::ffff:169.254.169.254/128 169.254.169.254/32 168.63.129.16/32

IPAddressDeny=fd00:ec2::254/128 ::ffff:169.254.169.254/128 169.254.169.254/32 168.63.129.16/32

IPAddressDeny=fd00:ec2::254/128 ::ffff:169.254.169.254/128 169.254.169.254/32 168.63.129.16/32
imds from vaultwarden: 000

Vaultwarden fetches website icons for the vault on request, so it also refuses to fetch from any private, link-local or metadata address itself, even through a name that resolves to one:

S=$(date '+%Y-%m-%d %H:%M:%S'); curl -sk -o /dev/null https://127.0.0.1/icons/169.254.169.254.nip.io/icon.png; sleep 1
sudo journalctl -u vaultwarden --since "$S" --no-pager -o cat | grep -o "IP 169.254.169.254 for domain .* is not a global IP!"

IP 169.254.169.254 for domain '169.254.169.254.nip.io' is not a global IP!

SSH accepts keys only:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|x11forwarding|permitemptypasswords) '

permitrootlogin no
passwordauthentication no
kbdinteractiveauthentication no
x11forwarding no
permitemptypasswords no

Step 11: Use your own domain and certificate

Point a DNS record (for example vault.example.com) at the instance's public or Elastic IP address, then:

sudo vaultwarden-set-domain vault.example.com

This sets DOMAIN=https://vault.example.com, pins nginx to that name (the instance's own addresses keep working), issues a new self-signed certificate for it when the current one is cloudimg's, and restarts Vaultwarden. To use a certificate from a certificate authority, put the certificate chain in /etc/ssl/vaultwarden/vaultwarden.crt and its key in /etc/ssl/vaultwarden/vaultwarden.key (owner root, key mode 0600) and run sudo systemctl reload nginx; vaultwarden-set-domain never replaces a certificate that is not cloudimg's. With a trusted certificate you can also add an HSTS header in /etc/nginx/sites-available/vaultwarden (it is re-rendered by vaultwarden-set-domain, so keep a copy of local changes).

Step 12: Admin token, mail and two-step login

• New admin token: sudo vaultwarden-admin-token rotate generates a new token, stores only its hash for Vaultwarden, updates /root/vaultwarden-credentials.txt and restarts Vaultwarden. Admin sessions that are already open stay valid until they expire (at most 20 minutes).
• Mail: without a mail server, Vaultwarden cannot send invitations, verification emails or email two-step codes. To add one, set the SMTP settings in the admin panel (Settings, SMTP Email Settings). Settings saved in the admin panel are stored in /var/lib/vaultwarden/data/config.json and override /etc/vaultwarden/vaultwarden.env. Keep Allow new signups off: with mail configured, invitations are sent as email links.
• Two-step login: every user can turn on an authenticator app, a security key (WebAuthn, which needs your own domain name and a trusted certificate) or other methods under Settings, Security, Two-step login in the web vault. We recommend it for everyone.

Step 13: Your data and backups

Everything Vaultwarden keeps is on the data volume at /var/lib/vaultwarden:

sudo ls -l /var/lib/vaultwarden /var/lib/vaultwarden/data /var/lib/vaultwarden/secrets
df -h /var/lib/vaultwarden | tail -1

/var/lib/vaultwarden:
total 24
drwx------ 4 vaultwarden vaultwarden  4096 Oct 29 02:28 data
drwx------ 2 root        root        16384 Oct 29 01:41 lost+found
drwx------ 2 vaultwarden vaultwarden  4096 Oct 29 02:23 secrets

/var/lib/vaultwarden/data:
total 484
-rw------- 1 vaultwarden vaultwarden 278528 Oct 29 02:23 db.sqlite3
-rw------- 1 vaultwarden vaultwarden  32768 Oct 29 02:27 db.sqlite3-shm
-rw------- 1 vaultwarden vaultwarden 168952 Oct 29 02:27 db.sqlite3-wal
drwx------ 2 vaultwarden vaultwarden   4096 Oct 29 02:28 icon_cache
-rw------- 1 vaultwarden vaultwarden   1679 Oct 29 02:23 rsa_key.pem
drwx------ 2 vaultwarden vaultwarden   4096 Oct 29 02:23 tmp

/var/lib/vaultwarden/secrets:
total 4
-rw------- 1 vaultwarden vaultwarden 119 Oct 29 02:23 admin-token.phc
/dev/nvme1n1     20G  520K   19G   1% /var/lib/vaultwarden

• data/db.sqlite3 (with its -wal and -shm files): users, organisations and the encrypted vaults. Attachments and Send files appear under data/ when you use them.
• data/rsa_key.pem: signs login tokens. Keep it with the database; a new key signs every device out.
• secrets/admin-token.phc: the admin token's hash.

Back the volume up with EBS snapshots (AWS Backup or Data Lifecycle Manager), use Backup Database in the admin panel, or copy the folders while Vaultwarden is stopped:

sudo systemctl stop vaultwarden && sudo tar -C /var/lib/vaultwarden -czf /root/vaultwarden-backup-$(date +%F).tar.gz data secrets && sudo systemctl start vaultwarden
sudo tar -tzf /root/vaultwarden-backup-$(date +%F).tar.gz | head -20

data/
data/tmp/
data/db.sqlite3-shm
data/icon_cache/
data/db.sqlite3
data/rsa_key.pem
data/db.sqlite3-wal
secrets/
secrets/admin-token.phc

To restore, stop Vaultwarden, extract the archive into /var/lib/vaultwarden (owner vaultwarden, folders mode 0700) and start it again. The vault data is encrypted with your users' master passwords, but treat backups as secrets anyway.

Step 14: Server components

Component	Where
Vaultwarden 1.37.4	/usr/local/bin/vaultwarden, unit vaultwarden.service, user vaultwarden, 127.0.0.1:8000
Web vault 2026.7.0	/usr/share/vaultwarden/web-vault (read-only, owner root)
Configuration	/etc/vaultwarden/vaultwarden.env (0600, no secrets: the admin token hash is read from ADMIN_TOKEN_FILE)
Data	/var/lib/vaultwarden (own EBS volume)
nginx site	/etc/nginx/sites-available/vaultwarden, host and Origin rules /etc/nginx/cloudimg/, certificate /etc/ssl/vaultwarden/
Helpers	vaultwarden-set-domain, vaultwarden-signups, vaultwarden-admin-token, vaultwarden-cred-roundtrip.sh in /usr/local/sbin
First boot	vaultwarden-firstboot.service, /usr/local/sbin/vaultwarden-firstboot.sh
Licences, build record	/usr/share/doc/cloudimg-vaultwarden/
Logs	journalctl -u vaultwarden, /var/log/nginx/

Ubuntu packages update automatically through unattended upgrades. To move to a later Vaultwarden release, back up the data volume first, replace /usr/local/bin/vaultwarden with a build of the new release (owner root, mode 0755) and the web vault folder with the matching bw_web_builds release, read the release notes, and restart Vaultwarden; it migrates the database on start. A newer cloudimg version of this image is the simplest route: launch it, restore your backup, and switch DNS.

Step 15: Licences and source

Vaultwarden is licensed under the GNU Affero General Public License v3.0 only and the web vault under the GNU General Public License v3.0. The image carries both licences, the build record and the exact dependency lock file in /usr/share/doc/cloudimg-vaultwarden/:

ls /usr/share/doc/cloudimg-vaultwarden/
head -3 /usr/share/doc/cloudimg-vaultwarden/BUILD-INFO

BUILD-INFO
Cargo.lock
LICENSE-vaultwarden-AGPL-3.0.txt
LICENSE-web-vault-GPL-3.0.txt
SOURCE.txt
rust-dependencies.txt
Vaultwarden 1.37.4 - cloudimg build of the pinned upstream tag (no source patch)
source:      https://github.com/dani-garcia/vaultwarden.git tag 1.37.4 commit 7c188967e7a467b19b2757bc3326f9cf3ccae327 (AGPL-3.0-only)
toolchain:   rustc 1.99.1 (58cf8f9c3 2026-10-13) (rustup 1.29.2, profile minimal; the tag pins 1.99.0)

• Server source: github.com/dani-garcia/vaultwarden at tag 1.37.4, built unmodified with cargo build --release --locked --features sqlite and Rust 1.99.1. The only difference from the upstream tree is Cargo.lock: eight dependencies are raised to newer releases of the same versions (ctutils 0.4.6, rustls 0.23.46, rustls-webpki 0.103.16, tokio 1.53.3, webpki-root-certs 1.0.11, zstd 0.14.3, zstd-safe 8.2.0, zstd-sys 2.1.2) to clear published security advisories. The shipped lock file is in /usr/share/doc/cloudimg-vaultwarden/Cargo.lock.
• Web vault source: github.com/dani-garcia/bw_web_builds at v2026.7.0; the image ships the official v2026.7.0 release byte for byte.

Step 16: Security notes

• Keep port 22 open to your own networks only, and never open 8000. Consider limiting 443 to the networks your users connect from.
• Keep Allow new signups off in the admin panel and use invitations. Create accounts through the SSH tunnel; open a registration window (Step 8) only for one person's address, and only while you expect them to sign up.
• Store the admin token somewhere safe and rotate it (Step 12) after sharing it. If you prefer, restrict /admin to the SSH tunnel by adding an allow/deny rule for location /admin in the nginx site.
• Use a certificate from a certificate authority and your own domain for production; the Bitwarden mobile apps and browser extensions need a certificate their device trusts.
• Known residual advisories (reviewed for this release):
• rsa 0.9.10 (RUSTSEC-2023-0071, "Marvin", Medium, no fixed release anywhere): Vaultwarden uses it to sign its own login tokens with RSA-PKCS#1 v1.5; there is no RSA decryption path. Exploiting a timing side channel would need large numbers of authenticated sign-ins and precise network timing.
• rustls 0.21 and rustls-webpki 0.101 (RUSTSEC-2026-0346, -0349, -0098, -0099, -0104, -0382): only inside Rocket's built-in TLS server, which this image does not use (nginx terminates TLS; Rocket serves plain HTTP on the loopback address). Not reachable.
• crypto-bigint 0.5 (RUSTSEC-2026-0387): only on elliptic-curve token paths; Vaultwarden accepts RS256 tokens only and single sign-on is off. Not reachable.
• Web vault 2026.7.0: the Angular 21.2.17 advisories that are rated High apply to server-side rendering or to compile-time translation files, neither of which the browser-only web vault uses; Medium-rated Angular (CVE-2026-88057) and qs advisories remain in the client bundle. node-forge (CVE-2026-85393, signature verification) is in the bundle but the web vault never verifies RSA signatures with it.

Support

cloudimg provides 24/7 technical support for this image by email and live chat: support@cloudimg.co.uk. Vaultwarden and Bitwarden are trademarks of their respective owners; cloudimg is not affiliated with or endorsed by them. Vaultwarden is an unofficial Bitwarden-compatible server: report server issues to cloudimg or the Vaultwarden project, not to Bitwarden.