Vaultwarden

#

Installing Vaultwarden

#

What is a password manager - briefly

#

A password manager is an app that securely stores your logins, passwords, notes, and other secrets in encrypted form and helps automatically fill in data when logging into sites/apps. Benefits: strong unique passwords for each service, random password generation, sync across devices, a centralized store for passwords and SSH keys, and a change history.

What is Vaultwarden

#

Vaultwarden is a lightweight, fast, Bitwarden-compatible server implementation (written in Rust) that implements the Bitwarden API and lets you use official Bitwarden clients (browser extensions, mobile/desktop apps) with your own server. Vaultwarden is designed for self-hosted deployment (containers, Docker Compose, Kubernetes, etc.).

Why self-hosted

#

Briefly - the key benefits of self-hosted Vaultwarden:

• Control over your data: the database and backups are under your control, and only yours, not in some third party’s cloud.
• Privacy: no metadata/backup copies are sent to external services. You, and only you, control your data.
• Flexibility and integration: you can connect LDAP/SMTP/an external DB, SSO via your own identity provider, set up backups, use your own TLS (reverse proxy), and so on.
• Savings and simplicity: Vaultwarden is lighter and cheaper on resources than the upstream Bitwarden Server.

Downsides/risks: you’re responsible for security yourself (updates, TLS, backups, firewall configuration, secret rotation). There’s one point here that some might find debatable, though. For some reason, people believe Bitwarden is more secure because it’s a commercial product. At first glance that sounds logical. But in reality, the cloud services of companies are always under attack, and sometimes they let one through. Bitwarden itself has had leaks more than once, and users of its cloud have often had their accounts hijacked. Strange as it may seem, you end up protecting your own Vaultwarden instance far more carefully. And that’s not even counting the fact that, no offense, you personally aren’t really an interesting target in the first place.

Short deployment plan (what we’ll do)

#

1. Start with a basic docker-compose.yml - a minimal working setup.
2. Cover the advanced configuration: secrets in .env, SSO via Authentik, push notifications, Rocket/logging tuning - the setup currently running for me.
3. Set up a reverse proxy and TLS.
4. Walk through the admin panel, user registration, and organizations.
5. Cover backups and common mistakes.

Basic installation

#

If you just need a working server without SSO and extra settings - this setup is enough. Further in the article there’s also an advanced version, but it’s easier to start with this one.

services:
  vaultwarden:  # Definition of the Vaultwarden service - the main password manager container.
    container_name: vaultwarden  # Container name in Docker - convenient for commands and logs.
    image: vaultwarden/server:latest  # Official Vaultwarden image from Docker Hub (written in Rust).
    restart: unless-stopped  # The container will automatically restart if it crashes, but not after a manual stop.

    volumes:
      - /path/to/bind/mount/:/data/  # Mount a local host directory into /data inside the container.
                                       # This is where the database, attachments, and Vaultwarden config are stored.

    environment:
      - SIGNUPS_ALLOWED=false        # Disallow new user registrations (false) - improves security.
      - ADMIN_TOKEN=replace_with_a_hashed_token  # See the hashing section below — don't store the token in plain text.
      - WEBSOCKET_ENABLED=true       # Enable WebSocket - Bitwarden clients get instant updates.
      - DOMAIN=https://vaultwarden.domain.ru  # Specify the domain — needed for correct links (password reset, TOTP, etc.)
      - TZ=Europe/Moscow             # Set the timezone — correct time in logs and notifications.

    networks:
      - proxy                        # Attach the container to Traefik's external network so the proxy can discover it.

    labels:
      - "traefik.enable=true"

      # --- HTTP → HTTPS redirect ---
      - "traefik.http.routers.vaultwarden.entrypoints=web"
      - "traefik.http.routers.vaultwarden.rule=Host(`vaultwarden.domain.ru`)"
      - "traefik.http.middlewares.vaultwarden-https-redirect.redirectscheme.scheme=https"
      - "traefik.http.routers.vaultwarden.middlewares=vaultwarden-https-redirect"

      # --- HTTPS (secure) ---
      - "traefik.http.routers.vaultwarden-secure.entrypoints=websecure"
      - "traefik.http.routers.vaultwarden-secure.rule=Host(`vaultwarden.domain.ru`)"
      - "traefik.http.routers.vaultwarden-secure.tls=true"
      - "traefik.http.routers.vaultwarden-secure.service=vaultwarden"

      # --- Backend settings ---
      - "traefik.http.services.vaultwarden.loadbalancer.server.port=80"
      - "traefik.docker.network=proxy"

    security_opt:
      - no-new-privileges:true  # The container won't be able to escalate its privileges within the system.

