Every IT team has that one technician who lives in Markdown and another who wants a toolbar. Most documentation platforms pick a side and force everyone into it — and the people on the losing side quietly stop writing documentation. That’s how knowledge bases die: not from a bad migration or a missing feature, but from friction at the moment someone was about to write something down.
Weavestream’s Articles module takes a different position: the editing format is a per-article choice, not a platform decision. Here’s how the documentation system works, and why it’s built the way it is.
A Knowledge Base Per Client, Not One Big Wiki
Articles in Weavestream are scoped to a company record, like everything else in the platform. Each client gets their own knowledge base: their own articles, their own folder tree, their own visibility settings. There’s no global wiki where client runbooks sit next to internal process docs and you rely on naming conventions to keep them apart.
For MSPs, this matches how the work actually happens. When a technician opens a client’s record, the documentation for that client is right there — onboarding notes, network documentation, escalation procedures, the quirks of that one legacy application nobody wants to touch. No cross-client search results to second-guess, no “which client was this for again?”
Two Editor Modes, Chosen Per Article
Each article stores an editor mode that determines how it’s authored:
| Mode | What you get |
|---|---|
| WYSIWYG (Tiptap) | Full rich-text editor with toolbar. Content stored as Tiptap/ProseMirror JSON. |
| Markdown | Raw Markdown |
The rich-text mode is powered by Tiptap 3 and covers what you’d expect from a serious editor: headings (H1–H6), inline formatting, resizable tables, inline image uploads from the client’s file store, syntax-highlighted code blocks, interactive task lists, links, block quotes, and horizontal rules.
Markdown mode supports standard CommonMark plus GitHub Flavored Markdown extensions — fenced code blocks with language hints, tables, task lists, and strikethrough. If your team already writes runbooks in Markdown elsewhere, they paste straight in.
You can switch an existing article between modes using the format toggle. Weavestream is honest about the trade-off here: switching triggers a one-time conversion with a confirmation dialog, because complex rich-text structures don’t always round-trip perfectly to Markdown and back. That’s the kind of caveat most platforms bury — better to know before you flip the toggle.
Crucially, search doesn’t care which mode you picked. Both formats are indexed as plain text, so a Markdown runbook and a rich-text procedure are equally discoverable.
Folders That Nest as Deep as You Need
Articles are organised into folders per client, and folders nest to any depth. You can build whatever structure fits the client — Networking / Firewalls / Site B, or a flat list, or anything in between. Folders are created, renamed, and deleted from the article list view, articles move between folders freely, and an article can also live at the root level with no folder at all.
The folder tree is browsable from the sidebar, which matters more than it sounds. Search is great when you know what you’re looking for; browsing is how a new technician discovers what documentation exists for a client they’ve never worked with.
One Knowledge Base, Two Audiences
Every article has a visibility flag with two states:
- Internal (default) — visible only to operators and super admins
- Client-visible — also appears in the client portal for that client’s portal users
This is a quietly important design decision. The alternative — maintaining a separate client-facing knowledge base — means duplicated content that drifts out of sync, or worse, an internal doc that accidentally gets published wholesale. With per-article visibility, you write documentation once and decide record by record what the client sees.
A practical pattern: keep the full network documentation internal, but flip the “how to request a new user account” and “what to do when the office internet is down” articles to client-visible. Your clients get self-service answers; your internal docs stay internal by default.
Search That Actually Finds Things
Article content is indexed for full-text search using PostgreSQL’s native tsvector — no external search service to deploy, no Elasticsearch cluster to babysit. Titles are weighted higher than body content, so an article titled “VPN Setup” outranks an article that merely mentions VPNs in passing.
Articles surface through the command palette (Cmd+K), the per-tenant article list, and the search API. Results are scoped to the requesting user’s accessible tenants, so search respects the same permission boundaries as everything else — a technician without access to a client can’t find that client’s runbooks by searching for them.
For a self-hosted IT documentation platform, doing search in-database is the right call. It’s one less service in your Docker Compose file and one less thing to break at 2am.
AI-Assisted Editing, With a Human in the Loop
If you’ve configured Weavestream’s AI chat with an OpenAI-compatible endpoint, the AI can help write and edit articles. When the chat panel is open and an article is the active document, you can ask the AI to rewrite or expand sections, fix formatting and grammar, add tables or lists, or draft new sections from rough bullet notes.
The important part is how edits land: proposed changes appear as tool-call cards in the chat, and nothing touches the article until you accept it. Review the diff, accept or discard. There’s no autonomous agent rewriting your runbooks while you’re not looking.
Chat responses can also be saved directly as new articles via the “Save as article” action — useful when you’ve asked the AI to draft a procedure from your notes and the answer is good enough to keep.
Why This Matters for Self-Hosted IT Documentation
The knowledge base is usually the most personal part of an MSP documentation platform. Asset records and credential vaults have fairly fixed shapes; articles are where your team’s actual knowledge lives, in their actual words. That’s exactly the content you don’t want held hostage by a SaaS vendor’s export format or a proprietary editor.
Weavestream’s approach — Markdown as a first-class authoring format, per-client scoping, in-database search, self-hosted on your own infrastructure — means your runbooks stay in a form you control. If your team writes in Markdown today, they keep writing in Markdown. If they prefer a rich editor, that works too, in the same platform, searchable the same way.
Getting Started
If you’re already running Weavestream, open any company record and head to its Articles section — create a folder, pick your editor mode, and start writing. The format toggle is on the article form if you change your mind later.
New to Weavestream? The quickstart guide gets the full stack running with Docker Compose. The articles module needs no extra configuration — PostgreSQL full-text search works out of the box, and AI editing lights up as soon as you connect an OpenAI-compatible endpoint.