vaultwarden Documentation

Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs

65,127 stars Rust Rust 1 file · ~4,049 tokens #bitwarden#bitwarden-rs#docker#rocket#rust#vaultwarden
RAW Doc

Docker & Self-Hosted Deployment Verified OCI

Deploy vaultwarden on any server, homelab, or cloud container platform.

1-Click Terminal Command
bash (docker run) 
docker run -d --name vaultwarden -p 1080:1080 --restart always playwright_oidc_vaultwarden_prebuilt
Configured Services & Ports
⚙️ VaultwardenPrebuild
image: playwright_oidc_vaultwarden_prebuilt
⚙️ Vaultwarden
image: playwright_oidc_vaultwarden-${ENV:-dev}
⚙️ Playwright
image: playwright_oidc_playwright
⚙️ Mariadb
image: mariadb:12.2.2
🔌 Ports: ${MARIADB_PORT}:3306
⚙️ Mysql
image: mysql:9.7.0
🔌 Ports: ${MYSQL_PORT}:3306
⚙️ Postgres
image: postgres:18.4
🔌 Ports: ${POSTGRES_PORT}:5432
⚙️ Maildev
image: timshel/maildev:3.2.19
🔌 Ports: ${SMTP_PORT}:1025, 1080:1080
⚙️ Keycloak
image: quay.io/keycloak/keycloak:26.6.2
⚙️ KeycloakSetup
image: keycloak_setup-${ENV:-dev}
docker-compose.yml
yaml (docker-compose.yml) 
services:
  VaultwardenPrebuild:
    profiles: ["playwright", "vaultwarden"]
    container_name: playwright_oidc_vaultwarden_prebuilt
    image: playwright_oidc_vaultwarden_prebuilt
    build:
      context: ..
      dockerfile: Dockerfile
    entrypoint: /bin/bash
    restart: "no"

  Vaultwarden:
    profiles: ["playwright", "vaultwarden"]
    container_name: playwright_oidc_vaultwarden-${ENV:-dev}
    image: playwright_oidc_vaultwarden-${ENV:-dev}
    network_mode: "host"
    build:
      context: compose/warden
      dockerfile: Dockerfile
      args:
        REPO_URL: ${PW_VW_REPO_URL:-}
        COMMIT_HASH: ${PW_VW_COMMIT_HASH:-}
    env_file: ${DC_ENV_FILE:-.env}
    environment:
      - ADMIN_TOKEN
      - DATABASE_URL
      - CLIENT_SUPPRESS_ONBOARDING
      - EMAIL_2FA_AUTO_FALLBACK
      - I_REALLY_WANT_VOLATILE_STORAGE
      - LOG_LEVEL
      - LOGIN_RATELIMIT_MAX_BURST
      - SMTP_HOST
      - SMTP_FROM
      - SMTP_DEBUG
      - SSO_AUTH_ONLY_NOT_SESSION
      - SSO_DEBUG_TOKENS
      - SSO_ENABLED
      - SSO_FRONTEND
      - SSO_ONLY
      - SSO_SCOPES
    restart: "no"
    depends_on:
      - VaultwardenPrebuild

  Playwright:
    profiles: ["playwright"]
    container_name: playwright_oidc_playwright
    image: playwright_oidc_playwright
    network_mode: "host"
    build:
      context: .
      dockerfile: compose/playwright/Dockerfile
    environment:
      - PW_WV_REPO_URL
      - PW_WV_COMMIT_HASH
    restart: "no"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ..:/project

  Mariadb:
    profiles: ["playwright"]
    container_name: playwright_mariadb
    image: mariadb:12.2.2
    env_file: test.env
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      start_period: 10s
      interval: 10s
    ports:
      - ${MARIADB_PORT}:3306

  Mysql:
    profiles: ["playwright"]
    container_name: playwright_mysql
    image: mysql:9.7.0
    env_file: test.env
    healthcheck:
      test: ["CMD", "mysqladmin" ,"ping", "-h", "localhost"]
      start_period: 10s
      interval: 10s
    ports:
      - ${MYSQL_PORT}:3306

  Postgres:
    profiles: ["playwright"]
    container_name: playwright_postgres
    image: postgres:18.4
    env_file: test.env
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
      start_period: 20s
      interval: 30s
    ports:
      - ${POSTGRES_PORT}:5432

  Maildev:
    profiles: ["vaultwarden", "maildev"]
    container_name: maildev
    image: timshel/maildev:3.2.19
    ports:
      - ${SMTP_PORT}:1025
      - 1080:1080

  Keycloak:
    profiles: ["keycloak", "vaultwarden"]
    container_name: keycloak-${ENV:-dev}
    image: quay.io/keycloak/keycloak:26.6.2
    network_mode: "host"
    command:
      - start-dev
    env_file: ${DC_ENV_FILE:-.env}

  KeycloakSetup:
    profiles: ["keycloak", "vaultwarden"]
    container_name: keycloakSetup-${ENV:-dev}
    image: keycloak_setup-${ENV:-dev}
    network_mode: "host"
    build:
      context: compose/keycloak
      dockerfile: Dockerfile
      args:
        KEYCLOAK_VERSION: 26.6.2
    depends_on:
      - Keycloak
    restart: "no"
    env_file: ${DC_ENV_FILE:-.env}

