* Update GHA and pre-commit Signed-off-by: BlackDex <black.dex@gmail.com> * Update admin diagnostics Added a check if the templates are overridden and return which specific folder, `admin`, `email` or `scss`. This way we could more quickly point users to possible outdated templates which they are using. Also updated the Support String to use some emojis so we should be able to quicker see if there is something wrong. Just checking `true` or `false` could be difficult sometimes, and sometimes what we had as `false` wasn't bad either. Also adjusted the eslint comments so it will work with the latest version of eslint. Signed-off-by: BlackDex <black.dex@gmail.com> * Fix updating collections for a cipher The newer clients expect a `cipherDetails` response on the `collections-admin` endpoints. Without it, the client will cause an error and stops handling the update correctly. This will fix this by returning the cipher json. Fixes #7545 Fixes #7546 Signed-off-by: BlackDex <black.dex@gmail.com> * Cache CSS file in a different way Currently we set a cache ttl of 24 hours, and users need to do a force refresh if there is anything changed to the CSS file. In the past we have had several issue reported which were related to a still cached CSS file. This commit will change the caching and also cache the generated CSS file in memory. Instead of letting the browser cache it for 24 hours we generate an ETag, this is just a hash of the contents. This ETag is returned by the browser during a request, and we can match this, and if so, just return a `304` `Not Modified`. If the ETag is not known, we return the new content. This should make simple refreshes by clients get updated settings or a new version of Vaultwarden which has other CSS entries get updated instantly. If a user does a hard refresh, we will not receive the ETag and the content will be served. The same goes if someone has the `reload_templates` feature enabled, since then we should not cache anyway. If someone adjust settings via the `/admin` interface, the cache will be invalidated and a new CSS will be generated. Signed-off-by: BlackDex <black.dex@gmail.com> * Fix showing events for a specific user Signed-off-by: BlackDex <black.dex@gmail.com> * Update crates and adjust code. - Updated opendal and adjusted code where needed. - Updated yubico_ng and adjusted code where needed. This version now supports using an own HttpClient and it pulls in no reqwest dependency anymore. Now it will use our own client which uses custom hickory DNS and other features. Signed-off-by: BlackDex <black.dex@gmail.com> * Update web-vault to v2026.7.0 Signed-off-by: BlackDex <black.dex@gmail.com> * Fix hadolint warnings Signed-off-by: BlackDex <black.dex@gmail.com> --------- Signed-off-by: BlackDex <black.dex@gmail.com>
An alternative server implementation of the Bitwarden Client API, written in Rust and compatible with official Bitwarden clients [disclaimer], perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.
Important
When using this server, please report any bugs or suggestions directly to us (see Get in touch), regardless of whatever clients you are using (mobile, desktop, browser...). DO NOT use the official Bitwarden support channels.
Features
A nearly complete implementation of the Bitwarden Client API is provided, including:
- Personal Vault
- Send
- Attachments
- Website icons
- Personal API Key
- Organizations
- Multi/Two Factor Authentication
- Emergency Access
- Vaultwarden Admin Backend
- Modified Web Vault client (Bundled within our containers)
Usage
Important
The web-vault requires the use of HTTPS and a secure context for the Web Crypto API.
That means it will only work if you enable HTTPS.
We also suggest to use a reverse proxy.
The recommended way to install and use Vaultwarden is via our container images which are published to ghcr.io, docker.io and quay.io. See which container image to use for an explanation of the provided tags.
There are also community driven packages which can be used, but those might be lagging behind the latest version or might deviate in the way Vaultwarden is configured, as described in our Wiki.
Alternatively, you can also build Vaultwarden yourself.
While Vaultwarden is based upon the Rocket web framework which has built-in support for TLS our recommendation would be that you setup a reverse proxy (see proxy examples).
Tip
For more detailed examples on how to install, use and configure Vaultwarden you can check our Wiki.
Docker/Podman CLI
Pull the container image and mount a volume from the host for persistent storage.
You can replace docker with podman if you prefer to use podman.
docker pull vaultwarden/server:latest
docker run --detach --name vaultwarden \
--env DOMAIN="https://vw.domain.tld" \
--volume /vw-data/:/data/ \
--restart unless-stopped \
--publish 127.0.0.1:8000:80 \
vaultwarden/server:latest
This will preserve any persistent data under /vw-data/, you can adapt the path to whatever suits you.
Docker Compose
To use Docker compose you need to create a compose.yaml which will hold the configuration to run the Vaultwarden container.
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
environment:
DOMAIN: "https://vw.domain.tld"
volumes:
- ./vw-data/:/data/
ports:
- 127.0.0.1:8000:80
Get in touch
Have a question, suggestion or need help? Join our community on Matrix, GitHub Discussions or Discourse Forums.
Encountered a bug or crash? Please search our issue tracker and discussions to see if it's already been reported. If not, please start a new discussion or create a new issue. Ensure you're using the latest version of Vaultwarden and there aren't any similar issues open or closed!
Contributors
Thanks for your contribution to the project!
Disclaimer
This project is not associated with Bitwarden or Bitwarden, Inc.
However, one of the active maintainers for Vaultwarden is employed by Bitwarden and is allowed to contribute to the project on their own time. These contributions are independent of Bitwarden and are reviewed by other maintainers.
The maintainers work together to set the direction for the project, focusing on serving the self-hosting community, including individuals, families, and small organizations, while ensuring the project's sustainability.
Please note: We cannot be held liable for any data loss that may occur while using Vaultwarden. This includes passwords, attachments, and other information handled by the application. We highly recommend performing regular backups of your files and database. However, should you experience data loss, we encourage you to contact us immediately.
Bitwarden_RS
This project was known as Bitwarden_RS and has been renamed to separate itself from the official Bitwarden server in the hopes of avoiding confusion and trademark/branding issues.
Please see #1642 - v1.21.0 release and project rename to Vaultwarden for more explanation.