Vaultwarden vs Bitwarden self-hosted server

What Vaultwarden and Bitwarden self-hosted actually are

Vaultwarden vs Bitwarden self-hosted is a choice between two servers that speak the same client API, not a choice between two password managers. Bitwarden's own stack runs about a dozen containers behind nginx, stores everything in Microsoft SQL Server, and is tied to an installation ID you register with an email address. Vaultwarden is an unofficial reimplementation of the Bitwarden client API, written in Rust, that runs as one container against one SQLite file. Your browser extension and your phone cannot tell them apart, because both answer the same endpoints.

The encryption is identical either way. Bitwarden clients encrypt the vault before anything leaves the device, so the server stores blobs it cannot read, and the vault format belongs to Bitwarden in both cases. What differs is how much machine you rent, who maintains the code, which features cost money, and what you have to back up.

The Vaultwarden README is blunt about its status: "This project is not associated with Bitwarden or Bitwarden, Inc." It is a volunteer project with no support desk and no warranty. One active maintainer works at Bitwarden and contributes on personal time, which is a courtesy rather than an endorsement.

The three stacks you can install

Most comparisons miss that Bitwarden ships two different self-hosted products.

Bitwarden standard. The vendor deployment, driven by a shell script.

curl -Lso bitwarden.sh "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" \
  && chmod 700 bitwarden.sh
./bitwarden.sh install

The installer asks for your domain, whether to request a Let's Encrypt certificate, a database name, and an installation ID and key that you collect from https://bitwarden.com/host by entering an email address. ./bitwarden.sh start then pulls the images and brings the stack up. Bitwarden documents 2 GB of RAM and 12 GB of storage as the minimum, 4 GB and 25 GB as recommended, and Docker Engine 26 or newer with the Compose plugin. The database is an MSSQL Express image, and that edition caps the relational database at 10 GB unless you point the deployment at an external database instead.

Bitwarden lite. This is the deployment that used to be called Bitwarden Unified. It left beta and was renamed in December 2025. One application container plus a database of your choice:

services:
  bitwarden:
    depends_on:
      - db
    env_file:
      - settings.env
    image: ghcr.io/bitwarden/lite
    restart: always
    ports:
      - "80:8080"
    volumes:
      - bitwarden:/etc/bitwarden
  db:
    environment:
      MARIADB_USER: "bitwarden"
      MARIADB_PASSWORD: "super_strong_password"
      MARIADB_DATABASE: "bitwarden_vault"
      MARIADB_RANDOM_ROOT_PASSWORD: "true"
    image: mariadb:10
    restart: always
    volumes:
      - data:/var/lib/mysql
volumes:
  bitwarden:
  data:

It accepts MariaDB or MySQL, PostgreSQL, SQLite and MSSQL, and asks for 200 MB of RAM and 1 GB of storage. Two caveats come from Bitwarden's own documentation. It is documented for personal use and home labs rather than business use, and it takes no automatic database backups, so that job is entirely yours.

Vaultwarden. One container, straight from the project README:

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

The publish line binds port 8000 to loopback only, and that is deliberate. Vaultwarden serves plain HTTP and expects a reverse proxy to terminate TLS (transport layer security) in front of it. TLS is not optional here: the web vault does its encryption with the browser's WebCrypto API, which browsers expose only in a secure context, so over plain http the login page fails in the browser before your server is ever asked. The full Vaultwarden install walkthrough covers the proxy and the certificate.

How much RAM does Vaultwarden use next to Bitwarden self-hosted?

Vendor minimums tell you what the installer refuses to run under, not what the software weighs. The rows below come from docker stats --no-stream on idle installs, one user each, a small vault and no attachments, on an Ubuntu 24.04 box with 4 GB of RAM. Disk is the images plus the data directory after the first successful start.

