Self-Hosted Vaultwarden: Docker & Client Setup Guide

Let’s talk about something that affects every single person reading this: passwords. You’ve got hundreds of them. Your Netflix, your bank, that random forum you signed up for in 2014, your work email, your kid’s school portal. And if you’re being honest, you’re probably reusing the same three or four with slight variations. Yes, really. I know, I know — don’t worry, you’re in good company. But what if I told you there’s a way to never type a password again, never reuse one again, and keep them all safe on a server you own? That’s where self-hosted Vaultwarden comes in. Want to skip ahead and just see one in action? Have a peek at vault.myguard.nl — that’s a real, live, hardened Vaultwarden instance running on the same stack we’re about to build.

Selfhosted Vaultwarden Docker password manager dashboard

What Is Vaultwarden, in Plain English?

Imagine a tiny, very polite digital butler whose entire job is to remember every password you’ve ever made, autofill them when you visit the right website, and gently scold you when you try to reuse one. That’s a password manager. The most famous one is Bitwarden — it’s open-source, audited, and trusted by millions. But the official Bitwarden server is a beast: it needs Microsoft SQL Server, multiple containers, lots of RAM, and frankly a degree in patience to keep running on your own hardware.

Vaultwarden is the lightweight, community-built alternative server. It speaks the same language as Bitwarden — meaning every official Bitwarden app, browser extension, and CLI tool works with it perfectly — but it’s written in Rust, fits in a single tiny Docker container, sips about 50 MB of RAM, and runs happily on a Raspberry Pi, a cheap VPS, or that old laptop gathering dust in your closet. It used to be called “Bitwarden_RS,” but the name was changed (politely, at the official Bitwarden company’s request) to avoid confusion. Same engine, different badge.

The project is fully open-source under the AGPLv3 license and developed in the open on GitHub. If you want to dig deeper, star the repo, read the source, or file a bug, here are the official links:

GitHub repository: github.com/dani-garcia/vaultwarden — source code, releases, issues.
Project wiki: github.com/dani-garcia/vaultwarden/wiki — the definitive documentation, with deep dives on every config flag, reverse-proxy examples, backup recipes, and fail2ban jails.
Docker Hub image: hub.docker.com/r/vaultwarden/server — the official container we’ll be pulling.
Bitwarden (the upstream protocol & clients): bitwarden.com — the company whose API Vaultwarden re-implements.

So when we say selfhosted Vaultwarden, we mean: you run the server, you own the encrypted vault, you control who can sign up, and nobody — not Bitwarden Inc., not Google, not your nosy ISP — gets to peek at your data. The vault is end-to-end encrypted on your device before it ever touches the server. Even you, the server admin, can’t read your users’ passwords. That’s the magic.

Everything Is Encrypted Server-Side — Even the Admin Can’t See It

Read this section twice. This is the single most important thing to understand about Vaultwarden — and the reason it’s safe to self-host in the first place.

When you type your master password into the Bitwarden client, that password never leaves your device. Instead, the client uses it (via PBKDF2 with 600,000 iterations, or Argon2id in newer setups) to derive an encryption key. That key encrypts every single field in your vault — passwords, notes, TOTP secrets, attachments, passkeys, the lot — using AES-256-CBC with an HMAC-SHA256 integrity check. Only the encrypted blob is sent up to the server.

What does this mean in practice?

The server stores ciphertext only. If you peek at the Vaultwarden SQLite database with sqlite3 /data/db.sqlite3, you’ll see rows of base64 gibberish like 2.aGsmaiq…|wQjT…|3kPq…. That’s it. No readable passwords, no readable URLs, nothing.
The administrator (you, or whoever runs the server) cannot read anyone’s vault. Not yours. Not your family’s. Not a colleague’s. The server literally lacks the key. This is called zero-knowledge or end-to-end encryption, and it’s the same model as Signal, ProtonMail, and the official Bitwarden cloud.
A full server compromise leaks ciphertext, not plaintext. Even if an attacker dumps the database, the volume, and the RAM, they walk away with encrypted blobs and a hashed authentication token. They’d still need to brute-force every individual user’s master password to read anything — and with a strong passphrase that’s astronomically expensive.
The /admin panel can manage users, invitations, and config — but cannot view vault contents. It’s an ops console, not a backdoor.

