Self-Host Vaultwarden on Proxmox

I used 1Password for years, then moved to Apple Passwords once it became a standalone app. It was already on all of my Apple devices and it meant one less subscription. But I also use Linux and want the same access to my passwords there, and I'd like to keep secure notes (passports, for example), which Apple Passwords doesn't support.

So I moved to Bitwarden, with my own server: Vaultwarden, an alternative Bitwarden server written in Rust, running in my homelab. Everyone in the family uses the normal Bitwarden apps, and features that need a paid licence on a self-hosted Bitwarden server (built-in verification codes, attachments, emergency access) are included.

This is the written companion to the video, with every command to copy and paste and the details that didn't fit on camera. The Caddyfile, the token file, the service override and the Tailscale policy are also in nightlyventures/configs.

Two containers on Proxmox. Caddy is the HTTPS entry point with a real certificate; Vaultwarden stores the vault. Bitwarden clients connect to Caddy, which passes requests on to Vaultwarden.

Every client uses the same address. I'm using https://vault.nightlyventures.dev; replace it with your own hostname throughout. You need:

CADDY_LAN_IP and VAULTWARDEN_LAN_IP below are placeholders for the two container addresses. Caddy runs Debian (systemd); Vaultwarden runs Alpine (OpenRC), so the service commands differ per container.

Open the Proxmox VE Community Scripts, find Vaultwarden and, as with any of these scripts, read what it does before you paste it into your Proxmox shell. The script offers Debian or Alpine:

I picked Alpine with the Default Install. When it finishes, Vaultwarden is running with a self-signed certificate, so your browser won't trust it yet. Note its IP address.

Run the Caddy helper script in the same way: Debian, Default Install. When it asks whether to install the xCaddy add-on, don't answer yet. xcaddy compiles a custom Caddy build, and the default container only has 512 MB of RAM. In a second tab, go to the Caddy container → Resources → Memory and set it to 1024 MiB. You can do this while the container is running. Then choose Yes.

Note Caddy's IP address too, and reserve both addresses in your router's DHCP settings. We'll use them in the configuration, so they shouldn't change later.

To get a real certificate, Caddy has to prove that you own the domain. With the DNS challenge, Caddy creates a temporary DNS record through your DNS provider's API, so you don't need to open any ports. That requires the provider's plugin; for Cloudflare that's caddy-dns/cloudflare.

You can also download a ready-made binary with your plugins from the Caddy download page, which supports pretty much every major DNS provider. I build it with just the plugin I need. In the Caddy console, as root:

You should see dns.providers.cloudflare in the output. The dpkg-divert and update-alternatives lines follow Caddy's own instructions for custom builds on Debian: the packaged binary moves aside, your build gets priority, and a package update (including the helper script's own update) no longer replaces your build with one that lacks the plugin. To switch between the two binaries later, run update-alternatives --config caddy and restart Caddy.

In the Cloudflare dashboard, create an API token with these permissions, limited to the zone that contains your vault hostname:

The steps are similar for other DNS providers. Store the token in a separate file that only root can read. That way you can show or share your Caddyfile without exposing the token:

Add one line with your token:

Then make the file available to the Caddy service:

Add this above the line that says everything below will be discarded:

The last two lines are an addition to what you see in the video, and I recommend them. The stock Caddy service starts with --environ, which prints every environment variable to the system log on each start, including your token. Overriding ExecStart without that flag keeps the token out of journalctl, and out of any log you paste into a forum.

Now replace the default example in /etc/caddy/Caddyfile with this site block, which refers to the token by name:

Restart Caddy so it picks up the new environment:

Caddy will handle HTTPS, and it talks to Vaultwarden over plain HTTP on port 8000 inside your network. So first make sure that only Caddy can reach that port. In Proxmox, on the Vaultwarden container → Firewall:

Enabling the container's firewall also blocks other incoming traffic to the Vaultwarden container, such as SSH and ping, because a container's default input policy is DROP. That's fine here: we use the Proxmox console. Never forward port 8000 on your router.

In the Vaultwarden console, open /etc/conf.d/vaultwarden:

Remove the export ROCKET_TLS=... line and make sure these are set:

The DOMAIN line isn't in the video, where I set the same value later in the admin panel. Setting it now is better: two-step login with a hardware key (WebAuthn) is tied to this address, so it should be correct before you register a key.

To check the firewall, run curl http://VAULTWARDEN_LAN_IP:8000/alive from the Caddy console (it should answer) and from another machine on your network (it should time out).

