Small teams share a surprising number of logins: hosting accounts, social profiles, supplier portals, and the Wi-Fi password that everyone asks about. Sharing them through chat messages or a spreadsheet is insecure and chaotic, and commercial password managers charge per user, which adds up fast for a team that mostly needs the basics.

Vaultwarden solves this neatly. It is a lightweight, community-built server that speaks the same protocol as Bitwarden, so every official Bitwarden app works with it unchanged. It runs happily on a tiny server, and it costs nothing beyond the server itself. The trade-off is that you own the maintenance, which is manageable if you set it up properly.

You need a small server with Docker, a domain name pointing at it, and a way to get HTTPS certificates automatically. A reverse proxy that handles certificates for you keeps this simple, and it is worth setting up before anything else, because a password manager without HTTPS should never be exposed to the internet.

You also need an email setup for invitations and two-factor codes, which can be a transactional email provider's free tier or your existing mail server. Plan your backup before your first login, not after. A password vault without a tested backup is a single server failure away from locking your whole team out of everything.

The core setup is a single container with a data folder and a few environment settings. The two settings that matter most are disabling open signups after you create your accounts, and setting a strong admin token for the admin panel. Leaving signups open on a public server is the most common Vaultwarden mistake, and it turns your private vault into a public one.

Once the container runs, create your account, install the official Bitwarden browser extension or app, and point it at your server address instead of the default cloud. Invite team members through the admin panel, create a shared collection for team logins, and keep personal logins in personal vaults. The separation matters: people leave teams, and collections make offboarding a one-click job.

Update the container regularly, because password software is a high-value target and security fixes arrive often. Automate updates if you can, but check after each update that logins still work before telling the team anything changed. A short monthly check beats a panicked recovery.

Back up the data folder regularly and test restoring it somewhere safe at least once. Store one encrypted export offline as a last resort, held by someone trusted. Self-hosting gives you control and privacy that commercial tools cannot match, but control means responsibility, and a tested backup is what turns that responsibility from a risk into an advantage.

Invite team members one at a time and confirm each person can log in, use the browser extension, and find the shared collection before inviting the next. A rushed bulk invite creates a pile of unanswered invitations and support questions, while a careful rollout surfaces setup problems early when they are easy to fix.

Set up emergency access for at least one trusted person, so the vault is recoverable if the main administrator is unavailable. Document the recovery steps somewhere outside the vault itself, because instructions locked inside the thing you cannot open are useless. A vault that nobody can recover is a vault that will one day cause a crisis.