File: README.md

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.











%3D'svg'%5D%2F*%5Blocal-name()%3D'g'%5D%5B2%5D%2F*%5Blocal-name()%3D'text'%5D%5B4%5D&style=flat-square&logo=rust&label=dependencies&color=005AA4)




[!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:

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.

shell
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.

yaml
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.

File: docker/README.md

Vaultwarden Container Building

To build and release new testing and stable releases of Vaultwarden we use docker buildx bake.
This can be used locally by running the command yourself, but it is also used by GitHub Actions.

This makes it easier for us to test and maintain the different architectures we provide.
We also just have two Dockerfile's one for Debian and one for Alpine based images.
With just these two files we can build both Debian and Alpine images for the following platforms:

  • amd64 (linux/amd64)
  • arm64 (linux/arm64)
  • armv7 (linux/arm/v7)
  • armv6 (linux/arm/v6)

Some unsupported platforms for Debian based images. These are not built and tested by default and are only provided to make it easier for users to build for these architectures.

  • 386 (linux/386)
  • ppc64le (linux/ppc64le)
  • s390x (linux/s390x)

To build these containers you need to enable QEMU binfmt support to be able to run/emulate architectures which are different then your host.
This ensures the container build process can run binaries from other architectures.

NOTE: Run all the examples below from the root of the repo.

How to install QEMU binfmt support

This is different per host OS, but most support this in some way.

Ubuntu/Debian

bash
apt install binfmt-support qemu-user-static

Arch Linux (others based upon it)

bash
pacman -S qemu-user-static qemu-user-static-binfmt

Fedora

bash
dnf install qemu-user-static

Others

There also is an option to use an other docker container to provide support for this.

bash
# To install and activate
docker run --privileged --rm tonistiigi/binfmt --install arm64,arm
# To uninstall
docker run --privileged --rm tonistiigi/binfmt --uninstall 'qemu-*'

Single architecture container building

You can build a container per supported architecture as long as you have QEMU binfmt support installed on your system.

bash
# Default bake triggers a Debian build using the hosts architecture
docker buildx bake --file docker/docker-bake.hcl

# Bake Debian ARM64 using a debug build
CARGO_PROFILE=dev \
SOURCE_COMMIT="$(git rev-parse HEAD)" \
docker buildx bake --file docker/docker-bake.hcl debian-arm64

# Bake Alpine ARMv6 as a release build
SOURCE_COMMIT="$(git rev-parse HEAD)" \
docker buildx bake --file docker/docker-bake.hcl alpine-armv6

Local Multi Architecture container building

Start the initialization, this only needs to be done once.

bash
# Create and use a new buildx builder instance which connects to the host network
docker buildx create --name vaultwarden --use --driver-opt network=host

# Validate it runs
docker buildx inspect --bootstrap

# Create a local container registry directly reachable on the localhost
docker run -d --name registry --network host registry:2

After that is done, you should be able to build and push to the local registry.
Use the following command with the modified variables to bake the Alpine images.
Replace alpine with debian if you want to build the debian multi arch images.

bash
# Start a buildx bake using a debug build
CARGO_PROFILE=dev \
SOURCE_COMMIT="$(git rev-parse HEAD)" \
CONTAINER_REGISTRIES="localhost:5000/vaultwarden/server" \
docker buildx bake --file docker/docker-bake.hcl alpine-multi

Using the `bake.sh` script

To make it a bit more easier to trigger a build, there also is a bake.sh script.
This script calls docker buildx bake with all the right parameters and also generates the SOURCE_COMMIT and SOURCE_VERSION variables.
This script can be called from both the repo root or within the docker directory.

So, if you want to build a Multi Arch Alpine container pushing to your localhost registry you can run this from within the docker directory. (Just make sure you executed the initialization steps above first)

bash
CONTAINER_REGISTRIES="localhost:5000/vaultwarden/server" \
./bake.sh alpine-multi

Or if you want to just build a Debian container from the repo root, you can run this.

bash
docker/bake.sh

You can append both alpine and debian with -amd64, -arm64, -armv7 or -armv6, which will trigger a build for that specific platform.
This will also append those values to the tag so you can see the built container when running docker images.

You can also append extra arguments after the target if you want. This can be useful for example to print what bake will use.

bash
docker/bake.sh alpine-all --print

Testing baked images

To test these images you can run these images by using the correct tag and provide the platform.
For example, after you have build an arm64 image via ./bake.sh debian-arm64 you can run:

bash
docker run --rm -it \
  -e DISABLE_ADMIN_TOKEN=true \
  -e I_REALLY_WANT_VOLATILE_STORAGE=true \
  -p8080:80 --platform=linux/arm64 \
  vaultwarden/server:testing-arm64

Using the `podman-bake.sh` script

To also make building easier using podman, there is a podman-bake.sh script.
This script calls podman buildx build with the needed parameters and the same as bake.sh, it will generate some variables automatically.
This script can be called from both the repo root or within the docker directory.

NOTE: Unlike the bake.sh script, this only supports a single CONTAINER_REGISTRIES, and a single BASE_TAGS value, no comma separated values. It also only supports building separate architectures, no Multi Arch containers.

To build an Alpine arm64 image with only sqlite support and mimalloc, run this:

bash
DB="sqlite,enable_mimalloc" \
./podman-bake.sh alpine-arm64

Or if you want to just build a Debian container from the repo root, you can run this.

bash
docker/podman-bake.sh

You can append extra arguments after the target if you want. This can be useful for example to disable cache like this.

bash
./podman-bake.sh alpine-arm64 --no-cache

For the podman builds you can, just like the bake.sh script, also append the architecture to build for that specific platform.

Testing podman built images

The command to start a podman built container is almost the same as for the docker/bake built containers. The images start with localhost/, so you need to prepend that.

bash
podman run --rm -it \
  -e DISABLE_ADMIN_TOKEN=true \
  -e I_REALLY_WANT_VOLATILE_STORAGE=true \
  -p8080:80 --platform=linux/arm64 \
  localhost/vaultwarden/server:testing-arm64

Variables supported

Variable default description
CARGO_PROFILE null Which cargo profile to use. null means what is defined in the Dockerfile
DB null Which features to build. null means what is defined in the Dockerfile
SOURCE_REPOSITORY_URL null The source repository form where this build is triggered
SOURCE_COMMIT null The commit hash of the current commit for this build
SOURCE_VERSION null The current exact tag of this commit, else the last tag and the first 8 chars of the source commit
BASE_TAGS testing Tags to be used. Can be a comma separated value like "latest,1.29.2"
CONTAINER_REGISTRIES vaultwarden/server Comma separated value of container registries. Like ghcr.io/dani-garcia/vaultwarden,docker.io/vaultwarden/server
VW_VERSION null To override the SOURCE_VERSION value. This is also used by the build.rs code for example

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

#bitwarden Browse bitwarden catalog → #bitwarden-rs Browse bitwarden-rs catalog → #docker Browse docker catalog → #rocket Browse rocket catalog → #rust Browse rust catalog → #vaultwarden Browse vaultwarden catalog → ⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →