Vaultwarden VPS requirements: the smallest server that works

Sizing guide

Our recommendations, derived from the sourced figures below. Not measurements.

Official requirements

What people report in practice

Individual reports, not controlled tests. Versions, hardware and settings differ, so treat these as data points, not guarantees.

• A Vaultwarden maintainer suggested 2 vCPUs and 1 GB RAM for a family VPS, adding: "In theory Vaultwarden can do with less then 100MB by it self." More CPU and storage are the only upgrades likely to help

  Answer by maintainer BlackDex to a question about a family instance, Jan 2024

  Forum Vaultwarden forum: Hardware requirements · checked Oct 24, 2026

• Idle: Vaultwarden 42 MB RAM and almost zero CPU, image about 168 MB. The same data on Bitwarden lite plus MariaDB idled at about 850 MB (771 MB app + 95 MB database), with images totalling about 2.08 GB

  vaultwarden/server:1.35.4-alpine with SQLite, single container; the author's own before-and-after migration

  Blog Ananta Fatur: Bitwarden vs Vaultwarden resource comparison · checked Oct 24, 2026

• Idle on Ubuntu 24.04 with one user and a small vault: Vaultwarden (SQLite) 58 MB in 1 container, Bitwarden lite + MariaDB 470 MB in 2, Bitwarden standard (MSSQL) about 2,400 MB in 12

  docker stats --no-stream on a 4 GB box; a hosting company's article, so the comparison is theirs, not ours

  Blog SSD Nodes: Vaultwarden vs Bitwarden self-hosted server · checked Oct 24, 2026

• 30 MiB RAM and 0.00% CPU on a server with 473.6 MiB of memory available

  vaultwarden/server:latest behind Caddy; one docker stats sample in a setup write-up

  Blog Stanislav Myachenkov: Selfhosting Vaultwarden Password Manager · checked Oct 24, 2026

• Replies to "is 4 GB enough?": one user ran Vaultwarden "for a few years" on a cheap 1 GB VPS for 2 users; another saw about 35 MB in an LXC container; another runs it with six other services on a 1 GB Raspberry Pi 3B+ at 65% memory use

  r/selfhosted thread, Mar 2026; individual reports, no versions given

  Reddit Reddit r/selfhosted: Vaultwarden - 4gb of RAM · checked Oct 24, 2026

• With about 6,000 stored passwords, the Vaultwarden process used 1 GB and sometimes more. The maintainer replied that large vaults, favicon downloads and database connections could contribute, and suggested the Alpine image, which uses a different memory allocator

  GitHub discussion, Sep 2024, Docker vaultwarden/server:latest on a 4 vCPU / 4 GB VPS; no root cause posted

  GitHub GitHub dani-garcia/vaultwarden discussion #4981: High memory usage on a 4 vCPU 4 GB VPS · checked Oct 24, 2026

• Building Vaultwarden from source (cargo build --release) needed at least 7 GB RAM, so updates failed on 8 GB home-lab machines. Reported runtime afterwards: about 400 MB as a Debian 13 native build, about 15 MB as Alpine native, about 65 MB in Docker Alpine

  Proxmox community-scripts maintainers, Sep 2025; their install script compiles from source

  GitHub GitHub dani-garcia/vaultwarden #6314: Excessive RAM requirements for builds · checked Oct 24, 2026

• The built-in SQLite backup switched to a method that "loads the whole DB into RAM", which the contributor linked to more OOM errors on small deployments with 256 MB RAM. Reverted to VACUUM INTO (merged 5 Apr 2026)

  Affected 1.35.0 (Dec 2025) through 1.35.4; the fix shipped in 1.35.5 (12 Apr 2026). Latest release on the check date: 1.37.4 (5 Oct 2026)

  GitHub GitHub dani-garcia/vaultwarden PR #6989: Change SQLite backup to use VACUUM INTO · checked Oct 24, 2026

What drives Vaultwarden's RAM use

Barely anything at idle

Vaultwarden is one Rust process with SQLite in the same container, so there's no separate database server or language runtime using memory. That is the main difference from the official Bitwarden server, whose standard deployment runs about a dozen containers including MSSQL. The reports above put Vaultwarden at tens of megabytes against hundreds of megabytes (Bitwarden lite) or gigabytes (Bitwarden standard).