This is genuinely brilliant and genuinely terrifying. Because of zero-knowledge encryption, there is exactly one rule that follows from it, and it has no exceptions:

If you forget your master password, your vault is gone. Forever. There is no recovery.

Let me be very clear about what that means. There is no “forgot password” email. There is no admin override. There is no support ticket that ends with someone resetting it for you. The server can’t help you, because the server cannot read your vault. That’s the whole point. If it could help you, it could help an attacker too.

The admin can delete your account and let you start over with an empty vault. They cannot recover the data inside it. Years of saved passwords, TOTP secrets, passkeys, attachments — all of it instantly worthless ciphertext. You are, in the most literal sense, on your own.

So before you put a single password into Vaultwarden:

Write your master password on paper. A long passphrase like “correct-horse-battery-staple-violet-piano”. Put it in a sealed envelope in a safe, or a fireproof box, or with a trusted relative. Yes, paper. Welcome to 2026.
Set up Emergency Access with a person you’d trust to inherit your digital life. They request access, you have N days to deny, after that they get a one-time copy.
Generate and store a few recovery codes if you enable 2FA on the vault — losing 2FA is just as fatal as losing the master password.
Test your backups. Once a year, restore them to a sandbox container and log in. A backup you’ve never tested is a hope, not a backup.

Get those four things right and zero-knowledge encryption is your friend. Skip them and one bad morning, you’ll be that person on Reddit asking “is there any way to recover my Vaultwarden?” The answer will always be no.

Why Self-Host a Password Manager At All?

Fair question. The cloud version of Bitwarden is excellent, audited, and either free or absurdly cheap. So why bother running your own?

Total control. Your passwords never live on someone else’s hardware. If a cloud provider gets breached (it happens — ask LastPass), you’re not in the blast radius.
No subscription fees. Vaultwarden gives you every paid Bitwarden feature for free: 2FA codes (TOTP), file attachments, organizations, Bitwarden Send, emergency access, the lot.
Privacy. No telemetry, no analytics, no “anonymous usage data.” Just you and your encrypted blob.
Learning. If you’re a tinkerer or sysadmin, running Vaultwarden teaches you Docker, reverse proxies, TLS, and backups — all skills that pay rent in the real world.
Family & team sharing. Spin up an organization, invite the household, share the Wi-Fi password and the Disney+ login. Built-in.

The trade-off? You are now responsible for uptime, backups, and security. If your server dies and you didn’t back up, your vault is gone. So read the backup section twice. I’m not joking.

The Vaultwarden Docker Image: Small, Fast, Friendly

The official Vaultwarden Docker image lives at vaultwarden/server on Docker Hub, and is built straight from the upstream GitHub repository. It’s a single static Rust binary plus the bundled web vault frontend, weighing in at roughly 180 MB on disk. At runtime it uses 30–80 MB of RAM depending on how many users you have. Compare that to the official Bitwarden self-host stack, which routinely chews through 2–3 GB. It’s a tiny footprint.

The image ships with sensible defaults: SQLite storage (great for small deployments), bundled web vault, optional WebSocket support for live sync, and a built-in admin panel you can enable for managing users. For bigger setups, you can switch the storage backend to MySQL/MariaDB or PostgreSQL — both are supported out of the box.

What You Get Out of the Box

End-to-end encrypted vault — passwords, secure notes, identities, credit cards.
TOTP / 2FA codes built into entries (no need for a separate Authy/Google Authenticator).
File attachments — store passport scans, license PDFs, encrypted at rest.
Bitwarden Send — send a password or file to someone via a one-time, self-destructing link.
Organizations & collections — share vault items with family, teams, or per-project.
Emergency access — let a trusted person request access to your vault if you’re, well, hit by a bus.
Admin panel at /admin for invitations, user management, and config.
Web vault served right from the same container — no separate frontend container needed.
Yubikey, Duo, and WebAuthn 2FA support for your login itself.

TOTP, 2FA and Passkeys — The Headline Features

Passwords alone are not enough anymore. Every serious account should have a second factor, and increasingly, no password at all. Vaultwarden is genuinely brilliant at all three: it can store your TOTP codes, protect the vault itself with multiple 2FA methods, and now sync your passkeys across every device. Let’s unpack each.

Built-in TOTP Code Generator (Authenticator Replacement)

