Vaultwarden 1.37.4

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, select your Region, and choose Launch through EC2.

Choose m5.large, your key pair and a security group as described above. The AMI already carries the 20 GiB data volume, and you can make it larger on the launch page.

To launch with the AWS CLI instead, 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. To use your own name from the start, put it in /etc/sac/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.

Connect over SSH as the ubuntu user on Ubuntu 24.04, with the key pair you launched with.

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

systemctl is-active vaultwarden-firstboot vaultwarden nginx

active active active

Confirm that 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 [::]:*

Check that Vaultwarden answers its health check through nginx, and print its version and the web vault's version.

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

sudo cat /root/vaultwarden-credentials.txt

The file is root-only (mode 0600). It lists 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 never holds the token itself, only its Argon2id hash. Verify the settings and the hash file:

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 and check that its SHA-256 fingerprint matches vaultwarden.tls.sha256_fingerprint. 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.

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.

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, open a tunnel:

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

Leave the tunnel running and browse to https://localhost:8443/#/signup. It presents the same certificate, so check the same fingerprint. Enter the address you invited and your name, then choose Continue.

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

Accounts stay invite-only even on the tunnel, because 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.

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. If you do not want it now, choose Add it later and Skip to web app. Then 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. Enter vaultwarden.url as the server URL.

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. It takes one IPv4 or IPv6 address, or a network no larger than 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 around it. Even inside the window, only invited addresses can register. 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.

Run one command on the instance to check the whole chain. It confirms that:

• The web vault and health check answer over HTTPS.
• The admin token signs in, with a session cookie that is HttpOnly and SameSite=Strict, and a wrong token is refused.
• nginx refuses public registration.
• 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

Show 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

Inspect the certificate. It is an end-entity certificate for the instance's name and addresses, plus localhost for the tunnel, and it 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 = sac 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

The server refuses TLS 1.0 and 1.1, 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. It refuses to fetch from any private, link-local or metadata address, 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

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

sudo vaultwarden-set-domain vault.example.com

This command sets DOMAIN=https://vault.example.com and pins nginx to that name, while the instance's own addresses keep working. If the current certificate is SecureAnyCloud's, it issues a new self-signed certificate for the name. It then 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). Then run sudo systemctl reload nginx. vaultwarden-set-domain never replaces a certificate that is not SecureAnyCloud's.

With a trusted certificate you can also add an HSTS header in /etc/nginx/sites-available/vaultwarden. vaultwarden-set-domain re-renders that file, so keep a copy of local changes.

• 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, after 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 under 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, because with mail configured, invitations are sent as email links.
• Two-step login: every user can turn on an authenticator app, a security key or other methods in the web vault, under Settings, Security, Two-step login. A security key (WebAuthn) needs your own domain name and a trusted certificate. We recommend two-step login for everyone.

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, because a new key signs every device out.
• secrets/admin-token.phc: the admin token's hash.

Back up the volume with EBS snapshots (AWS Backup or Data Lifecycle Manager). Alternatively, 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.

• 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 in /etc/nginx/sites-available/vaultwarden, host and Origin rules in /etc/nginx/sac/, certificate in /etc/ssl/vaultwarden/
• Helpers: vaultwarden-set-domain, vaultwarden-signups, vaultwarden-admin-token and vaultwarden-cred-roundtrip.sh in /usr/local/sbin
• First boot: vaultwarden-firstboot.service, /usr/local/sbin/vaultwarden-firstboot.sh
• Licences and build record: /usr/share/doc/sac-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 replace the web vault folder with the matching bw_web_builds release. Read the release notes, then restart Vaultwarden. It migrates the database on start.

The simplest route is a newer SecureAnyCloud version of this image: launch it, restore your backup and switch DNS.

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/sac-vaultwarden/.

ls /usr/share/doc/sac-vaultwarden/ head -3 /usr/share/doc/sac-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 - sac 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/sac-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.

• 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. Optionally, restrict /admin to the SSH tunnel by adding an allow/deny rule for location /admin in the nginx site.
• For production, use a certificate from a certificate authority and your own domain. The Bitwarden mobile apps and browser extensions need a certificate that 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 only to sign its own login tokens with RSA-PKCS#1 v1.5, and 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): these exist only inside Rocket's built-in TLS server, which this image does not use. nginx terminates TLS, and Rocket serves plain HTTP on the loopback address. Not reachable.
• crypto-bigint 0.5 (RUSTSEC-2026-0387): used 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 High-rated Angular 21.2.17 advisories apply to server-side rendering or to compile-time translation files, and the browser-only web vault uses neither. 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.