networks:
  proxy:
    external: true  # Use the external Docker network that Traefik already uses.

Notes on the basic file

#

• ADMIN_TOKEN - the token for logging into the admin panel (/admin). Without it, the panel is inaccessible. For how to hash the token properly, see the “Secure ADMIN_TOKEN” section below.
• SIGNUPS_ALLOWED=false - recommended if the server is exposed externally. Only allow true while creating the first account, then turn it off.
• WEBSOCKET_ENABLED=true - real-time sync across clients. The reverse proxy must support proxying Upgrade: websocket.

Advanced configuration: .env, SSO, and push notifications

#

Once the service picks up users, you’ll want to get secrets out of the compose file, add single sign-on through your own identity provider (mine is Authentik), and get push notifications on mobile clients instead of just polling/websocket. Here’s the configuration that’s currently running for me.

docker-compose.yml

#

services:
  vaultwarden:
    container_name: vaultwarden
    image: vaultwarden/server:latest
    restart: unless-stopped
    volumes:
      - /path/to/docker/vaultwarden/data:/data
      - /path/to/docker/vaultwarden/logs:/data/logs
    ports:
      - 18083:80
    environment:
      - ADMIN_TOKEN=${VAULTWARDEN_ADMIN_TOKEN}
      - SIGNUPS_ALLOWED=${VAULTWARDEN_SIGNUPS_ALLOWED}
      - SIGNUPS_VERIFY=${VAULTWARDEN_SIGNUPS_VERIFY}
      - INVITATIONS_ALLOWED=${VAULTWARDEN_INVITATIONS_ALLOWED}
      - WEBSOCKET_ENABLED=true
      - ROCKET_ENV=prod
      - ROCKET_WORKERS=10
      - TZ=${VAULTWARDEN_TZ}
      - LOG_LEVEL=error
      - EXTENDED_LOGGING=true
      - DOMAIN=${VAULTWARDEN_BASE_URL}
      - SMTP_HOST=${VAULTWARDEN_EMAIL__HOST}
      - SMTP_PORT=${VAULTWARDEN_EMAIL__PORT}
      - SMTP_FROM=${VAULTWARDEN_EMAIL__USERNAME}
      - SMTP_USERNAME=${VAULTWARDEN_EMAIL__USERNAME}
      - SMTP_PASSWORD=${VAULTWARDEN_EMAIL__PASSWORD}
      - SMTP_SECURITY=${VAULTWARDEN_EMAIL__SECURITY}
      - SSO_ENABLED=true
      - SSO_AUTHORITY=https://authentik.domain.ru/application/o/vaultwarden/
      - SSO_CLIENT_ID=${VAULTWARDEN_SSO_CLIENT_ID}
      - SSO_CLIENT_SECRET=${VAULTWARDEN_SSO_CLIENT_SECRET}
      - SSO_SCOPES="openid email profile offline_access"
      - SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
      - SSO_CLIENT_CACHE_EXPIRATION=0
      - SSO_ONLY=false            # true - completely disables master-password login, SSO only
      - SSO_SIGNUPS_MATCH_EMAIL=true  # the first SSO login is linked to an existing account by email
      - PUSH_ENABLED=true
      - PUSH_INSTALLATION_ID=${VAULTWARDEN_PUSH_INSTALLATION_ID}
      - PUSH_INSTALLATION_KEY=${VAULTWARDEN_PUSH_INSTALLATION_KEY}
      - PUSH_RELAY_URI=https://api.bitwarden.eu
      - PUSH_IDENTITY_URI=https://identity.bitwarden.eu
    networks:
      - vaultwarden
    # The reverse proxy is configured separately — see the Traefik/Nginx section below.
    # Example Traefik labels (if the container is on the same network as the proxy):
    #labels:
    #  - "traefik.enable=true"
    #  - "traefik.http.routers.vaultwarden.entrypoints=web"
    #  - "traefik.http.routers.vaultwarden.rule=Host(`vaultwarden.domain.ru`)"
    #  - "traefik.http.middlewares.vaultwarden-https-redirect.redirectscheme.scheme=https"
    #  - "traefik.http.routers.vaultwarden.middlewares=vaultwarden-https-redirect"
    #  - "traefik.http.routers.vaultwarden-secure.entrypoints=websecure"
    #  - "traefik.http.routers.vaultwarden-secure.rule=Host(`vaultwarden.domain.ru`)"
    #  - "traefik.http.routers.vaultwarden-secure.tls=true"
    #  - "traefik.http.routers.vaultwarden-secure.service=vaultwarden"
    #  - "traefik.http.services.vaultwarden.loadbalancer.server.port=80"
    #  - "traefik.docker.network=proxy"
    security_opt:
      - no-new-privileges:true