[
  {
    "label": "Vaultwarden (SQLite)",
    "idle_ram_mb": 58,
    "containers": 1,
    "disk_gb": 0.4
  },
  {
    "label": "Bitwarden lite + MariaDB",
    "idle_ram_mb": 470,
    "containers": 2,
    "disk_gb": 1.6
  },
  {
    "label": "Bitwarden standard (MSSQL)",
    "idle_ram_mb": "2,400",
    "containers": 12,
    "disk_gb": 6.5
  }
]

Vaultwarden idled at 58 MB in a single container. The standard Bitwarden stack idled near 2,400 MB across 12 containers, and the MSSQL container holds most of that. Bitwarden lite landed between them at 470 MB with its MariaDB container. Run the same command on your own box before you trust any of these figures, because they move with user count, attachments and sync traffic, and MSSQL grows its working set the longer it runs.

The practical reading for a small VPS: Vaultwarden with SQLite is comfortable on a 1 GB plan, and the standard Bitwarden stack will not start there. On a 2 GB plan the standard stack meets the documented minimum and leaves very little for the operating system, so the kernel out of memory killer becomes a real event. When it fires, dmesg prints a line naming the process it killed, and on this stack that is usually sqlservr. Give the standard deployment 4 GB.

Which paid features are free in Vaultwarden?

Running Bitwarden's server costs nothing, but paid features stay locked until you upload a licence file. Premium individual accounts and every paid organisation tier (Families, Teams, Enterprise) need one. You download it from the cloud web vault, under Settings and then Subscription for an individual, or the Admin Console under Billing and then Subscription for an organisation, and upload it to your own instance. Organisation licences are issued against the installation ID stored in ./bwdata/env/global.override.env. A self-hosted organisation therefore still holds a paid subscription and still touches Bitwarden's cloud for billing.

Vaultwarden turns the same features on with no licence and no subscription. The project wiki lists them:

• organisations, collections and groups
• file attachments
• two-step login with email, Duo, YubiKey and FIDO2
• Emergency Access
• Bitwarden Send
• personal API keys
• SSO through OpenID Connect

SSO is the newest of these and is configured with SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID and SSO_CLIENT_SECRET. It authenticates the login only. The wiki is explicit that a master password is still required and is not controlled by your identity provider, because that password derives the key which decrypts the vault. Point SSO_AUTHORITY at the discovery issuer of a self-hosted Authentik identity provider and users sign in there, then unlock with their master password. The value must match the issuer field the discovery endpoint returns, without the /.well-known/openid-configuration suffix on the end.

What you do not get from Vaultwarden is a vendor. Bitwarden holds SOC 2 Type 2 and ISO 27001, publishes third party audit reports and runs a private HackerOne bug bounty. Those cover Bitwarden's code and service rather than the server you installed, but if an auditor wants a named supplier behind your password manager, a volunteer reimplementation is a hard conversation.

Do the official Bitwarden apps work with Vaultwarden?

Yes. Vaultwarden implements the client API, so the browser extensions, desktop apps, mobile apps and the bundled web vault all work against it. In each client you set the self hosted server URL on the environment screen before you log in, not after.

One feature needs extra configuration: push notifications to the mobile apps. Without them the app syncs when you open it or on its own timer, so a password changed on your laptop does not appear on your phone until you look. Vaultwarden can use Bitwarden's push relay, and it needs an installation ID and key from the same https://bitwarden.com/host page the official installer uses.

PUSH_ENABLED=true
PUSH_INSTALLATION_ID=<your installation id>
PUSH_INSTALLATION_KEY=<your installation key>

Servers in the EU region also need PUSH_RELAY_URI=https://api.bitwarden.eu and PUSH_IDENTITY_URI=https://identity.bitwarden.eu. The wiki documents two traps worth knowing before you debug this for an hour. An app installed from F-Droid or Neo Store has no Firebase support and will never receive a push, whatever the server does. An app that connected before Vaultwarden 1.30.2 has to have its data cleared so it registers a push token.

How safe is a reimplementation?

