Self-Hosted Password Manager on a Mini PC: Sizing Vaultwarden on Real Hardware

The short answer

A password manager is the lightest self-hosted service you will ever put on a mini PC. Vaultwarden runs as a single Rust container with a documented idle footprint under ~100 MB of RAM, and every hardware demand it makes sits far below what our Beelink EQi12 measured while running media servers and database benchmarks. The real work is not horsepower — it is HTTPS, backups, and patch discipline.

One honesty note before anything else: we have not run Vaultwarden end-to-end on this machine. What we have measured, on this exact unit, is the hardware envelope any self-hosted vault would live inside — idle and load power, NVMe write speed, reverse-proxy request throughput, and month-scale stability. This page uses those numbers for what they are good at: deciding whether the machine you already own makes the problem trivial. It does. Every figure traces to the public EQi12 measurement repository (CC BY 4.0), and product terms were verified in October 2026.

Where this page fits among our other pages

What a self-hosted vault actually asks of your hardware

A Bitwarden-compatible server is not a media server. There is no transcoding, no machine learning, and no sustained disk pressure. Vaultwarden implements the Bitwarden client API in Rust, stores everything in a single SQLite database by default (PostgreSQL and MySQL are optional, not required), and spends almost its entire life waiting for a client to sync a few kilobytes of ciphertext.

That last phrase is the whole sizing story. Bitwarden clients encrypt every item locally before it ever reaches the server — the server holds ciphertext it cannot read — and a sync consists of small JSON payloads over HTTPS. Even a household of six with thousands of entries produces traffic that would embarrass a single JPEG upload. Compare that with what we measured on the same class of machine in the EQi12 Docker component benchmark: an nginx container sustained 10,630 requests per second at 100 concurrent connections with zero errors. A reverse proxy fronting a family password vault uses a rounding error of that ceiling.

The contenders: Vaultwarden, official Bitwarden self-host, KeePassXC

The feature table is the easy part and honest guides mostly agree on it. What the table cannot tell you is whether the machine matters — and for once, the answer is that it barely does, which is exactly what the measurements below show.

The capacity evidence, clearly labeled

Everything in the top half of this table was measured on the same Beelink EQi12 (Intel i3-1215U, 6C/8T, 16 GB DDR4-3200, WD PC SN540 512 GB NVMe, firmware 33006000) running Docker on Windows. These are component benchmarks and whole-system states — not Vaultwarden scores. The two Vaultwarden rows are documented or third-party figures, labeled as such.

The contrast with every other self-hosting decision we have written about is the point. Choosing a photo platform or a NAS operating system involves genuine capacity math — ML pipelines, ZFS RAM floors, storage IO. Choosing a password server involves checking that your reverse proxy is up and your backups run. If your mini PC survives the workloads in the table above, the vault is not the thing that will stress it.

The HTTPS requirement shapes your setup more than the hardware does

The one hard requirement is a secure context. The Bitwarden web vault uses the browser’s Web Crypto API, which is only available over HTTPS, and the official clients want a trusted endpoint too. In practice you have three shapes, in rising order of exposure:

1. VPN-only access. The vault listens on your LAN or on a Tailscale interface only; you generate a Tailscale HTTPS certificate for a private hostname and nothing is exposed to the internet at all. This is the shape we would run on a home mini PC, and the Tailscale vs WireGuard vs ZeroTier comparison covers why Tailscale is the default for this.
2. Reverse proxy with public DNS. Caddy or nginx terminates TLS and proxies to the container, which stays on the internal Docker network. This is the upstream-recommended shape and matches the measured nginx headroom above.
3. Direct port exposure — not recommended for a password vault on any machine.

Whichever shape you pick, disable open registration (SIGNUPS_ALLOWED=false once your users exist) and protect the admin interface with a strong token. Those are configuration tasks, not hardware tasks — which is why this section is longer than the sizing section.

Backup is the part that deserves real engineering

A password vault inverts the usual storage logic. The data volume is trivially small, but the value of every kilobyte is enormous, and the failure mode — losing the only copy of your vault database — is catastrophic in a way losing a media cache is not.

Three rules we would apply, consistent with our backup and restore drill:

• Back up the database file itself, safely. Pause the container or use the built-in backup command added in Vaultwarden 1.37.3 (September 2026) so you are not copying a SQLite file mid-write.
• Treat every copy as sensitive. The database is encrypted at rest, but it is still an attack target — keep copies on encrypted media and do not leave them on a public share.
• Keep one copy off the machine and test a restore. The retention math is trivial for a file this small; the backup retention planner helps with scheduling, but the drill page is the one that proves you can actually recover.

If your mini PC only has one internal NVMe, an external USB drive is fine for this role — but read the USB storage reality check first, because the port you plug into can change your write speed by nearly an order of magnitude. For a vault-sized database, even the slowest measured path (~36 MiB/s) finishes a backup in under a second; the point of that page is knowing which ports to trust for anything bigger.

The update treadmill is the real cost

Here is the honest trade, and it is not about hardware. Vaultwarden is an unofficial project that must track the official clients, and the compatibility clock is real: Bitwarden clients released from July 2026 onward require server version 1.37.0 or newer, and the 1.37.x line has been shipping security fixes steadily — 1.37.4 (October 2026) alone closed seven advisories, one rated high. Since version 1.35.0 (December 2025), native OpenID Connect single sign-on is available, but a master password is still required.

What that means in practice: a self-hosted vault is a service you patch promptly, every time, because your credentials live inside it. This is the one dimension where the official Bitwarden plans win on paper — Premium at $19.80/year or a Families plan at roughly $40-48/year for six users buys you someone else’s patch discipline. If you will not maintain a container, pay the subscription; $20 a year is cheaper than your time and safer than an unpatched server. If you already run a maintained Docker stack — and the fact that you are reading a site about measured home servers suggests you do — the vault is one more docker compose pull in a weekly routine you already have.

What we did not test

For completeness, the boundary of this page: we have not installed Vaultwarden, so there are no end-to-end sync latency numbers, no measured container RAM on our own unit, no client-app battery observations, and no benchmark of the admin interface. The Vaultwarden-side figures above are documented footprints and clearly attributed third-party measurements. The hardware-side figures are our own instrumented results, published raw in the measurement repository. We drew no performance conclusion about Vaultwarden itself — none is needed, because the machine’s envelope sits so far above the documented footprint that the margin question answers itself.

Fact block (for citation)

Data licensed CC BY 4.0. Product terms and versions change; verify current quotas and prices before making decisions. This page contains no Vaultwarden performance benchmarks — the service itself was not run by us.