networks:
  vaultwarden:
    external: true

.env file

#

Secrets and things that often change between environments go into .env next to docker-compose.yml:

VAULTWARDEN_ADMIN_TOKEN=<hashed token, see section below>

# Temporary settings for the first registration
VAULTWARDEN_SIGNUPS_ALLOWED=false
VAULTWARDEN_SIGNUPS_VERIFY=true
VAULTWARDEN_INVITATIONS_ALLOWED=true

# Email for notifications
VAULTWARDEN_EMAIL__HOST=smtp.gmail.com
VAULTWARDEN_EMAIL__PORT=465
VAULTWARDEN_EMAIL__USERNAME=<your email/SMTP login>
VAULTWARDEN_EMAIL__PASSWORD="<app password>"
VAULTWARDEN_EMAIL__SECURITY=force_tls  # options: starttls, force_tls, off

# SSO (Authentik)
VAULTWARDEN_SSO_CLIENT_ID=<client id from Authentik>
VAULTWARDEN_SSO_CLIENT_SECRET=<client secret from Authentik>

# Push notifications
VAULTWARDEN_PUSH_INSTALLATION_ID=<installation id from bitwarden.com/host>
VAULTWARDEN_PUSH_INSTALLATION_KEY=<installation key from bitwarden.com/host>

# Locale
VAULTWARDEN_TZ=Europe/Moscow

# Base URL (needed for email confirmation and SSO redirect to work correctly)
VAULTWARDEN_BASE_URL=https://vaultwarden.domain.ru

What changed compared to the basic version

#

Setting up SSO via Authentik

#

Vaultwarden supports login via OpenID Connect - you can use Authentik, Keycloak, Authelia, or any other OIDC-compatible provider. The general logic is the same, shown below using Authentik as the example.

1. In Authentik, create a new OAuth2/OpenID Provider with a redirect URI like https://vaultwarden.stilicho.ru/identity/connect/oidc-signin.
2. Create an Application, link it to the provider from step 1, and set a slug (in my case - vaultwarden, hence SSO_AUTHORITY=.../application/o/vaultwarden/).
3. Copy the Client ID and Client Secret - these go into VAULTWARDEN_SSO_CLIENT_ID and VAULTWARDEN_SSO_CLIENT_SECRET.
4. In the compose file, set SSO_ENABLED=true and specify SSO_AUTHORITY - this is the base URL of your OIDC provider; Vaultwarden will pick up .well-known/openid-configuration on its own.
5. SSO_SIGNUPS_MATCH_EMAIL=true - if a user already has a Vaultwarden account, the first SSO login gets linked to it by email instead of creating a duplicate.
6. Leave SSO_ONLY as false until you’ve confirmed SSO login definitely works - otherwise you risk locking yourself out if something goes wrong on the provider’s side.

Push notifications

#

