Somebody has to hold the credentials this lab shares between more than one person, and the ones its own scripts and automation need to authenticate with. Vaultwarden is a self-hosted, Bitwarden-compatible server, and it runs on its own dedicated machine holding exactly that: nothing personal, nothing that belongs to only one person’s own accounts.
Drafted by an AI agent (claude-opus-5) from this lab’s own runbooks, deployment log and errata. Reviewed before publication by the site owner. How this site is written →
What it replaced
Nothing, in the sense of a migration — this project never asked “what do we use instead of a personal password manager.” It asked a narrower question: a personal manager already existed and was staying. The question was what to do with the credentials that don’t belong to one person, which a personal manager was never designed to hold in the first place.
Why this one
The deciding property is the split itself, not a feature comparison. Personal logins — the operator’s own accounts, everywhere — stay exactly where they already were, in the personal manager already in daily use. Every credential that either belongs to more than one person, or belongs to a machine rather than a person, moves to Vaultwarden instead. Two stores, drawn along one line: who or what actually needs to hold this.
Self-hosting the shared half specifically, rather than using a second cloud account, follows from what a shared credential actually is here — mostly infrastructure admin passwords and machine-facing secrets, the kind of thing this project would rather not hand to a third party’s cloud regardless of how well-regarded it is.
How it is actually used here
Live on its own dedicated virtual machine with no other services on it — a deliberate isolation, because a store of shared and machine credentials is a concentrated target and gets to be the only thing that host does. Its own database sits on local disk rather than on shared network storage, after an earlier version of this project’s own storage design put it on the network share instead and had to be corrected — a lesson from elsewhere on this site about a decision optimizing for the wrong kind of integrity. Backups are consistent, offsite, and the restore path has actually been drilled, not just built and assumed.
The one gap worth naming plainly: this build of Vaultwarden has no programmatic secrets API. The original design assumed one — mint a scoped, machine-readable credential that a script could fetch at runtime without a human account behind it. That capability doesn’t exist in this self-hosted build. What machine credentials get today is a full human-equivalent account, which means any script reading from it can read the entire vault, with no per-workload scoping and no record of which script read what.
That gap is being closed by something else entirely, not by asking Vaultwarden to do a job it cannot do: a single access tool every script and agent calls, which logs who accessed what by name — never the value — as a structured trail. Vaultwarden remains the store. It stops being the thing that also has to answer “who read this, and when.”
The shape of the configuration
Two credential stores, divided by who or what holds the key rather than by sensitivity:
personal accounts -> personal password manager, human only
shared group credentials -> Vaultwarden, human accounts, org vaults
machine-facing secrets -> Vaultwarden today, full account per workload
(being replaced by a single audited access path)Single sign-on gates the login itself, so a Vaultwarden account doesn’t carry its own separate password to manage on top of everything else. The database lives on local disk; only the nightly backup artifact leaves the host, onto network storage and then offsite, encrypted before it leaves.
What it cost
A secrets manager with no identity model just moves the files. Every machine credential minted against Vaultwarden today is a static, full-account credential with no expiry and no scoping — the discipline of creating it carefully doesn’t stop the count from growing every time a new script needs one. That’s the honest cost of choosing a tool built around human organization vaults for a job that also needed per-workload machine identity, and it’s why the fix is a layer on top rather than a Vaultwarden feature.
What would change the decision
If self-hosting itself stopped being worth the operational weight — the backup discipline, the restore drills, being the one host that must never go down carelessly — a hosted alternative would be worth relitigating. Nothing in the record points that direction today.
If the machine-secrets gap outgrows what an access-and-audit layer on top can cover. The honest ceiling for any credential store on this fleet is one root credential per host, short-lived where possible, with everything else fetched at point of use rather than sitting on disk. Vaultwarden reaching that ceiling on its own, rather than through something layered in front of it, would be the point to reconsider what it’s the only mechanism for.
About Vaultwarden
Vaultwarden is an open source, Rust-based implementation of the Bitwarden server API, compatible with every official Bitwarden client. It is not built or endorsed by Bitwarden itself — an independent, community-maintained reimplementation aimed at lightweight self-hosting — and is released under the GNU Affero General Public License.
- Website — github.com/dani-garcia/vaultwarden
- Documentation — github.com/dani-garcia/vaultwarden/wiki
- Source — github.com/dani-garcia/vaultwarden
- Community — github.com/dani-garcia/vaultwarden/discussions