After my third IT Glue renewal, I sat down and added up what I’d paid over five years. The number was uncomfortable. What made it worse was realizing that none of that money was an investment — it was rent. If I stopped paying tomorrow, the knowledge would still exist in the world, but I’d have no structured way to access it without starting over.
That’s the quiet problem with renting your documentation infrastructure. Not the price — the dependency.
The structure is the value
Good MSP documentation platforms aren’t valuable because they store text. Plenty of things store text. They’re valuable because they impose structure — clients have consistent schemas, assets link to their credentials, procedures point back to the systems they explain. That web of relationships is the actual product.
The problem is that this structure lives entirely inside someone else’s database, behind someone else’s auth layer, subject to someone else’s roadmap decisions. When Kaseya bought IT Glue, the community didn’t panic about the features — they panicked about the dependency. Reasonably so.
The documentation that keeps your clients’ environments running is too operationally critical to be a line item someone else controls.
What I actually wanted
I didn’t want a notes app. I didn’t want a wiki. I wanted the relational model that IT Glue proved works — clients, assets, credentials, domains, IPs, procedures, all linked — but self-hosted, with a database I control and source code I can read.
Ideally, I wanted:
- Client-scoped documentation with consistent schemas across every account
- Typed relationships — not just free-text links, but actual typed edges (asset has credential, asset uses IP range, procedure explains asset)
- Expiry awareness for SSL certs, domains, and credentials that quietly rot
- Docker-first deployment so I could run it anywhere without fighting a stack
- No telemetry, no license checks, no phone-home — the app shouldn’t care whether it’s online
That list didn’t describe any existing open-source project I could find. Most alternatives were either too simple (glorified wikis) or too complex (full ITSM platforms that need a dedicated admin).
So I built it
Weavestream started as a weekend project to see if the relational model was hard to get right. It wasn’t — the hard part was the boring 80%: a clean data model, good search, a credential vault that’s actually usable, IPAM that doesn’t feel bolted on.
# The whole install, on a Debian VPS with Docker
git clone https://github.com/weavestream/weavestream
cd weavestream
cp .env.example .env
docker compose up -d
Six months later it’s running in production for a handful of clients, with real data, real pressure, and real rough edges I’m still filing down.
What “young but real” means
Weavestream is not a demo. It handles real client environments — assets, credentials, procedures, the whole picture — with an actual relational graph underneath. But it’s also not finished. Some UI flows are rough. Some features the roadmap promises aren’t shipped yet. The documentation could be better.
I’d rather ship that honestly than pretend it’s something it isn’t.
The versioned changelog is public. The roadmap is public. If something is broken, file an issue — I’ll read it.
Why open source
Partly philosophy. Partly pragmatism.
Philosophically: the documentation that keeps your clients running shouldn’t be trapped in someone else’s business model. Open source means you can read the code, audit the security, and fork it if the project ever goes sideways.
Practically: I wanted other IT professionals to be able to use this, improve it, and catch the edge cases I haven’t hit yet. That only works if the code is open.
The license is AGPL-3.0. If you improve it and run it as a service, share the improvements. Otherwise, do whatever you need.
If this sounds like the tool you’ve been looking for, start here. The self-hosting guide gets you running in under ten minutes on anything that runs Docker.
If you have questions, the GitHub Discussions are the right place. I read everything.