Vaultwarden for coworking staff secrets

This guide scopes Vaultwarden to one low-impact shared facilities credential. Vaultwarden is an unofficial Bitwarden-compatible server, not the official server/cloud, and this guide is not security or compatibility evidence.

1. Coworking outcome

Replace one password shared through chat/spreadsheets with individually authorized collection access, then rotate the underlying credential and prove revocation. Vaultwarden organizes secrets; humans approve access, rotation, emergency use, and recovery.

2. Pilot scope

Use two synthetic individual users with supported MFA, one Facilities collection, selected clients, a fake item, then one approved low-impact Wi-Fi admin credential. Exclude payment, root/cloud recovery, life-safety/door emergency, personal vault, and bulk production secrets.

3. Fit

Good fit: a technically operated team with TLS, individual accounts, supported MFA, least-privilege collections, encrypted off-host backups, independent recovery custody, updates, offboarding, and tested protected export.

4. Non-fit and alternatives

Poor fit: mandatory official Bitwarden support/certification, dynamic application secrets, public exposure without TLS, open enrollment, or no recovery owner. Compare official managed password services or supported enterprise products when assurance/support is required; retain the prior approved store during the pilot.

5. Coworking use cases

• Control staff access to one facilities Wi-Fi administration credential.
• Organize approved vendor-portal credentials in owner-specific collections later.
• Support offboarding through vault revocation plus source-system rotation.

Vault access alone does not revoke a credential at its source.

6. Tasks reduced or augmented

Vaultwarden can reduce insecure sharing, synchronize approved items, and centralize collection membership. It cannot decide authorization, guarantee client behavior, rotate source credentials by itself, replace source-system controls, or determine incident scope.

7. Human decisions and approvals

Security approves architecture/policy; organization/collection owners approve each member; credential owners approve migration/rotation; the recovery custodian approves backup access; change management approves upgrades/restores. Decrypted bulk export and destructive retirement require two people.

8. Owners and RACI

Name accountable service/security owners, responsible technical operator, organization and collection owners, credential-rotation/offboarding owners, and independent recovery custodian. Separate routine administration from backup-key custody where staffing permits.

9. Prerequisites

Inventory shared credentials and select one low-impact source supporting immediate rotation. Define account lifecycle, collection matrix, MFA/recovery codes, emergency path, enrollment, clients, DNS/TLS/proxy, optional email, backup encryption/key custody, export handling, incident route, and old-store fallback.

10. Skills and effort boundary

The pilot needs runtime/container, DNS/TLS/proxy, storage/database, client, identity/access, secret-rotation, backup/restore, and incident skills. The catalog’s 1-3 days is unverified and excludes policy, client troubleshooting, user enrollment, security review, and witnessed recovery.

11. Deployment choice

Use a current documented deployment on privately administered infrastructure. The repository’s compose/vaultwarden is a loopback-bound single-node SQLite staging baseline with no HA, SMTP, proxy, automatic updates, or off-host backups; it is not production evidence.

12. Architecture and dependencies

Map clients, TLS proxy, Vaultwarden, persistent state/database, optional email, DNS, backups, admin access, organization/collections, and source vendor portal. Document behavior when server, DNS, email, or client is unavailable and test every selected client/version.

13. License and edition boundary

The repository identifies Vaultwarden as AGPL-3.0-only and unofficial. Recheck the official repository for the selected release and obtain license advice if needed. Official Bitwarden terms/pricing/support do not describe Vaultwarden hosting.

14. Total cost boundary

Record compute/storage, DNS/TLS/proxy, optional email, setup, enrollment, clients, updates, monitoring, encrypted backups, drills, incident response, support/operational labor, and exit rotation. Free software provides no official vendor support; no compatibility/support promise is asserted.

15. Data map

Data	Purpose	Minimum handling	Exit record
Encrypted items	Secret storage	Approved pilot collection only	Protected export/import plus rotation
Accounts/membership	Access control	Individual/current roster	Access/offboarding register
Attachments/Sends if enabled	Optional sharing	Disabled unless approved/backed up	Inventory/deletion record
Config/signing/admin state	Operation/recovery	Restricted separate custody	Recovery inventory, never public export

Personal data and high-impact secrets are held. Payment data is excluded.

16. Privacy and retention

Minimize account profile/log data, define departed-user and event retention, and document privacy-request handling. Encryption does not remove obligations. Never inspect item contents/activity for employee monitoring or employment decisions.

17. Security baseline

Require TLS, unique master passwords, individual accounts, supported MFA, restricted organization owners, closed signup, least-privilege collections, protected admin route/token, supported updates, encrypted off-host backups, separate recovery-code/key custody, and prompt offboarding. Never share vault logins.

