Vaultwarden self hosts your own Bitwarden vault

why your password manager is the one thing worth self-hosting

think about what's actually in your password vault. bank logins, email recovery codes, that one spreadsheet-turned-vault-entry with your social security number in the notes field. it's the single highest-value target on your entire digital life, and normally you're trusting a third party's cloud to hold all of it. vaultwarden flips that. it's a lightweight, unofficial server that speaks the exact same protocol as bitwarden, so every official bitwarden app, browser extension, and cli tool connects to it like it's the real thing. except the real thing is a container sitting on your own hardware.

what vaultwarden actually is

bitwarden's official self-hosted server is written in .net and wants a decent chunk of ram and a small army of docker containers to run. vaultwarden is a full reimplementation written in rust, and it does the same job in one tiny container that'll run comfortably on a raspberry pi. same encryption model, same clients, same features like org support and totp storage. the only thing that changes is where your encrypted vault data physically lives.

the docker compose setup, broken down

the whole deployment is basically two lines of config:

# docker-compose.yml
image: vaultwarden/server:latest
volumes: [ ./vw-data:/data ]

the image line pulls the vaultwarden server image, the one that implements the bitwarden api. the volumes line is the important part for defenders: it maps a folder on your host, ./vw-data, into the container's /data directory. that folder is where your encrypted vault database, attachments, and config actually get written to disk. this matters because it means your data survives container restarts, updates, even a full container rebuild. if you ever nuke the container, that folder is your entire vault. back it up like it's a house key, because it kind of is.

then you bring it up with:

docker compose up -d

the up starts the service defined in your compose file, and -d runs it detached, meaning it keeps running in the background after you close the terminal. one command, one container, vault online.

why you still need caddy or something like it

vaultwarden by default talks plain http on a local port. that's fine for testing on localhost, it is not fine for anything that touches a network, including your own lan. bitwarden clients require https to function properly anyway, browser extensions will straight up refuse an insecure connection for sensitive vault data. this is where a reverse proxy like caddy earns its keep. caddy sits in front of vaultwarden, automatically requests and renews a tls certificate for your domain, and forwards encrypted traffic back to the container over http internally. the result is your vault is reachable at a proper https url, cert managed automatically, no manual renewal, no expired-cert lockouts at 2am.

if you're only ever accessing this from inside your home network, you can still put caddy in front and use a local ca or a service like tailscale to get valid certs without exposing anything to the open internet.

the actual security tradeoff you're making

self-hosting your vault means you're no longer trusting bitwarden's cloud infrastructure, but you are now the one responsible for patching, backups, and access control. that's not a downside if you take it seriously, it's a downside if you set this up once and forget it exists. a few non-negotiables: enable a strong master password, since vaultwarden still relies on client-side encryption doing its job. keep the container image updated, since it's your job now, not bitwarden's. restrict access to the admin panel, vaultwarden ships with an admin token setting and if you leave it disabled or use a weak token, anyone who finds your instance can manage users on it. and never expose port 80 or the raw vaultwarden port directly to the internet, always go through the reverse proxy.

the takeaway

vaultwarden is one of those rare self-hosted projects where the effort-to-value ratio is stupidly good. one small container, one compose file, and you've moved your highest-trust data off someone else's cloud and onto hardware you control. the tradeoff is real though: you own the uptime, you own the patching, you own the backups. treat that ./vw-data folder like it's your literal keychain, put https in front of it, keep the image updated, and you've got a password manager that answers to nobody but you.