Your documentation lives in Git, not in a database.

AI assistants

Hand an assistant write access, and keep the receipts

DocuWaves speaks MCP. Point an assistant at /api/mcp with a bearer token and it can browse, search, read and — with a token that says so — write your documentation. Every write arrives as an ordinary commit, authored by the token that made it.

So the ordinary tools answer questions about it:

git log --author='API token' # every assistant write git log --author='notes-bot' # just this one token git revert <sha> # undo one of them

• There is deliberately no delete tool An assistant can create pages and rewrite them, and both are recoverable — a wrong edit is visible and one git revert away. Deletion is the operation whose damage is invisible afterwards, so it stays in the admin UI where a human confirms it.
• Read and write are separate scopes Read is the default in the form. A read token calling a write tool is refused with the scope it has and the scope it needs. Tokens can carry an expiry, and revoking one takes effect on the next request.
• The token opens one door An API token authorises /api/mcp and nothing else — it cannot reach the rest of the admin API, cannot touch branding and cannot create another token. An admin browser session is not accepted on the endpoint either.
• It adds nothing to an AI bill The endpoint is a tool server. It answers an assistant's requests about your documentation and never calls a language model itself.

Getting started

No account, and no Git host either

There is no step where you create a repository first, mint a token, or sign up for anything. On its first start DocuWaves runs git init inside its own data volume, and every page you write from then on is a real commit in it.

• Local is a complete setup, not a trial Full page history, diffs, restore, attribution, and content that is plain Markdown you can read outside the app. The only thing you do not get is a copy somewhere else.
• A remote can be added at any point Put an empty repository's URL in .env and restart. The history you already have is pushed to it in full — every commit, not squashed into one import — and from then on the instance behaves like one configured with a remote on day one. Removing the URL again puts it back to local with everything intact.
• So back the volume up On a local-only instance ./data is the only copy of your documentation and nothing mirrors it. Back that directory up, clone it somewhere, or add a remote — the way you would with any other data you would miss.

The everyday things

The rest of it, briefly

• GitHub-flavored MarkdownTables, task lists and fenced code with syntax highlighting, written in a plain editor with a live preview a tab away.
• Diagrams as textA fenced mermaid block is drawn as a real diagram — in the preview, on the published page, and in GitHub's own file view.
• Images by paste or dragPaste a screenshot into the editor or drop files onto it: uploaded to the project's assets/, committed, and referenced at the cursor.
• Unsaved work survivesEditor text is kept in the browser and offered back when you return — never applied silently, and never uploaded.
• Full-text searchAcross every published page in every project, in the language and version the reader is currently in.
• Several projects, one instanceOne deployment serves the docs for every tool you maintain, each with its own categories and pages, shown as tiles.
• Multiple languages, optionallyA page can exist in several languages under one slug, with the language in the URL and an honest notice on a page not yet translated.
• Frozen versions, optionallyFreeze the docs at a release and they stay frozen, read-only and readable, while you keep editing the current ones.
• DraftsA page stays invisible to readers until you publish it, and a project with nothing published stays off the public site entirely.
• Branding per instanceName, logo, favicon, accent colour and footer come from a _site.yml in the content repository — versioned and reviewable like a page.
• Password login or OIDC SSOOne admin account, signing in with a password or through any standard OIDC provider — Authentik, Keycloak, Authelia, Zitadel.
• Real HTML for crawlersEvery public URL is answered with its own title, description, Open Graph tags, canonical and structured data, plus /sitemap.xml and /robots.txt.