TOTP (Time-based One-Time Password) is that six-digit code that changes every 30 seconds — the thing Google Authenticator, Authy, and Microsoft Authenticator show you. The dirty secret? It’s just a tiny shared secret + the current time, run through HMAC-SHA1. Any app can generate them, including Vaultwarden.

When you add a login entry, there’s a field labelled Authenticator Key (TOTP). Paste the otpauth:// URI from a QR code (or just the base32 secret) and from that moment on, the Bitwarden client shows the live 6-digit code right under the username and password, with a little countdown circle. Autofill on the login page fills the password and the TOTP code automatically. No more juggling your phone.

Why this is huge:

One app instead of two. Bin Authy / Google Authenticator. One unlock, all your codes.
Synced across devices. Lose your phone? Your codes are safe in your encrypted vault on every other device.
Backed up automatically. Whatever backs up your vault backs up your TOTP secrets too. (Old-school Authenticator users know that “I lost my phone” used to mean “I lost all my 2FA accounts.”)
Steam Guard support. Vaultwarden also generates Steam’s funky 5-character codes — paste a steam:// URI.

There’s a mild philosophical argument that storing your password and your 2FA code in the same vault defeats some of the point of 2FA. That’s true if your master password gets brute-forced. In practice, with a strong master password + the vault itself protected by 2FA (next section), the combined security is dramatically higher than “weak reused password + SMS code.” Pick your threat model.

2FA for the Vault Itself

“Wait, I can put 2FA on the vault that holds my 2FA codes?” Yes. And you absolutely should. If someone steals your master password, the 2FA prompt at login is your last line of defence. Vaultwarden supports five different second factors, configured per-user from the web vault under Settings → Two-step Login:

Authenticator app (TOTP): the classic — scan a QR with any TOTP app. Use a different app than Vaultwarden itself (e.g. your phone’s built-in iOS/Android authenticator), otherwise you’ve locked yourself out if the vault is down.
Email codes: a 6-digit code mailed to you on login. Requires SMTP configured in the container (SMTP_HOST, SMTP_FROM, etc.).
YubiKey OTP: tap your YubiKey, done. Up to five keys per account. Free YubiKey 5-class hardware tokens are the gold standard.
FIDO2 / WebAuthn: any modern security key (YubiKey, SoloKey, Nitrokey, even your phone’s secure enclave). Phishing-resistant by design — the browser checks the domain for you.
Duo Security: for organisations already paying Cisco for Duo. Push notification to the Duo mobile app.

Bitwarden’s hosted service paywalls YubiKey and Duo behind the Premium tier. On self-hosted Vaultwarden, every single 2FA method is free. That alone covers the €40/year Premium subscription you’d otherwise pay.

A small but important config flag: set EMAIL_2FA_ENABLED=true only if SMTP is reliable. If your mail relay dies, users can’t log in. WebAuthn + a recovery code printed to paper is the lowest-friction combo for most households.

Passkeys — the (Genuinely) Password-Free Future

Passkeys are the new shiny. They’re cryptographic key-pairs (FIDO2/WebAuthn under the hood) stored on your device that let you log in to websites with a fingerprint or face scan — without ever typing a password. The site stores only the public key; the private key never leaves your device. No password to phish, no password to leak, no password to remember. It is genuinely the biggest leap forward in auth in 20 years.

The catch with Apple/Google/Microsoft passkeys: they’re locked to their ecosystems. Use an iPhone? Your passkeys live in iCloud Keychain. Switch to Android? Good luck. This is exactly the kind of vendor lock-in that self-hosting fixes.

Recent Vaultwarden releases (from server v1.32+ paired with the modern Bitwarden clients) implement passkey storage in the vault. That means:

Create a passkey on any site (GitHub, Google, Microsoft, Amazon, Best Buy, hundreds more) and Vaultwarden offers to save it — same dialogue as saving a password.
Sync across every device. The passkey created on your Windows laptop is instantly usable on your Android phone, your iPad, your Linux desktop. One vault, every platform.
End-to-end encrypted in the same vault as your passwords — server admin can’t read them.
No iCloud, no Google Account, no Microsoft Account required. You own the keys.
Log in to Vaultwarden itself with a passkey — the “Login with passkey” flow on the Bitwarden client lets you skip the master password entirely on trusted devices (still 2FA-protected for sensitive operations).

One small caveat: passkey support in Vaultwarden is still maturing. Check the project wiki for the current matrix of which client versions support creation vs. usage vs. login. Browser-extension passkey creation works today on Chrome/Edge/Firefox; mobile creation is rolling out.