Back in the Caddy console, add one line to the site block in /etc/caddy/Caddyfile:

Validate and restart:

Caddy now has a certificate for the vault address, but your devices at home still need to find Caddy when they look up that name. Add a local DNS A record:

On UniFi that's Policy Engine → Create New Policy → DNS → Host (A). Pi-hole and AdGuard Home have equivalent local DNS settings.

Open https://vault.nightlyventures.dev on a device at home. It should load the vault without a certificate warning. If it doesn't resolve, check that the device actually uses your local DNS: a VPN, manually configured DNS or the browser's secure DNS setting can bypass it.

Create your account in the web vault. Use a long master password and keep a safe copy. I also keep a physical copy: write it down or print it, and put it in a binder.

Before you add any passwords, turn on two-step login under Settings → Security → Two-step login. You can use a hardware key or an authenticator you already have; I like the separate Bitwarden Authenticator app. Verification codes for other websites can live in your vault, but the code for the vault itself has to live outside it, or you can't get in.

You won't need that code every time you unlock the vault, only when you log in, for example on a new device. Keep a paper copy of the recovery code too: together with your master password, it gets you back in if you lose your authenticator.

Install the Bitwarden app, choose Self-hosted as the server and enter your vault address. Then log in with your account and the code from your authenticator.

On iOS 26 and later, Apple Passwords can hand credentials directly to another password manager:

This uses the Credential Exchange Protocol, an industry standard from the FIDO Alliance that a growing number of password managers support. In my test, passwords, passkeys and verification codes came across, and the imported passkey and codes worked afterwards. The export is a copy: Apple Passwords keeps its entries, so keep using it as a fallback until you've checked everything.

Right now, Bitwarden supports CXP imports in its iPhone and Android apps, not yet on the Mac. If you can't use CXP, export a CSV from Passwords on the Mac and import it in Bitwarden using the "Safari and macOS (csv)" format. A CSV doesn't include passkeys, and it's unencrypted, so keep it out of synced folders and delete it once the import is done.

The Bitwarden desktop app and the browser extensions work the same way: Self-hosted, your vault address, then log in. In Safari, enable the extension under Settings → Extensions and give it website access. When you sign in with a passkey, pick Bitwarden's passkey in the prompt so Apple Passwords doesn't supply it.

Once you've checked the import, go to Settings → General → AutoFill & Passwords, enable Bitwarden and disable Passwords. In the Bitwarden app, under Settings → Account security, you can enable Face ID to unlock the vault.

Family members will join by invitation, so there's no need to keep registration open. That setting lives in the Vaultwarden admin panel, which has its own password, separate from your master password.

Bitwarden shares items through organizations: everyone keeps a personal vault, and an organization's collections hold the items you share.

The Bitwarden apps keep a copy of your vault, so you can unlock it and use the passwords you already synced even when the server is out of reach, as long as you're still logged in. To sync new passwords and changes away from home, though, you need a way to reach your server. There are two options. Pick one; they're alternatives, not a combination.

I already use Tailscale on all my devices, so I added Caddy to the same tailnet. The vault login page never touches the public internet.

1. Give Caddy the TUN device. In Proxmox, Caddy container → Resources → Add → Device Passthrough → /dev/net/tun. Shut the container down and start it again. (Background: Tailscale in LXC containers.)

2. Install Tailscale in the Caddy container and sign in:

The last command shows Caddy's Tailscale IP; copy it. Then, in the Tailscale admin console, open the Caddy machine and disable key expiry. Device keys expire after 180 days by default, and when Caddy's key expires, remote sync silently stops for the whole family.

3. Add a public DNS record. At Cloudflare, add an A record for your vault hostname pointing to Caddy's Tailscale IP, with the proxy status set to DNS only. Make sure there is no AAAA record for the same name.

This is split-horizon DNS: the same address gets a different answer depending on where you ask. At home, your local DNS answers with Caddy's LAN IP. Away from home, Cloudflare answers with the Tailscale IP, which only devices on your tailnet can reach. Publishing a 100.x address doesn't expose anything: it isn't reachable from outside your tailnet, and at worst a device without Tailscale gets a connection error.

4. Give the family access. Family members need Tailscale on their phones as well as a vault account. Invite them to your tailnet as Members. If you don't want them to reach everything else on your tailnet, narrow the access policy. A minimal example for a small tailnet, where you keep full access and members can only reach Caddy on HTTPS:

Merge this into your existing policy instead of pasting over it, and remove the default allow-all rule: a narrow grant doesn't cancel a broader one. Test it from a family account. See Tailscale's docs on grants.

If the same Caddy also serves public websites through a port forward, restrict the vault's site block to local and Tailscale addresses, placed before reverse_proxy:

Check it: turn off Wi-Fi on your phone and connect Tailscale. Add a note to the vault on another device, then open Bitwarden on the phone and sync. The note should appear. That change came from your server at home, over Tailscale. Simply opening an already synced password proves nothing, because that also works offline.

Point the vault's DNS record to your home's public IP and forward TCP 443 (and only 443) to CADDY_LAN_IP:443. The Bitwarden apps then connect without a VPN. This doesn't work on every internet connection: behind your ISP's CGNAT, a port forward never reaches you.

The trade-off is that the Vaultwarden login page is public. If you go this way:

Yes, unfortunately, because for data this important you really can't skip them. Proxmox makes this easy:

A container backup includes the root disk, which is where the helper script puts Vaultwarden's data: the database with your passwords and passkeys, attachments, keys and configuration. Extra mount points are only included if Backup is enabled on them, and device passthrough is never included. The Caddy backup holds your build, configuration, certificates and, with Option A, its Tailscale identity. If you ever restore a copy for testing, keep it offline while the original is running.

Restore one once, so you know it actually works. Ideally, follow the 3-2-1 rule: three copies including the original, on two types of media, one of them off-site. I'll cover how I do that in a separate video. For file-level backups outside Proxmox, the Vaultwarden wiki lists what to include. A Proxmox snapshot backup of a running container is crash-consistent, which SQLite handles fine; if you want to be extra safe, use the "stop" backup mode, which briefly stops the container. What you shouldn't do is copy the database file by hand while Vaultwarden is running.

The Bitwarden apps and Vaultwarden update separately. Your phone may update the app automatically, and if the server falls behind, features can stop working properly. For example, Vaultwarden 1.37.2 was required for Bitwarden clients 2026.8.0 and newer. Security fixes matter too: 1.37.4 (5 October 2026) fixed seven security advisories, one rated high.

On Alpine, Vaultwarden updates come through Alpine's package repository, so they can arrive a little later than the release itself. For 1.37.4 the Alpine 3.24 package was built two days after the release. For most homelabs that's good enough. If you want new releases the moment they're out, or more control over which version you run, use the official vaultwarden/server Docker image instead. It's a bit more to manage, but you're no longer waiting on Alpine.

To stay current on Alpine, I schedule the helper's update to run every Sunday. It upgrades the container's Alpine packages, Vaultwarden included, and restarts Vaultwarden. In the Vaultwarden console, check the time, check that cron is running, and open the crontab:

Keep the existing entries and add this line once:

Cron runs commands with a minimal environment, so the line sets PATH and TERM explicitly for the helper script. That's Sunday 04:00 in the container's timezone; mine uses UTC, which date shows you. Afterwards you can read the last run with tail -n 80 /var/log/vaultwarden-update.log. The log is overwritten every week and nothing notifies you when a run fails, so look at it now and then. When a security release comes out, don't wait for Sunday: run update and choose option 1.

Note that update fetches the latest version of the helper script from GitHub each time and runs it as root. If you'd rather not run a script you haven't read on a schedule, use apk -U upgrade && rc-service vaultwarden restart in the cron line instead; that's what option 1 does.

Because of the dpkg-divert setup, package updates no longer touch your custom Caddy binary, so you update it yourself. Caddy's documentation suggests caddy upgrade for this, a command it still marks as experimental: it downloads the latest version with the same plugins from caddyserver.com's build service and replaces your binary.

If you'd rather build locally again, repeat the xcaddy build from step 2, move the result to /usr/bin/caddy.custom and restart. You don't need to repeat the dpkg-divert and update-alternatives lines. A newer Caddy release may need a newer Go version than the one xcaddy installed. Either way, check that dns.providers.cloudflare is still listed and that the vault loads over HTTPS.

No domain? A free DuckDNS subdomain works too, with the DuckDNS plugin instead of Cloudflare's. The differences:

I haven't run the DuckDNS variant myself; the commands follow the plugin's documentation.

That's it: our own password manager for the whole family, using the normal Bitwarden apps, on hardware I control. This was one of the reasons I got into homelabbing in the first place, so it's a bit of a full-circle moment for me. The price of that control is that backups and updates are now my job, so set those up before you move your real passwords over.