Ask most MSPs how they’d prove a runbook was accurate on the date of an incident, and you’ll get a shrug. Documentation platforms are good at showing you the current state of an article. They’re much worse at answering “what did this say last month, before someone edited the failover steps?” or “who removed the escalation contact from this procedure, and when?” If nobody remembers, the answer is usually “we don’t know” — which is not what you want to tell an auditor, an insurer, or a client after a bad outage.
Weavestream treats article history the same way it treats credential history: as a first-class, unwipeable record, not an afterthought. Every explicit save to an article creates a numbered version. Here’s how it works, and why it matters for MSPs who already know their password vault has version history and have never thought to ask whether their knowledge base does too.
A Version on Every Save
Every time an article is explicitly saved — including a save triggered by accepting an AI chat edit — Weavestream writes a new, numbered version row. The version captures the full article body along with the author and timestamp. Nothing about this is opt-in: you don’t have to enable version tracking or remember to snapshot anything. Saving the article is the versioning event.
This matters because the alternative — relying on people to manually export or copy an article before making a risky edit — never actually happens under time pressure. A technician troubleshooting a live incident is not going to duplicate a runbook first. Weavestream removes the need to remember.
The History Panel
Each article has a History panel that lists every past version, newest first. For each entry you get:
- Changed-field chips — a quick visual indicator of what actually changed in that version, so you’re not opening every revision just to find the one that matters
- Author and timestamp — who made the change and exactly when
- A preview drawer that opens the full body of any historical version without leaving the article
For an MSP documenting dozens of clients, this turns “who touched this and when” from a guessing game into a two-click lookup. If a client asks why their disaster recovery procedure looks different than what was reviewed in last quarter’s business review, you can open the history panel and show them exactly what changed and who changed it — instead of trying to reconstruct it from memory or a Slack thread.
Restore Is Forward-Only
Restoring an old version doesn’t rewrite history or delete the versions in between. Selecting Restore on a historical version creates a new version whose content matches the one you restored — the version count keeps climbing, and the full sequence of what happened stays intact.
This is a deliberate design choice, and it’s the same principle Weavestream applies to the password vault’s version history and the platform’s audit log more broadly: history is additive, never destructive. If a technician reverts a botched edit, the record shows that a revert happened — it doesn’t quietly erase the mistake from the timeline. For any MSP that has to answer compliance questions about change management, being able to say “our documentation platform cannot lose history, even when someone reverts a change” is a meaningfully stronger position than “we think we still have the old version somewhere.”
Autosave Drafts Stay Out of the Official Record
Weavestream also supports autosave — but it’s opt-in, off by default, and configured workspace-wide under Admin → Settings → Articles. When enabled, autosave writes to a separate draft row rather than touching the article’s live body or creating a numbered version. Nothing in an in-progress draft counts as history until someone performs an explicit Save.
This distinction matters in practice. Article history should represent deliberate publishing decisions, not every half-finished sentence typed while a technician was still thinking through a procedure. Weavestream keeps those concerns separate: the draft layer protects your in-progress work from being lost to a closed tab, while the version layer records only what was actually published.
A few behaviors reinforce this boundary:
- Cancel discards the draft and reverts the article back to its last saved version — no partial edit leaks into the official record.
- An explicit Save clears any in-progress autosave draft, even when the saved body happens to be identical to what’s already live, so a stale draft can never resurface later and overwrite a newer edit.
- Archiving an article automatically discards any in-progress draft for it, so archived articles don’t carry orphaned draft state.
Archive, Restore, and “Delete Forever” Are Separate Actions
Article lifecycle management in Weavestream is intentionally staged rather than a single destructive button:
| Action | What it does |
|---|---|
| Archive | Soft-deletes the article; it drops out of default views but the record and its full version history remain |
| Restore | Brings an archived article back |
| Delete forever | Permanently and irreversibly removes the article and cascades the delete to every version row |
“Delete forever” only becomes available once an article is already archived, and triggering it requires typing the article’s title to confirm — a deliberate speed bump against an accidental or automated deletion. Under the hood it’s gated by a dedicated article.purge permission that’s restricted to users with full membership access, so a read-only technician or a client-portal account can never trigger a permanent delete even by mistake.
For MSPs, this staged model means the common case — “we don’t need this article anymore” — never actually destroys anything. You archive it. The history stays queryable. Genuine permanent deletion is a distinct, deliberate, audited action that most teams will rarely if ever use.
Client Portal Users Only See What Was Client-Visible at the Time
If you expose any articles to your clients through the client portal, version history respects the same visibility boundary the article itself does — but it does it per version, not just for the current state.
A portal user browsing an article’s history only sees versions that were themselves marked client-visible at the time they were written. If an article started life as internal-only and was flipped to client-visible later, the client can’t reach back through history to read the internal-only versions that predate the switch. Versions they’re not entitled to see return a plain 404 — there’s no signal that a hidden version even exists, so the history panel can’t be used to infer what internal content used to be there. Operators and super admins, by contrast, always see the complete history regardless of any version’s visibility flag.
This is the kind of detail that’s easy to get wrong in a simpler “just log every edit” implementation, and easy to overlook until a client asks a pointed question about what they can and can’t see in a shared record’s past.
Why This Belongs in an IT Documentation Platform
Version history is table stakes for a password vault — nobody would accept a credential manager that couldn’t tell you a secret was rotated. Knowledge bases get held to a lower standard, mostly because most documentation tools weren’t built with MSP compliance obligations in mind. But the same questions come up for runbooks and procedures as they do for credentials:
- Can you show when a disaster recovery procedure was last reviewed and what changed?
- Can you prove a specific technician updated the firewall change procedure after an incident, rather than assuming someone did?
- If a client disputes what a shared article said on a given date, can you show them the actual historical version rather than your best recollection?
A self-hosted IT documentation platform that keeps this history on your own infrastructure — rather than trusting a SaaS vendor’s audit log you can’t independently verify — gives you a straight answer to all three. The data doesn’t live in a vendor’s black box; it’s rows in your own Postgres database, covered by whatever backup and retention policy you already run.
Getting Started
If you’re already running Weavestream, open any article and look for the History panel — it’s populated automatically the moment you’ve saved the article more than once. To turn on autosave drafts for your workspace, go to Admin → Settings → Articles and enable the autosave toggle; it’s off by default.
New to Weavestream? The quickstart guide gets the full stack running with Docker Compose in a few minutes. Article version history works out of the box — there’s nothing extra to configure, and the append-only design means your knowledge base’s change history is trustworthy from the first save.
Weavestream is free, self-hosted, and open source. If your MSP needs a documentation platform where “what did this runbook say last month” has a real answer instead of a shrug, explore it at weavestream.io.