Password managers are non-negotiable in 2026. Credential-stuffing attacks, phishing campaigns, and third-party breaches mean every service you use is a potential leak. A good vault solves this — one strong master password, unique generated credentials everywhere else, sync across devices, team sharing, TOTP, passkeys.
Bitwarden is the gold standard of open-source password managers. But Bitwarden's official cloud costs €3/user/month for Teams and €5/user/month for Enterprise. For a 10-person team, that's €360-600/year. For families, the Premium Family plan is reasonable, but your vault still lives on someone else's server.
Enter Vaultwarden — an unofficial, API-compatible Bitwarden server written in Rust. It's dramatically lighter than the official server (which ships 11+ microservices and an MSSQL dependency), runs happily in ~256 MB of RAM, and works seamlessly with every official Bitwarden client — iOS, Android, browser extensions, desktop apps, CLI.
This guide shows you how to self-host Vaultwarden in 2026 on a tiny €4.49/mo DanubeData DD Nano VPS, hardened for production use. You'll get a full-featured password vault — Organizations, Collections, Sends, Emergency Access, TOTP, passkeys, file attachments, admin panel — for the cost of a cappuccino per month, with your data living in a GDPR-compliant German data center that you alone control.
What Is Vaultwarden?
Vaultwarden (formerly bitwarden_rs) is an unofficial implementation of the Bitwarden Server API in Rust. It was created by Daniel García in 2018 because the official Bitwarden server at the time was heavy — a full stack of .NET microservices, SQL Server, Redis, Identity, Admin Portal, plus a separate attachments service. Running that on a low-end VPS was painful and memory-hungry.
Vaultwarden re-implements the same REST API that Bitwarden clients speak, but in a single static binary with SQLite (or optionally PostgreSQL/MySQL) as the backing store. The entire server fits in one Docker container, uses ~30-80 MB of RAM at rest (up to ~256 MB under load), and serves the exact same web vault UI that Bitwarden ships.
From the perspective of any Bitwarden client, Vaultwarden is a Bitwarden server. You point the client at your self-hosted URL, log in, and everything — password generator, TOTP codes, secure notes, identities, file attachments, organization sharing, Sends, emergency contacts — works identically.
What You Get for Free with Vaultwarden
- Unlimited users, vaults, and organizations — no per-seat pricing
- Premium features unlocked — TOTP codes, file attachments, emergency access, Yubikey/FIDO2/WebAuthn, Sends, password health reports
- Organizations with Collections — share passwords across teams/families with granular per-collection access
- Admin panel — user management, invitations, org management, backup settings
- Full client compatibility — works with official Bitwarden iOS/Android/browser/desktop/CLI clients
- Passkeys & WebAuthn support — log in without a master password on trusted devices
- Self-registration control — disable signups, invite-only mode, or domain allowlist
Why Self-Host Instead of Paying Bitwarden Cloud?
Three reasons: cost, sovereignty, and scope.
| Plan | Cost (10 users) | Annual Cost | Data Location | TOTP / Attachments |
|---|---|---|---|---|
| Bitwarden Free | €0 (no org sharing) | €0 | Bitwarden US | No |
| Bitwarden Premium (individual) | €0.83/user/mo | €99.60 (10×€9.96) | Bitwarden US/EU | Yes |
| Bitwarden Teams | €3/user/mo | €360/yr | Bitwarden US/EU | Yes |
| Bitwarden Enterprise | €5/user/mo | €600/yr | Bitwarden US/EU | Yes |
| Vaultwarden on DanubeData DD Nano | €4.49/mo (flat, unlimited users) | €53.88/yr | Falkenstein, Germany (GDPR) | Yes, everything unlocked |
The math is brutal. A 10-seat Bitwarden Teams license is €360/year. The exact same functionality — arguably more, since you get premium features for every user — runs on a DanubeData DD Nano for €53.88/year. That's a ~€306/year saving for a small team, scaling to €540+/year saved for 15-user setups, with no per-seat cost creep as you grow.
And cost is only half the story:
- Data sovereignty — your encrypted vault lives on a server you control, in a German data center, never touching a US hyperscaler. If you're a GDPR-minded European SME or a privacy-first family, this is the whole point.
- No vendor lock-in — export at any time, migrate anywhere, nothing phones home.
- Full feature set for everyone — Bitwarden locks TOTP, attachments, and emergency access behind Premium. Vaultwarden unlocks all of them for every user you create.
- Audit trail in your hands — admin panel shows active sessions, invitations, orgs, attachments. No third-party dashboards.
Security Considerations (Read This First)
Self-hosting a password manager means you are responsible for its security. The good news: Vaultwarden stores your vault using client-side AES-256 encryption derived from your master password via PBKDF2 or Argon2id — even if an attacker steals the SQLite database file, without your master password they only have ciphertext.
But you still need to treat the server like the sensitive piece of infrastructure it is:
- HTTPS is mandatory. Bitwarden clients refuse to talk to HTTP endpoints on anything except localhost. Use Caddy or Traefik with automatic Let's Encrypt.
- Keep the admin panel off the public internet or gate it behind an ADMIN_TOKEN + IP allowlist.
- Disable open signups as soon as your accounts are created. Otherwise, anyone on the internet can register and start probing.
- Force Argon2id for KDF. PBKDF2 is fine, but Argon2 is memory-hard and much tougher against GPU cracking.
- Enable 2FA on your master account — TOTP, Yubikey, or passkeys.
- Run Fail2ban against the Vaultwarden auth logs to block brute-force attempts.
- Backup the SQLite file + attachments regularly and offsite. Losing your vault database is losing everyone's passwords.
- Patch promptly. Vaultwarden releases roughly monthly; subscribe to GitHub releases.
A properly configured Vaultwarden instance is, realistically, more secure than a shared-tenant cloud service — smaller attack surface, no one else's breach can leak your data, and you control patch timing. But "properly configured" is doing a lot of work in that sentence. The walkthrough below gets you there.
Hardware Sizing
Vaultwarden is famously light. The official Docker image is ~45 MB. A running instance with a dozen users idles at ~30-60 MB of RAM and spikes to ~150-256 MB during sync or when the web vault is in use. CPU usage is negligible outside of Argon2 password hashing (which happens client-side anyway — the server just verifies).
| Users | Recommended VPS | DanubeData Plan | Monthly Cost |
|---|---|---|---|
| 1-15 users (family / small team) | 2 vCPU, 2 GB RAM, 40 GB NVMe | DD Nano | €4.49/mo |
| 15-50 users (SME) | 2 vCPU, 4 GB RAM, 60 GB NVMe | DD Micro | €7.49/mo |
| 50-200 users | 4 vCPU, 8 GB RAM, 120 GB NVMe | DD Small / Medium | €14.99-24.99/mo |
The DD Nano (2 vCPU / 2 GB RAM / 40 GB NVMe) at €4.49/mo is the sweet spot for Vaultwarden. It has comfortable headroom for the container, Caddy, Fail2ban, and a daily backup cron. You'd need well over 50 concurrent syncs per second to outgrow it.
Step 1: Provision a DanubeData DD Nano
- Sign up at danubedata.ro (you get a €50 signup credit, which covers ~11 months of Vaultwarden hosting for free).
- Click Create VPS.
- Choose Ubuntu 24.04 LTS as the base image.
- Select DD Nano (€4.49/mo).
- Pick Falkenstein (fsn1) as the datacenter.
- Add your SSH public key and click Deploy. The VPS is ready in < 60 seconds.
- Note the IPv4 (and IPv6) address.
Initial Hardening
# SSH in
ssh root@YOUR_VPS_IP
# Update everything
apt update && apt upgrade -y
# Create a non-root user
adduser --disabled-password --gecos "" vault
usermod -aG sudo vault
mkdir -p /home/vault/.ssh
cp /root/.ssh/authorized_keys /home/vault/.ssh/
chown -R vault:vault /home/vault/.ssh
chmod 700 /home/vault/.ssh
chmod 600 /home/vault/.ssh/authorized_keys
# Disable root SSH and password auth
sed -i 's/^#?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh
# Firewall
apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable
# Hostname
hostnamectl set-hostname vault
Step 2: Install Docker
# Official Docker installer
curl -fsSL https://get.docker.com | sh
# Compose plugin
apt install -y docker-compose-plugin
# Let the vault user run Docker
usermod -aG docker vault
# Enable on boot
systemctl enable docker
systemctl start docker
# Verify
docker --version
docker compose version
Log out and back in as the vault user for the group change to take effect:
exit
ssh vault@YOUR_VPS_IP
Step 3: Point DNS at Your VPS
Create an A (and AAAA if you have IPv6) record for the subdomain you'll use — e.g. vault.yourdomain.com:
Type: A
Name: vault
Value: YOUR_VPS_IPV4
TTL: 300
Type: AAAA
Name: vault
Value: YOUR_VPS_IPV6
TTL: 300
Verify propagation before continuing — Let's Encrypt will fail if DNS hasn't converged:
dig vault.yourdomain.com +short
# should echo your VPS IP
Step 4: Deploy Vaultwarden with Docker Compose + Caddy
Caddy is the simplest way to get automatic HTTPS. Two services, one file.
# Create the stack directory
mkdir -p /opt/vaultwarden
cd /opt/vaultwarden
# Generate an admin token (long random string, keep this safe)
ADMIN_TOKEN=$(openssl rand -base64 48)
echo "ADMIN_TOKEN=$ADMIN_TOKEN" | tee admin_token.txt
# Hash it for Vaultwarden (Argon2, recommended since v1.32)
HASHED_TOKEN=$(docker run --rm vaultwarden/server:latest /vaultwarden hash --preset owasp <<< "$ADMIN_TOKEN" 2>/dev/null | tail -1)
echo "Hashed admin token: $HASHED_TOKEN"
Save the plaintext admin token somewhere safe — you'll use it to log into the admin panel. The hashed version is what goes in the environment file.
docker-compose.yml
cat > docker-compose.yml << 'EOF'
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
env_file: .env
volumes:
- ./data:/data
networks:
- vault-net
caddy:
image: caddy:2-alpine
container_name: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy-data:/data
- caddy-config:/config
depends_on:
- vaultwarden
networks:
- vault-net
networks:
vault-net:
volumes:
caddy-data:
caddy-config:
EOF
.env file
cat > .env << 'EOF'
# ===== CORE =====
DOMAIN=https://vault.yourdomain.com
ROCKET_ADDRESS=0.0.0.0
ROCKET_PORT=80
# ===== ADMIN PANEL =====
# Paste the Argon2 hashed admin token you generated above
ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$...REPLACE_ME...'
# ===== SIGNUPS =====
# Disable public signups; invite via admin panel or SMTP
SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
INVITATIONS_ALLOWED=true
# Optional: whitelist email domains that can self-register
# SIGNUPS_DOMAINS_WHITELIST=yourcompany.com,yourdomain.com
# ===== WEB VAULT =====
WEB_VAULT_ENABLED=true
# ===== PASSWORD HASHING =====
# Argon2id is the 2026 recommendation for new installs
PASSWORD_HINTS_ALLOWED=false
PASSWORD_ITERATIONS=600000
# ===== SECURITY =====
# Require email verification for new invitations
REQUIRE_DEVICE_EMAIL=true
# Disable the /icons/ endpoint that fetches favicons (leaks traffic)
DISABLE_ICON_DOWNLOAD=true
# Show password hints only via email (not on login screen)
SHOW_PASSWORD_HINT=false
# ===== SMTP (required for invitations & password reset) =====
SMTP_HOST=smtp.yourprovider.com
SMTP_FROM=vault@yourdomain.com
SMTP_FROM_NAME=Vaultwarden
SMTP_PORT=587
SMTP_SECURITY=starttls
SMTP_USERNAME=vault@yourdomain.com
SMTP_PASSWORD=your-smtp-password
# ===== LOGGING =====
LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=warn
EXTENDED_LOGGING=true
# ===== PUSH NOTIFICATIONS (optional) =====
# Register at https://bitwarden.com/host/ for mobile push
# PUSH_ENABLED=true
# PUSH_INSTALLATION_ID=your-id
# PUSH_INSTALLATION_KEY=your-key
EOF
chmod 600 .env
Caddyfile
cat > Caddyfile << 'EOF'
vault.yourdomain.com {
# Security headers
header {
Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
X-Frame-Options "SAMEORIGIN"
X-Content-Type-Options "nosniff"
Referrer-Policy "same-origin"
Permissions-Policy "accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()"
-Server
}
encode gzip zstd
# Block the admin panel from the public internet
# Remove this block or add specific IPs to allow admin access
@admin path /admin*
handle @admin {
@allowed remote_ip 203.0.113.0/24 # your office IP range
handle @allowed {
reverse_proxy vaultwarden:80
}
respond "Forbidden" 403
}
# WebSocket endpoint for live sync
reverse_proxy /notifications/hub vaultwarden:3012
reverse_proxy /notifications/hub/negotiate vaultwarden:80
# Everything else
reverse_proxy vaultwarden:80
}
EOF
Replace 203.0.113.0/24 with your actual office/home IP range, or remove the allowlist entirely if you want admin access from anywhere (the ADMIN_TOKEN still protects it, but IP allowlisting is belt-and-braces).
Launch
# Start the stack
docker compose up -d
# Watch logs until Vaultwarden reports "Rocket has launched"
docker compose logs -f vaultwarden
# Ctrl+C when you see the startup banner
# Check health
docker compose ps
Visit https://vault.yourdomain.com — you should see the Bitwarden web vault login page, served with a valid Let's Encrypt certificate.
Step 5: Create Your First Account
Because you set SIGNUPS_ALLOWED=false, you need to invite yourself via the admin panel first:
- Go to
https://vault.yourdomain.com/admin - Enter the plaintext ADMIN_TOKEN you saved earlier
- Click Invite User, enter your email
- Open the invitation email, click the link, set a strong master password
- Immediately go to Account Settings → Security → Two-step Login and enable TOTP (Authenticator) and/or a passkey
Force Argon2id KDF
In your user settings, change the Encryption Key Settings (KDF):
- KDF algorithm: Argon2id
- Memory: 64 MiB (or 128 MiB if you have a strong device)
- Iterations: 3
- Parallelism: 4
This makes brute-forcing your master password dramatically harder than the default PBKDF2 — the OWASP 2023+ guidance.
Step 6: Install Bitwarden Clients
The official Bitwarden clients all work with Vaultwarden — you just point them at your self-hosted URL instead of bitwarden.com:
- Browser extension (Chrome/Firefox/Edge/Safari): After install, click Settings → Self-hosted, enter
https://vault.yourdomain.comin the "Server URL" field, then log in. - Mobile (iOS / Android): On the login screen, tap the gear icon at the top-left → Self-hosted environment, set Server URL, save, log in.
- Desktop (Windows / macOS / Linux): Same pattern — gear icon → self-hosted → Server URL.
- Bitwarden CLI:
bw config server https://vault.yourdomain.com && bw login
Everything else — password generator, TOTP, attachments, Sends, passkeys, autofill — works identically to the official cloud.
Step 7: Set Up Organizations for Team/Family Sharing
Organizations are how Vaultwarden shares passwords across multiple users. Each Organization has:
- Members — users who belong to the org
- Collections — groups of shared vault items (e.g. "Infrastructure", "SaaS Logins", "Family Bank")
- Permissions — per-collection read/edit/delete, per-member owner/admin/user/manager roles
Create an Organization
- In the web vault, click New organization
- Give it a name (e.g. "Acme Corp" or "Smith Family")
- Leave "Billing" fields blank — those only matter for Bitwarden cloud
- Go to Members → Invite Member, enter email addresses; invitees get SMTP invitation links
- Go to Collections → New Collection, create "Shared Logins"
- Assign members to collections with appropriate permission levels
Enterprise Policies (Optional)
The Organization settings page includes policies to enforce MFA on all members, require master password resets, ban vault export, and more. These are enabled for all Vaultwarden users (no Premium required).
Step 8: Install Fail2ban
Vaultwarden logs failed logins. Fail2ban can parse those logs and ban abusive IPs at the firewall level.
# Install
sudo apt install -y fail2ban
# Vaultwarden filter
sudo tee /etc/fail2ban/filter.d/vaultwarden.conf > /dev/null << 'EOF'
[INCLUDES]
before = common.conf
[Definition]
failregex = ^.*Username or password is incorrect. Try again. IP: <ADDR>. Username:.*$
ignoreregex =
EOF
# Vaultwarden admin-panel filter
sudo tee /etc/fail2ban/filter.d/vaultwarden-admin.conf > /dev/null << 'EOF'
[INCLUDES]
before = common.conf
[Definition]
failregex = ^.*Invalid admin token. IP: <ADDR>.*$
ignoreregex =
EOF
# Jail
sudo tee /etc/fail2ban/jail.d/vaultwarden.local > /dev/null << 'EOF'
[vaultwarden]
enabled = true
port = 80,443,8081
filter = vaultwarden
logpath = /opt/vaultwarden/data/vaultwarden.log
maxretry = 5
bantime = 14400
findtime = 14400
action = iptables-allports[name=vaultwarden]
[vaultwarden-admin]
enabled = true
port = 80,443
filter = vaultwarden-admin
logpath = /opt/vaultwarden/data/vaultwarden.log
maxretry = 3
bantime = 86400
findtime = 14400
action = iptables-allports[name=vaultwarden-admin]
EOF
sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden
Step 9: Automated Offsite Backups to S3
Your vault is only as safe as your backups. Losing /opt/vaultwarden/data/db.sqlite3 means losing every password for every user on the server. A nightly S3 backup costs cents per month and buys peace of mind.
DanubeData offers S3-compatible object storage at €3.99/mo for 1 TB, so the total cost of the Vaultwarden stack including offsite backup is still under €10/month.
Install rclone and Configure S3
curl https://rclone.org/install.sh | sudo bash
# Interactive config — use DanubeData S3 credentials
rclone config
# Choose: n (new remote), name: danubedata, storage: s3, provider: Other
# Endpoint: https://s3.danubedata.ro
# Access key: from DanubeData dashboard → Storage → Access Keys
# Secret key: same place
Backup Script
sudo tee /opt/vaultwarden/backup.sh > /dev/null << 'EOF'
#!/bin/bash
set -euo pipefail
BACKUP_DIR="/opt/vaultwarden/backups"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
DATA_DIR="/opt/vaultwarden/data"
S3_BUCKET="yourcompany-vaultwarden-backups"
mkdir -p "$BACKUP_DIR"
echo "=== Vaultwarden backup: $DATE ==="
# 1. SQLite online backup (safe even while Vaultwarden is running)
docker compose -f /opt/vaultwarden/docker-compose.yml exec -T vaultwarden
sqlite3 /data/db.sqlite3 ".backup '/data/db.sqlite3.bak'"
cp "$DATA_DIR/db.sqlite3.bak" "$BACKUP_DIR/db-$DATE.sqlite3"
rm -f "$DATA_DIR/db.sqlite3.bak"
# 2. Copy attachments, sends, and config
tar -czf "$BACKUP_DIR/vaultwarden-$DATE.tar.gz"
-C /opt/vaultwarden
--exclude="data/db.sqlite3"
--exclude="data/vaultwarden.log"
--exclude="data/icon_cache"
data/ docker-compose.yml .env Caddyfile
# 3. Bundle the SQLite backup into the archive
tar -rzf "$BACKUP_DIR/vaultwarden-$DATE.tar.gz"
-C "$BACKUP_DIR" "db-$DATE.sqlite3"
rm "$BACKUP_DIR/db-$DATE.sqlite3"
# 4. Encrypt with GPG (recommended — uploads encrypted tarball)
gpg --symmetric --cipher-algo AES256
--passphrase-file /opt/vaultwarden/.backup-passphrase
--batch --yes
-o "$BACKUP_DIR/vaultwarden-$DATE.tar.gz.gpg"
"$BACKUP_DIR/vaultwarden-$DATE.tar.gz"
rm "$BACKUP_DIR/vaultwarden-$DATE.tar.gz"
# 5. Upload to DanubeData S3
rclone copy "$BACKUP_DIR/vaultwarden-$DATE.tar.gz.gpg"
"danubedata:$S3_BUCKET/$(date +%Y/%m)/"
--checksum --s3-no-check-bucket
# 6. Rotate — keep 14 days locally, S3 lifecycle handles the rest
find "$BACKUP_DIR" -name "vaultwarden-*.tar.gz.gpg" -mtime +14 -delete
echo "=== Backup OK: $DATE ==="
EOF
sudo chmod +x /opt/vaultwarden/backup.sh
# Backup passphrase (generate + store in a password manager, NOT only on this server)
openssl rand -base64 48 | sudo tee /opt/vaultwarden/.backup-passphrase
sudo chmod 600 /opt/vaultwarden/.backup-passphrase
# Test it
sudo /opt/vaultwarden/backup.sh
# Schedule nightly at 03:15
(sudo crontab -l 2>/dev/null; echo "15 3 * * * /opt/vaultwarden/backup.sh >> /var/log/vaultwarden-backup.log 2>&1") | sudo crontab -
Critical: store the GPG passphrase somewhere OTHER than this server — ideally in another password manager, a printed copy in a safe, or a second device. If your server is lost and the passphrase is lost with it, your encrypted backups are inert.
Test Your Restore
Backups you haven't tested are wishes, not backups. At least once a quarter, spin up a throwaway VM, copy down the latest encrypted backup, decrypt it, and verify the SQLite database opens cleanly:
gpg --decrypt vaultwarden-2026-04-19_03-15-00.tar.gz.gpg > restore.tar.gz
tar -tzf restore.tar.gz | head
sqlite3 restore-data/db.sqlite3 ".tables" # should list users, ciphers, etc.
Step 10: Ongoing Maintenance
Update Vaultwarden
cd /opt/vaultwarden
docker compose pull
docker compose up -d
docker image prune -f
Run this monthly, or subscribe to the Vaultwarden GitHub releases feed. Updates are nearly always zero-downtime.
Monitor
# Container health
docker compose ps
docker stats --no-stream
# Disk usage (SQLite DB grows slowly with each cipher + attachment)
du -sh /opt/vaultwarden/data
# Fail2ban activity
sudo fail2ban-client status vaultwarden
# Live tail
docker compose logs --tail=100 -f vaultwarden
Admin Panel Checks
Log into /admin monthly and review:
- Pending invitations that were never accepted — revoke
- Users who haven't logged in for >90 days — audit/remove
- Organization membership — confirm each user still needs the role
- Attachment sizes — enforce limits if growth is unexpected
Cost Comparison: The Big Picture
| Scenario | Bitwarden Cloud | Vaultwarden on DanubeData | Annual Savings |
|---|---|---|---|
| Family of 6 | €3.33/mo (Families plan) = €40/yr | €4.49/mo = €53.88/yr | -€14 (sovereignty wins) |
| 10-person startup (Teams) | €3/user/mo = €360/yr | €4.49/mo + €3.99/mo S3 = €101.76/yr | ~€258/yr |
| 25-person SME (Teams) | €3/user/mo = €900/yr | €4.49/mo + €3.99/mo S3 = €101.76/yr | ~€798/yr |
| 50-person company (Enterprise) | €5/user/mo = €3,000/yr | €7.49/mo + €3.99/mo S3 = €137.76/yr | ~€2,862/yr |
For any team of 5+ users, self-hosting Vaultwarden pays for itself in the first month and saves hundreds to thousands of euros per year — while keeping your encrypted vault in a German data center you trust.
FAQ
Is Vaultwarden actually different from Bitwarden?
Functionally, no. Vaultwarden re-implements the Bitwarden Server REST API so every official Bitwarden client thinks it's talking to a standard Bitwarden server. The web vault UI is the same. Sync, autofill, password generation, TOTP, passkeys, Sends, Emergency Access — all work identically. The difference is under the hood: Rust instead of .NET, SQLite instead of MSSQL, one binary instead of eleven microservices. Not Bitwarden-affiliated — it's a separate open-source project under AGPL-3.0.
Will official Bitwarden clients keep working with Vaultwarden?
Yes. Vaultwarden tracks the Bitwarden API closely; when Bitwarden ships API changes (e.g. new MFA flows), Vaultwarden updates within days. Since 2020, the project has shipped consistent monthly releases. The one caveat: some very new Bitwarden features (e.g. Secrets Manager, specific Enterprise SSO flows) may lag or never land. For password-manager use cases, compatibility has been rock-solid.
Has Vaultwarden been security audited?
Vaultwarden itself has not had a formal third-party audit. However, the cryptography is not custom — vaults are encrypted client-side by Bitwarden's audited clients using AES-256-CBC with HMAC-SHA-256, keys derived from your master password via PBKDF2 or Argon2id. The server only stores ciphertext. That means server-side bugs can cause availability problems but cannot directly leak your secrets. The Rust code is small (~40k LOC), open-source, and widely deployed — many eyes have looked at it. For paranoid use cases, pin a release tag, review diffs before upgrading, and run behind a reverse proxy with WAF rules.
How often should I back up?
Nightly at minimum. The SQLite database is small (tens of MB for most deployments) and the backup takes seconds. For a high-write team environment, hourly online backups are cheap. The key metric is your RPO (recovery point objective) — how much data loss can you tolerate? 24 hours is fine for most teams; financial or compliance-heavy scenarios may want 1-hour intervals. Don't forget to test restore at least quarterly.
Is self-hosting Vaultwarden GDPR-compliant?
Running Vaultwarden on a DanubeData VPS in Falkenstein means all vault data stays in Germany under GDPR jurisdiction, never crossing the Atlantic to US cloud providers. You are the data controller; DanubeData is the infrastructure provider (processor) under a standard DPA. For an internal employee password manager, that's typically the simplest GDPR posture available — fewer third parties than using Bitwarden Cloud, and no Schrems II trans-Atlantic transfer concerns.
What happens if my server dies?
Your users can't sync until it's back, but their local clients still have their cached vault — they can read and use existing passwords offline. Restore from your latest encrypted backup onto a new DanubeData VPS (or any VPS), update DNS, and clients reconnect automatically. The whole process takes ~15 minutes if you've scripted it. This is why offsite backups with tested restore procedures are non-negotiable.
Can I migrate from Bitwarden Cloud to Vaultwarden?
Yes, and it's painless. In Bitwarden Cloud, go to Tools → Export vault, download the encrypted JSON export. Stand up Vaultwarden, create your account, install a Bitwarden client pointed at your new server, log in, go to Tools → Import data, select "Bitwarden (json)" and upload your export. All ciphers, folders, Organizations (if you re-create them first), and attachments come over. Repeat for each user on your team.
Should I use PostgreSQL/MySQL instead of SQLite?
Probably not. SQLite is the default and handles hundreds of concurrent users comfortably because Vaultwarden's workload is low-volume writes and frequent short reads — exactly what SQLite excels at. The MBCS (MySQL/MariaDB or PostgreSQL) backends exist for specific HA scenarios, but they add operational overhead (backup strategy, connection pooling, replication) without meaningful benefit for <200-user deployments. Stick with SQLite unless you have a concrete reason.
Get Started Today
A password manager is the single highest-ROI piece of security infrastructure any team or family can deploy. For €4.49/month — less than the cost of one Bitwarden Teams seat — you can run a fully-featured, self-hosted, GDPR-friendly Vaultwarden instance with unlimited users, every premium feature unlocked, and your data living in a German data center you control.
- Sign up for DanubeData and claim your €50 signup credit (that covers ~11 months of hosting free)
- Deploy a DD Nano VPS (€4.49/mo, Ubuntu 24.04, Falkenstein)
- Add S3 object storage (€3.99/mo, 1 TB) for encrypted offsite backups
- Follow the Docker Compose walkthrough above
- Invite your team, retire your old password manager, pocket the savings
Why DanubeData for Vaultwarden:
- €4.49/mo DD Nano is a perfect fit — 2 GB RAM is ~8× what Vaultwarden needs
- NVMe storage keeps SQLite reads instant even with thousands of ciphers
- Falkenstein, Germany — GDPR-native, no Schrems II headaches
- 20 TB included traffic (sync is light, you'll never hit it)
- Built-in S3 for encrypted backups in the same datacenter
- IPv6 included — future-proof from day one
- €50 signup credit — the first year is effectively free
→ Deploy your Vaultwarden VPS on DanubeData
Questions about the setup? Reach out — we're happy to help you migrate from Bitwarden Cloud or troubleshoot your deployment.