PUSH_ENABLED enables push notifications on Bitwarden mobile clients (instant appearance of one-time login codes, new-device notifications, etc.) without constant polling.

For this you need PUSH_INSTALLATION_ID and PUSH_INSTALLATION_KEY - issued for free at bitwarden.com/host after registering a self-hosted installation. In the example, PUSH_RELAY_URI/PUSH_IDENTITY_URI point to the European relay (api.bitwarden.eu / identity.bitwarden.eu) - if your users aren’t in the EU, you can use the global relay (api.bitwarden.com / identity.bitwarden.com).

Secure ADMIN_TOKEN

#

By default you can simply generate a random, complex token in any password generator and put it in ADMIN_TOKEN, but storing it as plain text is insecure - Vaultwarden will warn you about it both in the logs and in the admin panel itself.

The simplest way to hash the token is Vaultwarden’s own built-in command (available since version 1.28), which requires no extra packages:

docker exec vaultwarden /vaultwarden hash --preset owasp

The command asks for the password interactively and outputs a ready string like $argon2id$v=19$m=...$... - that’s what you paste into ADMIN_TOKEN (in the .env file you don’t need to escape $; but if you write the value directly into docker-compose.yml without .env, each $ needs to be doubled: $$, otherwise Compose will try to interpret them as environment variables).

Details are in the Vaultwarden wiki.

After that, you can (re)start the container:

docker compose up -d

Keep in mind that the /admin panel is the most attractive target for brute-forcing; if you want to lock it down with extra rate-limiting or ban scanners at the Traefik level, see the article on middlewares in Traefik and CrowdSec.

First login to the admin panel

#

After the container starts, you can check its logs, for example via Portainer or the docker logs vaultwarden command.

If everything’s fine, the app won’t complain - the token value is properly hashed. Otherwise you’ll see a warning that the token is stored as plain text and that this is insecure (this by itself doesn’t affect functionality, but it weakens the admin panel’s protection).

To reach the admin panel, type the address of your Vaultwarden into the browser’s address bar and be sure to add /admin at the end.

To confirm, enter the admin password and you land in the panel. Select the General settings tab - this is the central configuration section.

Right at the top there’s a reminder that any values entered in the admin settings will override environment variable values (for example, mail server settings) or the app’s own settings. Values that will be overridden are highlighted in yellow.

The “General settings” section - a detailed overview

#

Domain

#

• Description: The main domain Vaultwarden is accessible on.
• Example: https://vaultwarden.stilicho.ru
• Purpose: Used in links (invitations, password reset, email notifications, SSO redirect).
• Important: if you change the domain, also update WEBSOCKET_ADDRESS and the redirect URI in your OIDC provider’s settings.

WebSocket Address

#

• Description: The WebSocket address for syncing Bitwarden clients.
• Example: wss://vault.stilicho.ru/notifications/hub
• Purpose: Enables instant sync (for example, if a new password is added from another device).
• Note: If you use Traefik or another proxy - make sure to forward /notifications/hub.

Web Vault Enabled

#

• Description: Enables or disables the web vault interface.
• Default: enabled.
• Why disable it: if you want to use Vaultwarden only through the Bitwarden Desktop/Mobile clients.

User Registration (Allow new signups)

#

• Environment variable: SIGNUPS_ALLOWED
• Options: true - anyone can register; false - only manually (the admin creates users via /admin or invitations).
• Tip: disable it on a public server. Only leave it enabled temporarily to register the first account.

Require email verification on signups

#

• Variable: SIGNUPS_VERIFY
• Recommendation: enable it when SMTP is configured - especially if invites are allowed (INVITATIONS_ALLOWED=true), to rule out email typos.

Invitation (Allow invitations)

#

• Variable: INVITATIONS_ALLOWED
• Recommendation: leave it enabled if you use Organizations - otherwise no one will be able to join.

SMTP Enabled

#

• Variables: SMTP_*
• Recommendation: set up SMTP before creating organizations or before a password reset is needed.

SSO Enabled

#