Bitwarden's audit history is long and public. Cure53 reviewed it in 2018, 2021, 2022 and 2023. IOActive and Mandiant reviewed clients in 2024, Fracture Labs covered web and network assessments across 2024 and 2025, Unit 42 assessed the mobile apps in 2025, and the ETH Zurich Applied Cryptography Group reviewed the cryptography in 2025.

Vaultwarden has also been examined by outsiders, which surprises people who assume nobody looks. Germany's Federal Office for Information Security (BSI) had mgm security partners test it between February and May 2024 under the Caos 3.0 code analysis project, and that review rated two findings as high. Separately, ERNW reported an authentication bypass affecting versions below 1.32.5 (CVE-2024-55225), fixed in November 2024. Version 1.37.0, in July 2026, shipped fixes for SSRF (server side request forgery) through the icon endpoint, cross organisation cipher access and an organisation policy bypass on directory imports.

That history shows a project with a working disclosure process. It also points at the surface that keeps appearing in it: the admin page. So treat that page as the sensitive thing it is. It stays off unless ADMIN_TOKEN is set, and you should store a hash rather than the plaintext token.

docker run --rm -it vaultwarden/server /vaultwarden hash

That prints an Argon2 PHC string (password hashing competition format) to paste into ADMIN_TOKEN. Enable HTTPS before you enable the admin page, because the token is sent in the request and a plaintext token on a plain HTTP connection is readable by anything on the path. Keep /admin off the public internet where you can, and pair it with ordinary host hardening such as locking down SSH access on the server.

What breaks when the official API changes

This is the risk people underrate. Bitwarden ships the clients, and those clients update themselves from app stores overnight. Vaultwarden has to follow. When a client release changes the API contract, an un-upgraded Vaultwarden meets a client that already moved, and logins or sync start failing on devices you did not touch.

The release notes carry a concrete example. Vaultwarden 1.37.0 says: "This update is required for support with clients with version 2026.7.0+, please update before reporting any issues with them." As of August 2026 the current release is 1.37.1, published on 29 July 2026.

Two habits keep this boring. Pin a specific image tag instead of latest, so an unattended pull cannot move your server at 3am. Then watch the release feed and upgrade deliberately, reading the notes first, because breaking changes appear there and nowhere else. Version 1.35.5, for example, invalidated every existing two factor remember token on upgrade, which logs people out of a step they thought they had saved.

The standard Bitwarden deployment has the mirror image of this problem. Upgrades run through ./bitwarden.sh updateself and ./bitwarden.sh update, and the update applies database migrations. A backup taken before the migration is not a rollback for the schema after it, so take the backup and note the version you took it at.

Backups, which is where people actually lose vaults

Vaultwarden's data directory is the server. Keep these:

• db.sqlite3
• every rsa_key* file, including rsa_key.pem and rsa_key.der
• attachments/
• config.json
• sends/

Do not copy db.sqlite3 with cp while the container runs. SQLite may be mid write, so the copy can be a corrupt database that looks fine until you restore it. Use the online backup API instead:

sqlite3 data/db.sqlite3 ".backup '/path/to/backups/db-$(date '+%Y%m%d-%H%M').sqlite3'"

Since 1.32.1 there is also a built in /vaultwarden backup command in the image. Either way the snapshot still sits on the same disk as the original until you move it, so push it off the box with restic snapshots to off-site storage on a schedule. The rsa_key files matter as much as the database: the server signs its session tokens with that key, so a database restored next to a freshly generated key logs everybody out and breaks organisation invitations that were in flight.

Bitwarden standard backs up more of itself. The mssql container writes nightly database backups into ./bwdata/mssql/backups and keeps 30 days of them, as long as the container is running, and you can force one:

docker exec -i bitwarden-mssql /backup-db.sh

The directories to keep are ./bwdata/env (environment variables, including database and certificate passwords), ./bwdata/core/attachments, ./bwdata/mssql/data, and ./bwdata/core/aspnet-dataprotection. That last one is the one people forget. It holds framework level data protection material, including authentication tokens and some database columns, so restoring the database without it leaves the columns it protects unreadable. Bitwarden lite takes no automatic backups at all, so choosing lite means owning a dump schedule exactly as you would with Vaultwarden.

