Vaultwarden 1.36.0: Upgrade Guide
Self-hosting means you are your own security team.
In the cloud, a company patches vulnerabilities before you notice them. With Vaultwarden, you own the risk. If you skip updates, you run known vulnerabilities.
Vaultwarden 1.36.0 fixes two critical areas: • Admin panel authentication. • Session token handling.
The admin panel is a common target. Many users run it on a public subdomain. If you do not block the /admin path at your proxy level, you are at risk.
Key Improvements in 1.36.0:
• Server-side rate limiting: The app now handles rate limiting internally. It no longer relies solely on your Nginx or Caddy config. This prevents attackers from bypassing limits using fake IP headers.
• Better session security: The server now checks token expiry on every API call. This prevents stolen tokens from working longer than they should.
• Updated dependencies: Fixes for OpenSSL and tower-http reduce the risk of denial-of-service attacks.
How to Upgrade Without Losing Data:
Back up your database properly. Do not just copy the files. Use the SQLite backup command inside the container to avoid corruption. Run: docker exec vaultwarden sqlite3 /data/db.sqlite3 '.backup /data/db_backup.sqlite3'
Verify the backup. Run an integrity check on the new file. If it does not say "ok," do not proceed.
Use the atomic upgrade method. Do not stop your container first. This causes downtime. Instead, pull the new image while the old one runs, then recreate the service. Run: docker compose pull vaultwarden docker compose up -d vaultwarden
Set your IP header. To ensure rate limiting works, tell Vaultwarden which header your proxy uses. Add this to your environment: IP_HEADER=X-Forwarded-For
Hardening your setup:
• Stop using plaintext ADMIN_TOKEN. Use an argon2 hash instead. • Restrict the /admin path to your local network via your reverse proxy. • Set SIGNUPS_ALLOWED to false if you are the only user.
An upgrade takes five minutes. Proper preparation takes ten. Do not skip the backup.