• Variable: SSO_ENABLED
• Description: enables login via OpenID Connect. In the admin UI you can view the current connection status with the provider and diagnostics - useful if something’s off with SSO_AUTHORITY.

E-mail Domain Whitelist

#

• Example: stilicho.ru,prohomelab.com
• Purpose: restrict registration to your own/corporate domains.

Allow password hints

#

• Recommendation: can be disabled so as not to give a potential attacker any hints.

YubiKey OTPs Enabled

#

• Variables: YUBICO_CLIENT_ID, YUBICO_SECRET_KEY
• Purpose: two-factor authentication via YubiKey hardware keys.

WebSocket Notifications Enabled

#

• Note: requires a properly configured reverse proxy. WebSocket Docs

Admin Token

#

• Description: shows the current token used to log into the admin panel. It can only be changed via the environment variable (ADMIN_TOKEN in .env); the panel doesn’t let you change it “on the fly” without restarting the container.

Disable Two-Factor remember

#

• Recommendation: enable on public servers for better security. Note: since recent Vaultwarden versions, “remembered” 2FA tokens are valid for no more than 30 days regardless.

The rest of the settings are up to you, but I’d turn off simple uncontrolled registration in the app. Disabling registration doesn’t affect invitations or SSO.

The Users section

#

The “Users” table shows a list of all vault users, their status, confirmation level, and activity. From here you can also invite new users and manually confirm SSO accounts if SSO_SIGNUPS_MATCH_EMAIL didn’t kick in automatically.

What is an Organization

#

An Organization is a group of users who can share certain items (logins, passwords, secure notes, etc.). Analogous to a corporate or family vault in Bitwarden Cloud.

Basic idea

#

• You have a personal vault, visible only to you.
• Within an Organization you can create shared collections, for example:
  • “DevOps” - CI/CD passwords, SSH keys, API tokens
  • “Marketing” - access to social media and ad accounts
  • “Family” - shared subscriptions (Netflix, Spotify, etc.)

How it works

#

1. The admin creates an organization (e.g., “ProHomelab”).
2. Adds members by email (they need an account on the same server - via regular registration, invite, or SSO).
3. Creates Collections (categories for shared data).
4. Assigns access rights to each collection (read, write, admin).
5. Users receive these entries in their Bitwarden client (web, desktop, mobile).

Example structure

#

Organization: ProHomelab
 ├── Collection: Infrastructure
 │    ├── Proxmox login
 │    ├── Traefik dashboard
 │    └── Grafana API key
 ├── Collection: Media
 │    ├── Jellyfin admin
 │    └── Audiobookshelf credentials

Role types

#

• Owner - full control over the organization.
• Admin - manages users and collections.
• Manager - manages only their own collections.
• User - uses granted access, without managing the structure.

Important details

#

• Organizations aren’t required for personal use.
• Invitations require INVITATIONS_ALLOWED enabled and SMTP configured.
• You can create several organizations on one server.
• Personal encryption keys are supported - the admin can’t see the contents of members’ passwords.

Registering the first user

#

Go to your Vaultwarden’s address (in my case vaultwarden.stilicho.ru) and choose Create Account.

Enter an email and a nickname.

By default the password must be at least 12 characters, and Vaultwarden checks it for complexity and offers to check whether it’s been leaked (whether such a password has been compromised before).

After that you land in the vault.

At the top there’s a hint about the first three steps: create an account, install the browser extension, import data from another password manager. The export format depends on the specific source app, but the general principle is the same: export a file there, import it here.

User Settings

#

User settings are what a regular Vaultwarden user sees after logging into the Web Vault interface at https://vaultwarden.<your-domain>.ru.

Let’s look at the Vaults section - the “heart” of the whole system, where passwords, tokens, notes, and other secrets are stored and managed.

💡 To avoid confusion:

• Vaults - the personal store (and shared ones via Organizations).
• Settings - vault behavior settings.
• Admin Panel (/admin) - server-side parameters.

Basic structure

#

1. Items (vault entries)

#

Each item contains a name, type, fields (username, password, URL, etc.), optionally a TOTP code, attachments, notes, and a link to an Organization/Collection.

2. Collections

