← All Guides
intermediate

Vaultwarden for Families: Share Passwords With Organizations and Collections

Stop sharing a login over text. Set up Vaultwarden organizations and collections so your household shares the passwords it should, and nothing it shouldn't.

Budget Homelab ·
dockersecurityself-hostingvaultwardenhow-to

This post contains affiliate links. If you buy through them, I earn a small commission at no extra cost to you.

Most households solve password sharing badly. The streaming login gets texted once and lives in a message thread forever, the bank password is on a sticky note, and one person becomes the human password manager everyone else pings. If you already run Vaultwarden from the Vaultwarden deep-dive, you have the fix sitting unused on your own hardware: organizations and collections, which Bitwarden charges a family plan for and Vaultwarden gives you free.

This guide picks up where a single-user install stops. It assumes Vaultwarden is already running behind HTTPS on your stack. If you have not chosen a password manager yet, the self-hosted password manager comparison is the piece to read first, and Docker Compose basics plus the Nginx Proxy Manager HTTPS guide cover the prerequisites.

Why Organizations Instead of a Shared Account

The tempting shortcut is one Vaultwarden account that the whole family logs into. It works for about a month, and then it breaks in ways that are hard to undo.

A shared account has one master password, so nobody can change it without telling everyone. It has one 2FA enrollment, so the phone holding the TOTP codes becomes a household dependency. Every item is visible to every person, which is fine until a teenager can read the mortgage login. And when someone moves out, your only option is to change everything.

An organization fixes all four. Each person keeps their own account, their own master password, and their own 2FA. Shared items live in the organization, not in anyone’s personal vault, so revoking access is one click and it actually revokes.

Shared accountOrganization + collections
Master passwordsOne, sharedOne per person
2FAOne enrollmentPer person
Who sees whatEveryone sees everythingPer collection
Removing someoneRotate every passwordRemove member, done
Audit of who changed an itemNoneEvent log, if enabled
Cost self-hosted$0$0

What You Need

Step 1: Decide the Structure First

Do this on paper before touching the web vault, because moving items between collections later is tedious.

One organization is almost always right for a household. Collections are where the actual permission boundary lives, and the useful split is by trust level, not by category:

Three collections handles most families. Resist the urge to build twelve, because every collection is an assignment you have to maintain for every member.

Step 2: Lock Down Organization Creation

By default any user on your server can create their own organization. On a household server that is just clutter, and it lets someone else’s org start sending invitations from your instance. Restrict it to you.

In your docker-compose.yml:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    ports:
      - "8543:80"
    volumes:
      - ./data:/data
    environment:
      TZ: America/New_York
      DOMAIN: https://vault.example.com
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "true"
      ORG_CREATION_USERS: "you@example.com"
      ORG_EVENTS_ENABLED: "true"
      LOG_LEVEL: warn

Three of those matter here:

ORG_CREATION_USERS takes a comma separated list of emails. Only those addresses can create organizations. Set it to none to block creation entirely once yours exists.

INVITATIONS_ALLOWED lets an organization invite an address that has no account yet, even while SIGNUPS_ALLOWED is false. That combination is what you want long term: nobody can walk up and register, but you can still add a family member.

ORG_EVENTS_ENABLED turns on the organization event log, so you can see who viewed or changed a shared item. It is off by default and costs a little database growth. On a family server it is worth having the first time someone asks why the Netflix password changed.

Apply it:

docker compose up -d

Step 3: Get Everyone an Account

This is where most people get stuck, and the cause is almost always the same: Vaultwarden sends no email unless you configure SMTP. The invitation is created, the member sits in an invited state, and nothing ever lands in their inbox.

You have two ways through it.

Option A, configure SMTP. Better long term, because password hints, invitations, and 2FA emails all start working. Add to your environment block:

      SMTP_HOST: smtp.example.com
      SMTP_FROM: vault@example.com
      SMTP_FROM_NAME: "Home Vault"
      SMTP_PORT: "587"
      SMTP_SECURITY: starttls
      SMTP_USERNAME: vault@example.com
      SMTP_PASSWORD: "app-specific-password"

Use an app specific password, never your main mail account password. Restart, then send yourself a test from the admin panel at /admin under Diagnostics before you rely on it.

Option B, register directly. No SMTP required. Set SIGNUPS_ALLOWED: "true", restart, have each family member go to your vault URL and register with their own email and their own master password, then set it back to "false" and restart again. Do this in one sitting with everyone present, not over a week with signups left open.

Either way, every person ends up with their own account. That is the prerequisite for everything below.

Step 4: Create the Organization and Collections

Log into the web vault as yourself. Open the vault switcher and choose New organization. Name it something plainly recognizable, like Household, and give it your email as the billing contact. Vaultwarden ignores the billing fields, but the form still wants them.

Once the organization exists, open it and go to Collections. There is a Default collection already there. Rename it to Household or delete it after you create your own, then add the rest:

Create the collections before you invite anyone. Invitations ask which collections to assign, and it is much faster when the answer already exists.

Step 5: Invite, Accept, Confirm

This is a three step handshake and skipping the third step is the single most common Vaultwarden family complaint. It looks like a bug and it is not.

  1. Invite. In the organization, go to Members, click Invite member, enter their email, choose the member type, and tick the collections they get. Use the User type for everyone except yourself. Do not hand out Admin to a spouse by reflex, since User can still read and edit everything in their assigned collections.
  2. Accept. The member logs into their own vault and accepts the invitation. With SMTP configured they get a link. Without it, the invitation is waiting in their web vault when they log in.
  3. Confirm. You go back to Members and click Confirm on that person.

That third step is not bureaucracy. The organization’s encryption key is only encrypted to the member’s public key at the confirm step. Before it happens the member can see that the organization exists and cannot decrypt a single item in it. If someone reports “I accepted but there’s nothing in there,” you owe them a confirm, not a support ticket.

Step 6: Move the Right Items In, and Leave the Rest

In your personal vault, select the items that belong to the household, then use Move to organization and pick the target collection.

Two things about that action are worth knowing before you do it in bulk:

The item is re-encrypted with the organization key and ownership transfers to the organization. It is no longer your personal item. That is the entire point, and it is also why you should not sweep your whole vault in at once.

Only move what genuinely needs sharing. Your work email, your personal accounts, and anything tied to your identity alone should stay in your personal vault. A good filter: if you would be uncomfortable with the item still being readable by everyone in that collection a year from now, it does not go in.

For the Wi-Fi password and similar things people ask for constantly, a Secure Note in the Household collection beats a login item, and it stops the browser extension from trying to autofill it.

Step 7: Hardware 2FA Where It Counts

Your owner account can decrypt every collection in the organization. It deserves better protection than the rest.

Vaultwarden supports WebAuthn/FIDO2 as a second factor with no extra server configuration, which means a standard security key works out of the box. Register one under Settings > Two step login > FIDO2 WebAuthn, and register a second key as a backup before you walk away. A single key is a single point of failure, and there is no support desk to call.

A FIDO2 security key with NFC is the practical pick because NFC lets the same key work on a phone. Buy two of the same model so the backup behaves identically.

One caveat worth checking rather than assuming: Bitwarden’s own clients have historically gated some hardware key paths behind premium or the official server, and behavior varies by client version. Verify the key actually prompts on your phone app, not just in the browser, before you rely on it as your only second factor.

For everyone else in the household, TOTP is the realistic answer. Turn it on under the same menu, and have them store the recovery code somewhere physical. Note the recursion problem: if the only copy of a person’s TOTP secret is inside the vault that TOTP protects, they are locked out the moment they lose the phone.

If you also run Authelia in front of other services, leave Vaultwarden out of it. Putting an SSO portal in front of your password vault means an authentication loop the day SSO breaks.

Step 8: Emergency Access Is a Separate Problem

An organization shares items while everyone is around. It does nothing for the scenario where the person who set all this up is hit by a bus, because personal vaults stay personal.

Vaultwarden includes Bitwarden’s Emergency Access feature, free. Under Settings > Emergency access, add a trusted contact, choose View or Takeover, and set a waiting period. If they ever request access, you get notified and have that long to decline. If you cannot decline, they get in.

Set the waiting period to something you would realistically notice, seven days is reasonable. And note that this feature depends on notifications reaching you, which is another reason to get SMTP working in Step 3.

Your Backups Just Got More Important

Everything above still lives in one SQLite database at data/db.sqlite3. The difference is that losing it now takes out the whole household, not just you.

0 3 * * * sqlite3 ~/docker/vaultwarden/data/db.sqlite3 ".backup '/home/user/backups/vault-$(date +\%Y\%m\%d).sqlite3'"

Use .backup rather than copying the file directly. A plain cp of a live SQLite database can capture a partially written state, and the copy will look fine right up until you need it.

Get that off the host. The Duplicati backup guide covers encrypted off-site copies, and Syncthing works for a second machine on your own network. Then restore one, once, to a throwaway container. An untested backup is a guess.

Troubleshooting

Member shows Accepted, sees nothing. They need confirming. Members tab, Confirm. See Step 5.

Invitation email never arrives. SMTP is not configured, or it is configured wrong. Test it from /admin under Diagnostics rather than by sending more invitations.

“You are not allowed to create an organization.” Expected, if their address is not in ORG_CREATION_USERS. That is Step 2 working.

An item moved to the organization vanished from a personal vault. Also expected. Ownership transferred. Look in the collection.

Nobody can log in after a restart. Check DOMAIN still matches the URL people actually use. A mismatch breaks WebAuthn and passkeys specifically, so it often presents as “2FA stopped working” rather than a URL problem.

What It Costs

Nothing beyond what you already run. Bitwarden’s Families plan is $40 a year for six users. Vaultwarden gives you the same organizations, collections, and emergency access on hardware that is already powered on, and the container idles at well under 100MB of RAM. If you are starting from scratch, a 16GB mini PC runs this alongside a full Docker stack without noticing it.

The real cost is operational, and it is worth naming honestly: you are now your household’s password administrator. When the confirm step confuses someone, when a phone dies with the only TOTP secret on it, that is your evening. Set up the backups, register the second security key, and write down where the master passwords live. Do that and this runs quietly for years.