# Why Your MSP Client Credential Vault Belongs in Your Documentation Platform ![](./assets/credential-vault-belongs-in-your-documentation.png) Most MSPs are running two separate tools to do one job. There's the IT documentation platform — IT Glue, Hudu, or something homegrown — and then there's the password manager: Passportal, 1Password Teams, Keeper, or Bitwarden for Business. Two subscriptions. Two per-seat fees. Two places to look when a technician needs the admin credentials for a client's firewall. The split is so common that most MSPs have stopped questioning it. But it's worth asking: why are credentials stored separately from the assets and documentation they belong to? ## The Cost Problem Is Real Passportal runs around $3/seat/month on top of your IT Glue or documentation costs. Keeper for MSPs, 1Password Teams, and Bitwarden Business all charge per seat as well. Stack those on top of an IT Glue subscription at $29/seat/month and you're easily north of $35/seat/month before you've touched your RMM or PSA. For a 10-person shop, that's over $4,200/year just for documentation and credential management — tools that, from a workflow perspective, are supposed to serve the same moment: a technician opens a ticket, looks up the client, and needs to know which credentials to use. The per-seat model makes this painful in a specific way: your billing scales with headcount, not with how many clients you have or how useful the tool actually is. Hire two junior techs and your monthly SaaS bill jumps immediately. ## The Context Problem Is Worse The real issue isn't money. It's workflow fragmentation. When credentials live in a separate vault from your documentation, you're forcing technicians to context-switch. They look up a client's server asset in the documentation tool, then pivot to Passportal or 1Password to find the admin password, then back again. If documentation and credentials aren't manually cross-referenced — which they almost never are, consistently — you end up with vaults full of orphaned credentials and documentation full of "see password manager" placeholders. In an incident at 2am, that context-switch costs real time. When everything is on fire, the last thing you want is a technician toggling between tabs trying to match an asset to a credential stored somewhere else. ## What an Integrated Vault Actually Looks Like Weavestream is a self-hosted, open-source IT documentation platform that includes a client credential vault as a native feature — not a bolt-on or a third-party integration, but a first-class component of the same platform where you manage assets, documentation, IPAM, and domain monitoring. The credential vault is scoped per client. Credentials are stored alongside the assets and documentation they relate to, so a technician looking at a client's firewall asset can see the associated credentials in context — without switching tools. Role-based access control lets you grant read-only or full access per client, using the same access model that governs documentation and assets. Because Weavestream is self-hosted, the vault data never leaves your infrastructure. There's no SaaS provider holding your clients' credentials. You control the encryption, the backups, and the access logs. ## Self-Hosted Doesn't Mean Complicated The common objection to self-hosted tooling is operational overhead. That's a fair concern — you're responsible for updates, backups, and uptime. But Weavestream is Docker-first and Postgres-backed. Deployment is a `docker compose up` away. If you're already running any self-hosted services — Vaultwarden, Netbox, Grafana, anything else in your stack — Weavestream fits the same operational model. It's not meaningfully harder to run than any other containerised service you're already maintaining. For MSPs with a server or VPS for internal tooling, the incremental cost of adding Weavestream is low. The licensing cost is zero — it's licensed under AGPL-3.0. ## RBAC and the Technician Access Problem One underappreciated benefit of having credentials inside your documentation platform is that role-based access control now covers both at the client workspace level. In a standalone password manager, you manage permissions in that tool. In your documentation platform, you manage them separately. With Weavestream, the same tenant access model governs who can reach each client's documentation, assets, and credential vault. That said, Weavestream does not currently support restricting individual password records for different technician tiers inside the same client workspace. If a technician has access to a client's vault, they should be treated as trusted for that vault. The value today is simpler client-level access control, fewer duplicated permission rules, and one audit trail for documentation and credential activity. ## The Practical Case for Consolidation The argument for integrating credentials into your documentation platform isn't primarily ideological — it's practical. Fewer tools means fewer interfaces to train technicians on, fewer things to keep updated, and fewer surfaces where client data lives across disconnected systems. If you're already running a self-hosted documentation stack or actively evaluating one, it's worth asking whether that stack should handle credentials as well. The overhead of a separate tool adds up, and the workflow fragmentation it creates is a daily cost that doesn't show up on any invoice. --- Weavestream is free, self-hosted, and open source. If you're evaluating your MSP tooling stack or looking to consolidate credentials and documentation into one platform, explore it at [weavestream.io](https://weavestream.io).