Self-Hosted Password Manager on a No-KYC VPS: Vaultwarden Sizing and Security

Yes — a self-hosted password manager is one of the lightest things you can put on a VPS. Vaultwarden, the Rust reimplementation of the Bitwarden server API, typically runs in well under 200 MB of RAM for a personal or small-team vault, which means the smallest no-KYC plan (1 vCPU, 1 GB RAM, 15 GB NVMe at €4.99/mo) is genuinely enough. The hard part isn't capacity. It's making sure you don't lock yourself out of your own credentials.

This article covers what the server actually needs, which plan to pick, the handful of configuration choices that matter for security, and the honest limits of hosting your vault yourself.

Direct answer: what a self-hosted vault actually needs

A password vault is a tiny database of encrypted blobs that syncs a few kilobytes at a time. There is no video transcoding, no heavy query load, no traffic spike. For a household or a team of ten, the realistic resource profile looks like this:

• RAM: Vaultwarden itself commonly sits in the tens of megabytes at idle. Add a reverse proxy (nginx or Caddy) and the OS, and a 1 GB server is comfortable.
• Disk: A vault with thousands of entries is measured in megabytes. Attachments and Bitwarden Sends are what actually consume space.
• CPU: Idle almost all the time. Client-side key derivation (Argon2id or PBKDF2) runs in your browser or app, not on the server.
• Bandwidth: Negligible. Sync payloads are small and infrequent — nowhere near the 1 TB included on the entry plan.

It's worth distinguishing Vaultwarden from Bitwarden's own self-hosted server. The official stack is a multi-container .NET application with a SQL Server backend, and Bitwarden's documentation puts its minimum at roughly 2 CPU cores and 2 GB of RAM. Vaultwarden implements the same client API in a single Rust binary with SQLite by default, which is why it has become the standard choice for small servers. Official Bitwarden clients — browser extensions, desktop, iOS, Android — connect to it by pointing at your custom server URL.

Which no-KYC VPS plan fits

Map it to what else the server will do, not to the vault itself:

Iron 1 (€4.99/mo — 1 vCPU, 1 GB RAM, 15 GB NVMe, 1 TB bandwidth). Fine for Vaultwarden plus a reverse proxy, plus maybe a small static site or a WireGuard endpoint. This is the right choice if the vault is the point of the server.

Iron 2 (€9.99/mo — 2 vCPU, 4 GB RAM, 35 GB NVMe, 4 TB). Pick this if the vault shares the box with anything substantial: a database-backed site, a Matrix server, a monitoring stack, or heavy use of attachments and Sends. The extra NVMe also gives you room to keep local backup snapshots before they're shipped off-site.

Anything larger is overkill unless the password manager is incidental to a bigger workload. If you're unsure where your overall stack lands, the no-KYC VPS plan sizing guide maps RAM, disk and bandwidth to common workloads in more detail.

What self-hosting your vault actually protects

Be precise about the threat model here, because "self-hosted" is often treated as a synonym for "safe" and it isn't.

What it does change: your vault data no longer sits in a commercial provider's multi-tenant database. You're not exposed to that company's breach disclosures, policy changes, subscription tiers, or subpoena handling. You decide the backup policy and the retention.

What encryption already handled anyway: the Bitwarden data model is zero-knowledge by design. Vault items are encrypted client-side with a key derived from your master password before they ever reach the server. That's true on Bitwarden's cloud and on your own box. So moving to self-hosting doesn't suddenly make the ciphertext safer — it changes who holds it and who can be compelled to hand it over.

What it does not hide: your server's operator can see that an encrypted vault exists on disk, see request timing, and see the IP addresses your clients sync from. Full-disk encryption on a running remote server doesn't solve that either — the key is in memory while the machine is up. If you want the full picture of what any host can technically observe, read what your VPS provider can actually see before deciding this matters to you.

What gets worse: you are now the uptime, patching, and backup department. A cloud vault that you forget about still works. A self-hosted vault you forget about eventually breaks.

Where no-KYC hosting genuinely fits here

A password vault is about as sensitive as self-hosted data gets, and the conventional hosting signup flow works against that. Most hosts tie the server to a verified email, a card or PayPal account, and often a name and address — so the encrypted vault sits on infrastructure permanently indexed to your legal identity, and the billing record outlives the server.

That's the specific gap no-KYC hosting closes. IronBalkans accounts are created with no email, name, phone or ID — just a generated account ID and a recovery key — and billing is Monero, Bitcoin or Litecoin at the live rate, so no card or payment processor record ties the box to you. Deployment runs in under 60 seconds after the payment confirms, on real KVM virtualization in Bucharest with dedicated vCPU, RAM and NVMe, a dedicated IPv4, a /64 IPv6 block and DDoS filtering included. You can spin up a server and have Vaultwarden running the same evening.

One caveat worth stating plainly: with no email on file, there is no password reset link. Store your account recovery key the same way you'd store the vault's own emergency backup — offline, in more than one place.

The configuration that actually matters

Five things separate a safe self-hosted vault from a liability:

1. Real TLS, no exceptions. Bitwarden clients rely on the browser's WebCrypto API, which only works in a secure context. Put Vaultwarden behind nginx or Caddy with a valid certificate on a real domain. Don't expose the raw HTTP port.

2. Turn off open signups. Set SIGNUPS_ALLOWED=false once your own account exists. Otherwise anyone who finds the URL can register on your server. Use invitations for additional users.

3. Treat the admin token like a root password. The /admin page is a full management interface. Set ADMIN_TOKEN to an Argon2 hash rather than plaintext, or leave the admin panel disabled entirely and manage via environment variables and the CLI.

4. Lock down the host, not just the app. Keys-only SSH, a restrictive firewall, automatic security updates. The vault's crypto is irrelevant if someone gets root and installs a reverse proxy that captures plaintext on the way in. Start with SSH hardening that measurably reduces risk.

5. Back up correctly, and prove the restore works. For SQLite, use sqlite3 data.db ".backup backup.db" rather than copying a live file. Back up the whole data directory: the database, rsa_key.pem (or config.json on newer builds), attachments/, and sends/. Lose the RSA key and existing sessions and organization keys break even if the database survives. Ship it off the server, encrypted — restic or Borg with tested restores is the right shape for this. Also keep an occasional encrypted JSON export somewhere offline as a last-resort escape hatch that doesn't depend on your server existing at all.

Common mistakes

• Running it on a box you also experiment on. Every package you install is more attack surface in front of your credentials. If the server does anything exposed and risky, put the vault somewhere else.
• Assuming the clients are a backup. Bitwarden clients cache an encrypted copy locally, which is why a server outage doesn't immediately lock you out. But that cache isn't a restore path, and a client that re-syncs against an empty server can leave you with nothing.
• Forgetting SMTP. Without a mail relay configured, email-based invites, 2FA-by-email and password hints don't function. You can run without it — using TOTP for 2FA and manual account creation — but know that going in. Self-hosting outbound mail from scratch is its own project.
• Skipping upgrades. Vaultwarden tracks the Bitwarden API; client updates occasionally require a server update to keep working. Patch it on a schedule.
• Exposing the admin panel to the internet. Bind it behind a VPN or restrict it by source IP.

Pros and cons, honestly

Pros: very cheap to run — the entry plan is under €5/mo and the vault barely touches it; no vendor account, no subscription, no premium tier gating TOTP or attachments; full control of backups and retention; with no-KYC signup and crypto billing, no identity record attached to the infrastructure holding your credentials.

Cons: you own uptime, updates and restores; no support desk if you break the database; a misconfigured admin panel or weak host security is a serious single point of failure; recovery depends entirely on backups you have to maintain and test yourself.

FAQ

Can I run Vaultwarden on 1 GB of RAM? Yes. With a reverse proxy and a lean distro it's comfortable for personal and small-team use.

Do official Bitwarden apps work with it? Yes — set the custom server URL at login. Vaultwarden implements the Bitwarden client API.

Is SQLite good enough, or do I need PostgreSQL/MariaDB? SQLite is fine for small and medium vaults and keeps RAM use minimal. Larger multi-organization deployments may justify a real database server — which is also when you'd want more than 1 GB of RAM.

Does my host see my passwords? Not the plaintext. Items are encrypted client-side before upload. The host can see that encrypted data exists and observe network activity.

What if my server dies? Your clients keep a local encrypted cache, so you aren't locked out instantly — but restore from your off-site backup promptly. Don't rely on client caches as your recovery plan.

Is Bucharest latency a problem? No. Vault syncs are small and infrequent; a few tens of milliseconds is imperceptible for this workload.

Get started

A password manager is the rare self-hosted service where the cheapest plan is genuinely the correct one — the work is in the backups and the hardening, not the hardware. If you want a server with no email, no ID and crypto-only billing to put it on, pick a plan and deploy in under a minute. Just write down the recovery key before you do anything else.