18. Compliance and expert review

The operator owns credential policy, authorization, privacy/employment, breach response, contracts, and regulated secrets; compatibility is not certification. Require security review before production/exposure/identity integration/high-impact secrets, legal/compliance review for regulated assurance, and database experts for corruption/migrations/strict recovery.

19. Integration boundary

No browser, desktop, mobile, identity, SMTP, backup, or vendor-portal integration is catalog-verified. Record official compatibility source, exact version, permissions, data path, failure behavior, owner, revoke method, and test result before allowing real secrets.

20. Configuration baseline

Record exact server/runtime/database/client versions, canonical HTTPS domain/proxy, signup/invitation/email settings, admin route/token custody, authentication/MFA/recovery policy, owners/collections, optional features, sessions/log retention, backup scope/key custody, monitoring, update, incident, and export controls. Never record secret values.

21. Smallest useful experiment

Following the project wiki, deploy isolated staging, create two synthetic users and a Facilities collection, enable supported MFA, add a fake item, and test sync, lock, revocation, restore, and export before the one real rotation.

22. Implementation sequence

1. Accept the unofficial-server/support boundary and approve owners/policy.
2. Select one credential, collection matrix, clients, and old-store fallback.
3. Deploy privately with TLS, closed signup, and restricted administration.
4. Enroll test accounts, supported MFA, and recovery codes.
5. Test client/boundary/revocation/export/server restore/emergency procedures with fake data.
6. Migrate and rotate the approved credential; prove old access fails.
7. Obtain security, credential, collection, and recovery sign-off before expansion.

23. Migration and rollout

Keep the prior approved store until the credential is rotated, recovered, and accepted. Add one collection/credential cohort at a time, independently approve users, communicate client/recovery changes, and freeze unrelated access changes. Never bulk-import high-impact secrets from an unreviewed export.

24. Required test plan

Test enrollment, supported MFA, recovery codes, client login/sync/lock, collection allow/deny, removed-user access, server outage, optional email failure, encrypted backup, isolated restore, attachment if enabled, protected export/import, export destruction, source rotation, and old-password rejection. Use fake secrets first.

25. Acceptance criteria

Only approved users access the test collection; revocation behaves as documented in tested clients; MFA/recovery pass; the one source credential is rotated and old value rejected; complete-state restore and protected export/import pass; no unprotected export remains; security/collection/credential/recovery owners sign.

26. Success metrics

Track approved versus actual memberships, offboarding/revocation observations, credential-rotation completion, MFA/recovery defects, backup age, restore result/time, client incidents, export-destruction evidence, and operator effort. No security or staffing improvement is assumed from service health alone.

27. Monitoring and alerting

Monitor service/proxy/TLS, storage, backup outcomes, update advisories, and optional email without secret values. Restrict alerts; never place vault contents, admin token, recovery codes, or decrypted exports in logs/tickets. Human owners validate security impact.

28. Operating cadence

Review owners, memberships, dormant/leaver accounts, supported MFA, clients, optional features, releases, backups/restores, TLS/storage, and emergency contacts on defined cadences. Rotate source credentials after relevant staff/vendor changes rather than relying only on vault revocation.

29. Failure modes and response

Plan for server/DNS/email/client outage, admin/user lockout, collection misgrant, stolen device/session, lost recovery material, corrupt/incomplete backup, exposed export, compromise, and bad migration. Security restricts access, preserves minimum evidence, rotates affected source credentials, revokes sessions, and follows notification advice; restore does not invalidate stolen secrets.

30. Backup procedure

Follow selected-version official backup guidance. For the local Compose reference, create the documented SQLite backup then encrypt/copy the complete data volume, including applicable attachments, Sends, configuration, and signing material; protect admin token/key separately.

31. Restore drill

Restore copied complete state to isolated infrastructure with a compatible pinned version and version-specific file/WAL handling. Verify login, MFA flow, sync, organization/membership, collection boundary, fake item, and enabled attachments. A database opening alone is not acceptance.

32. Upgrade, rollback, and exit

Read release/client/schema notes, back up/restore a copy, test target server and clients, and approve a window. Stop for schema/login/sync/collection/recovery failure; migration may require prior-version data restore, not image downgrade. Exit through two-person protected export/import, separate access mapping, rotation of every migrated source credential, revocation, and verified destruction of temporary exports/obsolete state.

33. Sources, evidence, and unknowns

Reviewed 2026-07-17: Vaultwarden repository and wiki. The local Compose staging reference was documented 2026-07-18; evidence is documentation/configuration review only.

Untested: clients, supported MFA/recovery details, version-specific backup scope, migrations, exports, email, support, hardening, certifications, restore/rollback times, and production security. Treat all as open gates until target evidence exists.