Vault size, icons and connections

The maintainer named three things that can push RAM up: large vaults, website icon downloads, and database connections (discussion #4981). Icons are fetched and cached by the server unless you turn that off with DISABLE_ICON_DOWNLOAD or point ICON_SERVICE elsewhere (.env.template). If a small instance grows, try the -alpine image tag, which the maintainer says uses a different memory allocator.

Building is not running

Compiling Rust is far heavier than running the result. The wiki says building the web vault needs about 1.5 GB, and a script that compiles Vaultwarden itself reported 7 GB or more. Pull the prebuilt vaultwarden/server image (or a binary extracted from the Alpine image) and a 1 GB VPS never sees that load.

Disk is attachments

The SQLite database holds passwords, notes and metadata, and is small. File attachments and Send files are stored as separate files and are what grows. You can cap them per user or per organization with USER_ATTACHMENT_LIMIT and ORG_ATTACHMENT_LIMIT (in KB). The prebuilt Alpine image was about 168 MB in one report.

Gotchas on a VPS

• Update promptly. Bitwarden's mobile apps and browser extensions update themselves, and upstream sometimes makes changes that break older servers. The wiki warns that falling behind on Vaultwarden releases can cause "sudden breakage" (container image docs). Releases also carry security fixes; 1.35.5 fixed three advisories.
• Use 1.35.5 or newer on small plans. Built-in SQLite backups in 1.35.0–1.35.4 loaded the whole database into RAM, which was linked to out-of-memory errors on 256 MB deployments (PR #6989). Current releases stream the backup.
• Back up more than the database. Back up db.sqlite3 with SQLite's .backup command (not a raw copy while it's in use), plus attachments/, sends/, config.json and the rsa_key.* files (backup guide). Store copies off the VPS: if the server is lost, so is the vault.
• Don't put SQLite on a network share. CIFS/Samba volumes without file locking cause problems with the SQLite database (the wiki's example is Azure Web Apps, FAQs). Keep the data folder on the VPS's local disk.
• Close sign-ups and protect /admin. SIGNUPS_ALLOWED defaults to true, so anyone who finds your URL can create an account until you turn it off. Coolify's one-click Vaultwarden template also defaults it to true (template). If you enable the admin page, store ADMIN_TOKEN as an Argon2id hash (admin page docs).
• HTTPS and WebSockets through the proxy. The web vault only works over HTTPS. Since 1.29.0, live sync notifications run on the main port, so a reverse proxy must pass the WebSocket Upgrade and Connection headers. Mobile apps use push notifications instead, which need separate credentials from Bitwarden (WebSocket docs).
• Don't report bugs to Bitwarden. Vaultwarden is not affiliated with Bitwarden, Inc. The project asks users to report bugs to Vaultwarden, not to official Bitwarden support, whichever client they use.

Cheapest plans that fit

Vaultwarden on its own (SQLite, prebuilt image): 1 GB RAM and 1+ vCPU

Threshold: VPSfit budget of 512 MB for Vaultwarden and its reverse proxy, from reported idle use of 30–58 MB; the smallest plans we track have 1 GB (source). Only plans with at least 1 vCPU are listed.

Vaultwarden, maintainer's suggested spec: 1 GB RAM and 2+ vCPU

Threshold: Maintainer suggestion: 2 vCPUs and 1 GB RAM, plus storage for attachments (source). Only plans with at least 2 vCPUs are listed.

Prices checked Oct 21, 2026 on each provider's official pricing page. EUR prices converted at the ECB rate of Oct 20, 2026 (1 € = $1.1215) only for ranking. See all plans on the cheapest 4 GB VPS page.

Related pages

• Coolify requirements: Vaultwarden is a one-click service in Coolify; Coolify itself needs more RAM than the vault does.
• Nextcloud requirements: A common neighbour on a self-hosting VPS; Nextcloud, not Vaultwarden, decides the server size.
• n8n requirements: Another light app that shares a small VPS well; check its worker and database needs.
• Immich requirements: If the same server holds your photos, size it for Immich's machine learning first.