![\"Mascote](\"\/wp-content\/uploads\/2026\/10\/vaultwarden-v5.webp\")
<\/p>\n<\/p>\n
The Vaultwarden<\/a> is a server compatible with official Bitwarden clients<\/strong>, written in Rust. It fits on a Raspberry Pi, uses very little memory, and delivers in self-host features that the official Bitwarden only offers on a paid plan, such as the integrated TOTP authenticator and emergency access. It is not Bitwarden Inc.: it's the community project (formerlybitwarden_rs<\/em>), under AGPL-3.0 license, now at 1.37.3<\/strong>.<\/p>\n <\/p>\n If you already have a Linux box on the internet and don't want to send your vault to anyone's cloud, this is the short path: one container, HTTPS in front, and the official apps pointed at your domain.<\/p>\n The apps (Android, iOS, desktop, browser extension, CLI) speak the Bitwarden API, and Vaultwarden implements that API. The vault stays encrypted on the client<\/strong> (zero-knowledge): items arrive at the server already encrypted with a key derived from your master password, and the server cannot read them.<\/p>\n Keep an eye on versions, because the official clients evolve fast: 1.37.0 is required for clients 2026.7.0 and later, and 1.37.2 for 2026.8.0 and later. 1.37.0, from July 2026, also fixed a bundle of security flaws (SSRF on the icons endpoint, cross-organization item access, unauthenticated WebSocket flooding, among others), and 1.37.3 started revoking 2FA \u201cremember this device\u201d tokens when the password or 2FA change. Since 1.35.0 (December 2025), single sign-on (SSO) via OpenID Connect is native, enabled with The recommended path from upstream is the container. HTTPS is required: the web vault uses the Web Crypto API, which the browser only allows in a secure context. The Caddy<\/a> obtains and renews the certificate on its own. (If Docker is still new to you, there's the Docker course<\/a>.)<\/p>\n Generate the admin panel token (Argon2) before<\/em> from compose. The command asks for the password twice and prints the hash:<\/p>\n Paste the string The Anyone who already has nginx (ISPConfig, for example) can skip the Caddy service: publish Vaultwarden only on Open Subsequent invitations come from the Enable 2FA on the vault (TOTP or FIDO2) on the first day. It is the same Bitwarden app; the only difference is the server.<\/p>\n In any Bitwarden app, on the login screen: Self-hosted<\/strong> \u2192 paste Do not report Vaultwarden bugs to Bitwarden Inc. support. The README is explicit: issues and discussions go to the project's GitHub and Matrix.<\/p>\n The volume A daily script that generates this copy, packages the volume without the \u201clive\u201d database, and cleans up the temporary files:<\/p>\n To restore, extract the package into an Change the image tag in Pinning the version (instead of A Rust binary, a volume and HTTPS. The vault stays on hardware you control \u2014 and the app in your pocket stays the same.<\/p>","protected":false},"excerpt":{"rendered":" Vaultwarden is a server compatible with the official Bitwarden clients, written in Rust. Updated guide for 1.37.3: Docker Compose with Caddy, stuck registration, native SSO, backup with the built-in command, and safe update.<\/p>","protected":false},"author":0,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[33,2,120],"tags":[155,156,158,157,154],"class_list":["post-405","post","type-post","status-publish","format-standard","hentry","category-howtos","category-linux","category-servidores","tag-bitwarden","tag-docker","tag-rust","tag-senhas","tag-vaultwarden"],"_links":{"self":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/405","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/comments?post=405"}],"version-history":[{"count":5,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/405\/revisions"}],"predecessor-version":[{"id":1799,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/405\/revisions\/1799"}],"wp:attachment":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/media?parent=405"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/categories?post=405"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/tags?post=405"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}What it is (and isn't)<\/h2>\n
\n
SSO_ENABLED<\/code>. SCIM and Secrets Manager remain exclusive to official Bitwarden.<\/p>\nDeploy with Docker and Caddy<\/h2>\n
![\"Diagrama:](\"\/wp-content\/uploads\/2026\/10\/vaultwarden-docker-compose-caddy.webp\")
docker run --rm -it vaultwarden\/server:1.37.3 \/vaultwarden hash\n<\/code><\/pre>\n$argon2id$...<\/code> in the YAML. In Compose, each $<\/code> becomes $$<\/code>.<\/p>\nmkdir -p \/opt\/vaultwarden && cd \/opt\/vaultwarden\n<\/code><\/pre>\n# \/opt\/vaultwarden\/compose.yaml\nservices:\n vaultwarden:\n image: vaultwarden\/server:1.37.3\n container_name: vaultwarden\n restart: unless-stopped\n environment:\n DOMAIN: \"https:\/\/vault.exemplo.com.br\"\n SIGNUPS_ALLOWED: \"true\"\n ADMIN_TOKEN: \"$$argon2id$$v=19$$m=65540,t=3,p=4$$COLE_O_HASH\"\n volumes:\n - .\/vw-data:\/data\n\n caddy:\n image: caddy:2\n container_name: vw-caddy\n restart: unless-stopped\n ports:\n - \"80:80\"\n - \"443:443\"\n - \"443:443\/udp\"\n volumes:\n - .\/Caddyfile:\/etc\/caddy\/Caddyfile:ro\n - caddy_data:\/data\n - caddy_config:\/config\n depends_on:\n - vaultwarden\n\nvolumes:\n caddy_data:\n caddy_config:\n<\/code><\/pre>\n# \/opt\/vaultwarden\/Caddyfile\nvault.exemplo.com.br {\n\tencode zstd gzip\n\treverse_proxy vaultwarden:80\n}\n<\/code><\/pre>\n# DNS do dom\u00ednio \u2192 IP desta m\u00e1quina, depois:\ndocker compose up -d\ndocker compose logs -f\ncurl -s https:\/\/vault.exemplo.com.br\/alive<\/code><\/pre>\n\/alive<\/code> responds with the server date and time when everything is up. Don't forget the volume .\/vw-data:\/data<\/code>: without a persistent volume, the current Vaultwarden refuses to start and shows No persistent volume!<\/em> in the log. It's a safeguard so you don't lose the vault when recreating the container.<\/p>\n127.0.0.1:8000<\/code> and proxy with Let's Encrypt in nginx. The WebSocket uses the same port 80 of the container; the old port 3012 is no longer needed.<\/p>\nFirst login and disabling registration<\/h2>\n
https:\/\/vault.exemplo.com.br<\/code> and create your<\/strong> account. Then close the door:<\/p>\nSIGNUPS_ALLOWED: \"false\"\n<\/code><\/pre>\ndocker compose up -d\n<\/code><\/pre>\n\/admin<\/code>, with the token you generated. Without ADMIN_TOKEN<\/code>, the panel doesn't even exist \u2014 and that's how it should be if you don't plan to use it. If you use SSO, the 1.37.3 brought the SSO_SIGNUPS_ALLOWED<\/code> to separately control the registration through this path.<\/p>\nPointing official clients at it<\/h2>\n
https:\/\/vault.exemplo.com.br<\/code>. Log in with the email of the account you created. Browser extension, phone and CLI (bw config server<\/code>) use the same URL.<\/p>\nBackup \u2014 without one, there's no vault<\/h2>\n
.\/vw-data<\/code> is the vault: db.sqlite3<\/code>, rsa_key.pem<\/code> (signs the login tokens), attachments, Sends, and the config.json<\/code> from the admin panel. Copying the SQLite file with the service running can generate an inconsistent copy; the binary itself has a command that makes a safe copy of the database, without stopping anything:<\/p>\ndocker compose exec vaultwarden \/vaultwarden backup\n# Backup to 'data\/db_20261005_170645.sqlite3' was successful<\/code><\/pre>\n#!\/bin\/sh\n# \/usr\/local\/sbin\/vw-backup\nset -eu\ncd \/opt\/vaultwarden\ndocker compose exec -T vaultwarden \/vaultwarden backup\ntar -czf \"\/backup\/vw-$(date +%F).tar.gz\" -C vw-data \\\n --exclude='db.sqlite3*' --exclude='icon_cache' .\nrm -f vw-data\/db_*.sqlite3<\/code><\/pre>\nvw-data<\/code> empty, rename the `backup-db.sqlite3`, and db_AAAAMMDD_HHMMSS.sqlite3<\/code> to db.sqlite3<\/code> and bring up the Compose. Keep the copy off<\/em> from the machine \u2014 another disk, another VPS, a bucket via rclone<\/a> \u2014 and test the restore at least once. The OnCalendar=<\/code> of the systemd<\/a> handles scheduling if you don't want cron.<\/p>\nUpgrading<\/h2>\n
compose.yaml<\/code> to the new version, take the backup and recreate the container:<\/p>\n\/usr\/local\/sbin\/vw-backup\ndocker compose pull\ndocker compose up -d\ndocker compose logs --tail=30 vaultwarden<\/code><\/pre>\nlatest<\/code>) keeps the update under your control and rollback simple: just go back to the tag. Read the release notes first, particularly when they mention compatibility with a new version of the clients.<\/p>\nReferences<\/h2>\n
\n