Organisations & Sharing — Built for Families and Teams

Here’s where Vaultwarden quietly destroys the competition. On commercial password managers, “share with family” is a paid tier costing €40–60 a year. On self-hosted Vaultwarden, it’s free, unlimited, and frankly more flexible. The mechanism is called Organisations.

An Organisation is a shared vault. You create one (say, “Household”), invite people by email, and any item placed in the org is visible to every member. Inside the org you can carve it up further with Collections — think of them as folders with permissions. So “Streaming” (Netflix, Disney+, Spotify) might be visible to everyone, but “Finance” (bank, broker, tax portal) only to you and your partner. Kids get the streaming collection only.

Invite by email — recipient creates a Bitwarden account on your server and accepts. (Requires SMTP configured; alternatively the admin panel can generate invite links manually.)
Roles — Owner, Admin, Manager, User. Owners and Admins manage members and collections; Users just consume items.
Per-collection permissions — read-only, read/write, or hide-password (members can autofill but can’t view the actual password — useful for shared employee logins).
Move items between personal and org vaults with two clicks. No exporting/importing.
Unlimited orgs, unlimited members, unlimited collections. The official Bitwarden Families plan caps at 6 users; on Vaultwarden, invite the whole village.

Practical patterns we see all the time on instances like vault.myguard.nl:

“Household” org with Streaming / Bills / Wi-Fi / Insurance collections, every adult is a Manager, kids are Users on Streaming only.
“Work” org per team — Ops, Dev, Marketing — each with their own shared service accounts.
“Estate” org — read-only collection shared with a sibling or spouse, containing important account info, insurance policies, and recovery codes. Combined with Emergency Access (below), this is the “if I drop dead” playbook.

Sharing a Single Password or File — Bitwarden Send

Sometimes you don’t want to set up a whole org — you just need to hand one password or one document to someone, securely, once. Maybe it’s the new Wi-Fi password for a houseguest, a tax PDF for your accountant, or a server root password for a contractor doing a one-off job. Email? Insecure. WhatsApp? Sits in chat history forever. SMS? Please, no.

Enter Bitwarden Send. You create a Send (a text snippet or a file up to 500 MB), set the rules, and Vaultwarden hands you a unique URL. The recipient opens the link, sees the content once, and it’s gone. They don’t need a Bitwarden account. They don’t need to install anything. They just click.

Text Sends — paste a password, an API key, a recovery code, a love letter. Up to 1000 characters in a clean shareable URL.
File Sends — attach a PDF, image, ZIP, anything up to 500 MB. End-to-end encrypted; the server stores only the ciphertext.
Expiry & max access count — “expires in 1 hour” or “max 1 view” or both. After that it self-destructs.
Optional access password — recipient must enter a password (which you share via a different channel) to decrypt. Defeats accidental link leakage.
Hide email — by default the Send shows your account email; toggle this off for anonymous shares.
Manual disable — change your mind? Hit “disable” and the link dies immediately, even before expiry.

Enable Sends with SENDS_ALLOWED=true in your compose file (it’s on by default in our example above). On the client, look for the paper-plane icon. The whole flow takes about ten seconds — and you’ll never go back to pasting passwords into WhatsApp again.

Other Features Worth Knowing

Bitwarden Send — encrypted, self-destructing links for sharing a password or file with someone who doesn’t have Bitwarden. Set an expiry, a max view count, an optional access password.
Emergency Access — designate a “trusted contact” who can request access to your vault after a configurable waiting period. Hit-by-a-bus protection without giving anyone live access today.
Organisations & collections — share specific items with family or a team. Granular permissions per collection.
Vault health reports — flags reused passwords, weak passwords, exposed passwords (checked against Have I Been Pwned), and inactive 2FA on sites that support it.
File attachments — encrypted PDFs, passport scans, recovery codes attached to entries.
SSH keys (recent versions) — store and serve SSH private keys via the Bitwarden agent. Goodbye ~/.ssh/id_rsa sitting in plaintext.

A Working Docker Compose Setup