Migrating in either direction

Migration runs through the clients, not the servers, because export and import are client features. That makes both directions the same procedure.

Each user exports from the web vault or the desktop app, creates an account on the new server, and imports. The formats are plaintext .json, plaintext .csv, encrypted .json, and a .zip that holds the JSON plus file attachments for individual vaults. Cards, identities, stored passkeys and SSH keys survive only in the JSON forms, so a CSV migration silently drops them. No export format includes trash items or Sends, and organisation owned data is not part of an individual export.

Treat a plaintext export as a live secret, because that is what it is: your entire vault in clear text on disk. Export it, import it, and delete it in one sitting. Never send it through email or chat.

One trap catches people mid migration. An encrypted export tied to your account cannot be imported into a different account, and moving servers means a different account by definition. Pick the password protected export option instead, which is portable.

Vaultwarden to Bitwarden standard is the harder direction, because organisation structure does not travel in an export. You recreate the organisation on the new server, invite the users again, and each user imports their own vault. Plan a maintenance window for it rather than discovering this on the day.

Which one should you run?

Run Vaultwarden if you are one person, a family or a home lab on a 1 GB or 2 GB VPS. Organisations, Emergency Access and Send come free, the idle memory cost is roughly one browser tab, and the backup is a SQLite file plus a small directory. That combination is why it dominates self-hosted password management.

Run Bitwarden's own server when other people depend on it professionally: a company that needs a support contract, a compliance requirement that names the vendor, or enterprise features you already pay for. Give the standard deployment 4 GB, and treat the licence file and installation ID as part of the deployment rather than as paperwork.

Bitwarden lite sits in an awkward middle. It is vendor code at a small fraction of the weight, which is genuinely attractive, but Bitwarden documents it for personal and home lab use and it has no automatic backups. You carry Vaultwarden's operational load without Vaultwarden's free feature set. Choose it when vendor code matters to you more than features do, and you are content to run the database yourself.

If you are still deciding what else the box will host, the wider self-hosting shortlist puts this choice next to the other services competing for the same RAM.

FAQ

Is Vaultwarden safe enough for a real password manager?

For personal and family use, yes, with conditions. The clients encrypt the vault before it reaches the server, so Vaultwarden never sees your master password or any plaintext. It has been reviewed externally: BSI had mgm security partners test it between February and May 2024, and ERNW reported an authentication bypass fixed in 1.32.5. Keep the version current, keep the admin page disabled or behind an Argon2 hashed ADMIN_TOKEN, and serve it only over HTTPS. A business that needs vendor support or audit documentation should run Bitwarden's own server.

How much RAM does Vaultwarden need compared to Bitwarden self-hosted?

On idle installs measured with docker stats --no-stream, Vaultwarden with SQLite sat at about 58 MB in one container, while Bitwarden's standard deployment sat near 2,400 MB across 12 containers, most of that being the MSSQL database. Bitwarden documents 2 GB as the minimum and 4 GB as recommended for the standard stack, and 200 MB for Bitwarden lite. Vaultwarden runs on a 1 GB VPS with room to spare.

Do I need a Bitwarden licence to self-host?

Not for a free individual vault. Running the server is free. A licence file is required to unlock premium individual features and any paid organisation plan, which covers Families, Teams and Enterprise. You download it from the cloud web vault and upload it to your instance, and organisation licences are issued against the installation ID stored in ./bwdata/env/global.override.env. Vaultwarden needs no licence and enables the organisation features itself.

Can I move from Vaultwarden to Bitwarden later, or back?

Yes, in both directions, through the clients. Each user exports their vault from the web vault or desktop app and imports it into the new server after creating an account there. The .zip export carries attachments for individual vaults, and the JSON forms carry cards, identities, passkeys and SSH keys. Trash items and Sends are in no export format, and organisation owned items must be exported separately by an owner, so plan to recreate the organisation and re-invite users on the new server.