#

If you’re part of an Organization, a list of Collections - shared folders with entries available to a group of users - will appear in the left panel. Without an organization, these sections aren’t shown.

3. Navigation tabs

#

4. Adding new entries

#

The + New Item button opens the entry creation form. Options include “Generate password” (built-in generator), “Add TOTP” (one-time 2FA code), “Attach file” (if ENABLE_ATTACHMENTS=true is enabled).

5. Search and filtering

#

Search by name, username, domain, notes - performed locally, data isn’t sent to the server in plain text. Filters: by item type, by organization/collection, by tags.

6. Folders

#

A personal logical structure, not tied to organizations. Data in a folder isn’t shared with other users, even if they’re in the same organization.

7. Trash

#

Deleted entries don’t disappear immediately - they go to the trash, from where they can be restored or permanently deleted.

8. Item context menu

#

View, Edit, Clone, Move to Folder/Collection, Add Favorite, Delete.

9. Password Generator

#

Generates a password of the desired length and complexity (letters, digits, symbols, exclusion of similar-looking characters) - available directly from the Vault.

Backups

#

A common question people ask online is how exactly to back up Vaultwarden. Here’s a minimal working approach.

For SQLite (the default database), it’s enough to copy the entire data directory while the container isn’t actively writing - or use sqlite3 .backup for a consistent snapshot without stopping the service:

#!/usr/bin/env bash
set -e

SRC="/path/to/docker/vaultwarden/data"
DEST="/backup/vaultwarden/$(date +%F)"

mkdir -p "$DEST"
sqlite3 "$SRC/db.sqlite3" ".backup '$DEST/db.sqlite3'"
cp -r "$SRC/attachments" "$DEST/" 2>/dev/null || true
cp -r "$SRC/sends" "$DEST/" 2>/dev/null || true
cp "$SRC/rsa_key"* "$DEST/" 2>/dev/null || true

# clean up backups older than 14 days
find /backup/vaultwarden -maxdepth 1 -mtime +14 -exec rm -rf {} \;

Hook this up to cron (e.g., once a day) and make sure to verify that the backups actually restore - a “backup that’s never been restored,” as they say, is just a file taking up space.

If you use PostgreSQL/MySQL - use pg_dump/mysqldump respectively instead of copying the SQLite file.

Common mistakes

#

• DOMAIN doesn’t match the real HTTPS address - this breaks email confirmation and TOTP/2FA. Check that the value exactly matches what the browser sees (including protocol, no trailing slash).
• WebSocket won’t connect - the reverse proxy isn’t proxying /notifications/hub with the Upgrade/Connection headers. Check the proxy config.
• SSO redirects to an error - the redirect URI in the OIDC provider’s settings doesn’t match Vaultwarden’s real address, or SSO_AUTHORITY doesn’t point to the provider’s/application’s root URL.
• No push notifications arriving - stale or incorrect PUSH_INSTALLATION_ID/PUSH_INSTALLATION_KEY, or the wrong relay region is selected (.com instead of .eu or vice versa).
• Warning about a plain-text ADMIN_TOKEN in the logs - the token isn’t hashed, see the section on vaultwarden hash --preset owasp.

FAQ

#

Can Vaultwarden be used without a domain of my own? Technically yes (via IP), but the Web Vault requires a secure context (HTTPS) for the Web Crypto API, and without a domain it’s much harder to get a proper TLS certificate. In practice - the system won’t really work without a real domain.

Is SSO mandatory? No, it’s an optional add-on. Regular registration with a master password works fine without it. Moreover, using SSO doesn’t disable the built-in authentication.

Can I migrate data from Bitwarden Cloud? Yes - export the vault from Bitwarden Cloud (Settings → Export Vault) and import it into a freshly created account on Vaultwarden.

What do I do if I forgot ADMIN_TOKEN? Generate a new one via vaultwarden hash --preset owasp and update .env/the environment variable, then restart the container. This has no effect on user data.

Summary

#

Unfortunately, a single article can’t cover every capability of this excellent app, so for more details on all the settings, see the official Vaultwarden documentation.