Here’s a minimal, production-leaning docker-compose.yml that you can drop on any Linux box with Docker installed. We use a named volume for persistence, expose only to localhost, and let a reverse proxy handle TLS. (We’ll cover the proxy in a minute — and yes, our WordPress NGINX configuration guide covers the same NGINX patterns we’ll use here.)

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "true"
      ADMIN_TOKEN: "REPLACE_ME_WITH_A_LONG_RANDOM_STRING"
      WEBSOCKET_ENABLED: "true"
      SENDS_ALLOWED: "true"
      EMERGENCY_ACCESS_ALLOWED: "true"
      LOG_LEVEL: "warn"
      ROCKET_PORT: "8080"
    volumes:
      - vw-data:/data
    ports:
      - "127.0.0.1:8080:8080"

volumes:
  vw-data:

Start it with docker compose up -d and you’ve got Vaultwarden listening on port 8080 of localhost. That’s it. Seriously. The whole server is one container.

Generating a Strong Admin Token

The ADMIN_TOKEN protects the /admin panel. Don’t use a memorable password — use the Argon2 hashed form Vaultwarden recommends. Generate it with:

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

Paste a long random passphrase, copy the resulting hash, and stick it in ADMIN_TOKEN. Now even if your env file leaks, your admin panel doesn’t fall over.

Putting Vaultwarden Behind a Reverse Proxy

Vaultwarden must be served over HTTPS. The Bitwarden clients flat-out refuse to talk to a plain-HTTP server (and rightly so). The easiest way is to put NGINX (or our extended Angie build) in front and let Let’s Encrypt handle the certificate. Here’s the relevant NGINX server block:

server {
    listen 443 ssl http2;
    server_name vault.example.com;

    ssl_certificate     /etc/letsencrypt/live/vault.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/vault.example.com/privkey.pem;

    client_max_body_size 525M;  # for big attachments

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # WebSocket for live sync
    location /notifications/hub {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Reload NGINX, run certbot, and you’re done. Your vault is now live on https://vault.example.com — exactly like our reference instance at vault.myguard.nl.

Vaultwarden client setup with Bitwarden browser extension

Setting Up the Client (Browser, Phone, Desktop, CLI)

Here’s the beautiful bit. Vaultwarden is API-compatible with Bitwarden, so you use the official Bitwarden apps — they’re polished, audited, and available on basically everything. You just have to point them at your server instead of Bitwarden’s cloud.

Browser Extension (Chrome, Firefox, Edge, Safari, Brave)

Install the Bitwarden extension from your browser’s store.
Before logging in, click the little cog/settings gear at the top-left.
Find Self-hosted environment and set Server URL to https://vault.example.com (or https://vault.myguard.nl if you’re testing).
Save. Go back. Create your account or log in.

That’s it. The extension now talks exclusively to your server. It will autofill on login pages, generate strong passwords, save new logins automatically, and warn you if you reuse one.

Mobile (iOS & Android)

Install Bitwarden from the App Store / Play Store.
On the very first screen, tap the gear icon (top-left).
Pick Self-hosted and enter your server URL.
Log in. Enable biometrics (FaceID / fingerprint) for instant unlock.
Turn on Autofill Services (Android) or AutoFill Passwords (iOS settings).

From now on, every login screen on your phone offers you the right credentials with a tap.

Desktop App

The Bitwarden desktop app is available for Windows, macOS, and Linux (including a Snap and Flatpak). Same routine: open settings before logging in, pick self-hosted, paste your URL, log in. It also unlocks the browser extension via native messaging — type your master password once, and every browser on the machine unlocks automatically.

Command Line (bw CLI)

For scripts, CI/CD, and terminal addicts, there’s bw:

npm install -g @bitwarden/cli
bw config server https://vault.example.com
bw login you@example.com
export BW_SESSION=$(bw unlock --raw)
bw list items --search github

Now you can pipe secrets into Ansible, GitHub Actions, or anywhere else without baking them into the repo. Combine this with our WordPress hardening plugin for an end-to-end secure deployment workflow.

Hardening Your Self-Hosted Vaultwarden

You wouldn’t leave the front door of your house open just because the safe inside is locked. Same logic applies here. The vault is encrypted, but you still want to harden the perimeter.

Disable open signups (SIGNUPS_ALLOWED=false) the moment your own account is created. Use INVITATIONS_ALLOWED=true for family/team onboarding instead.
Set SHOW_PASSWORD_HINT=false — by default the server will tell anyone who asks “what was the hint for this email?” which is a free username-enumeration gift to attackers.
Put it behind a WAF like our ModSecurity + OWASP CRS NGINX build (see our CRS install guide). Brute-force probes on /admin stop dead at the WAF.
Enable fail2ban on the Vaultwarden log file. There are ready-made jail definitions in the Vaultwarden wiki.
Pin a specific image tag rather than :latest in production, so you don’t get a surprise upgrade at 3 a.m.
Backups, backups, backups. A nightly sqlite3 /data/db.sqlite3 ".backup /backups/$(date +%F).sqlite3" plus a copy of the attachments/, sends/, and rsa_key* files is the bare minimum. Off-site copy too. If you lose rsa_key.pem, every existing 2FA token breaks.
Monitor it. Even a simple healthcheck ping against your domain catches outages before users do.

A Quick Tour of vault.myguard.nl

Want to see what a well-tuned Vaultwarden install actually looks like in the wild? Point your browser at vault.myguard.nl. It’s a real, production Vaultwarden instance running on the exact same Docker + NGINX + ModSecurity stack we ship as packages on this site. Open signups are disabled (sorry — invitation only), but you can see the login page, the TLS configuration, the response headers, and the overall snappiness. It’s a useful reference for what “done right” feels like.

The vault.myguard.nl instance is fronted by our extended Angie build with the OWASP CRS WAF, brotli + zstd compression (see our compression deep dive), HTTP/3, and a strict CSP. The container itself is a stock vaultwarden/server:latest with SQLite. Backups go to encrypted off-site storage every night. Total resource use: under 100 MB of RAM, less than 1% of one CPU core at idle. It’s almost embarrassing how little it costs to run.

Frequently Asked Questions

Is self-hosted Vaultwarden safe?

Yes — provided you keep it updated, run it behind HTTPS, and back it up. Your vault is encrypted on the client before it touches the server using your master password as the key. Even a full server compromise leaks ciphertext, not plaintext passwords. The risk profile is genuinely lower than most cloud password managers, because you’re not in a giant shared blast radius.

Can I use the official Bitwarden apps with Vaultwarden?

Absolutely — and you should. Vaultwarden implements the Bitwarden API, so every official client (browser, mobile, desktop, CLI) works perfectly. Just change the server URL in the client settings before logging in.

What happens if I forget my master password?

Your vault is gone. There is no recovery, no “forgot password” link, no admin override. That’s a feature, not a bug — the server literally cannot decrypt your data, so it can’t help you. Mitigation: write your master password on paper and store it in a safe, or set up Emergency Access with a trusted person, or print an encrypted recovery code. Do this before you forget.

SQLite or MySQL/PostgreSQL?

SQLite is the default and is genuinely fine up to a few hundred users. It’s fast, has zero moving parts, and backs up by copying one file. Only switch to MySQL or PostgreSQL if you have a clustered/HA setup or several thousand active users. Don’t over-engineer this.

How much will hosting cost me?

If you’ve already got a VPS or home server, effectively zero. From scratch, a €3–5/month VPS comfortably runs Vaultwarden for an entire family. The container needs about 50 MB of RAM and barely any CPU. A Raspberry Pi Zero 2 W can run it too, if you’re feeling sporty.

Does Vaultwarden support passkeys (WebAuthn)?

Yes. Recent versions support passkey storage in the vault and WebAuthn as a 2FA method for logging in to Vaultwarden itself. You can store passkeys for sites that support them and sync them across all your devices via your self-hosted vault — the same convenience Apple/Google offer, but on hardware you own.

Should I store TOTP codes in the same vault as my passwords?

It’s a trade-off. Storing them together is wildly more convenient and means losing your phone doesn’t lock you out of 50 accounts. The cost: if someone cracks your master password and bypasses your 2FA, they get everything. Mitigation: use a long, unique master passphrase, enable WebAuthn or a YubiKey as 2FA on the vault itself, and consider keeping a tiny separate authenticator app for your most critical accounts (bank, email, vault recovery).

Passkeys vs TOTP — which one should I use?

If a site offers passkeys, use them. They’re phishing-resistant by design (the browser checks the domain cryptographically), there’s no code to type or screenshot, and they’re faster. TOTP is the fallback when a site hasn’t added passkey support yet — which is still most of the internet. In practice you’ll use both for years. Vaultwarden handles both seamlessly.

Self-Hosted Vaultwarden: Docker Setup, Clients & Full Guide