Dokumentation-as-Code: Wiki.js, BookStack oder Markdown im Git?

Dokumentation ist das erste, was im Stress liegenbleibt. Und das erste, dessen Fehlen man bereut, wenn ein System um drei Uhr früh ausfällt und niemand mehr weiss, wie es konfiguriert war. Die Lösung ist nicht mehr Disziplin, sondern weniger Hürde.

Warum Markdown im Git gewinnt

Wiki.js und BookStack sind gut — aber sie sind ein weiteres System mit eigenem Login, eigener Oberfläche, eigenem Backup. Markdown im Git ist kein weiteres System. Es ist ein Ordner docs/ im bestehenden Repo, das jeder im Team schon offen hat.

docs/
  netzwerk/
    vlans.md
    wireguard.md
  server/
    proxmox-cluster.md
    backup-strategie.md
  software/
    winline-integration.md
    mcp-server.md

Der Agent — Claude Code, Codex — kennt diesen Ordner. Er kann daraus lesen, wenn er Code für ein System schreibt, und er kann seine Änderungen darin dokumentieren. Ein CLAUDE.md-Regel „document changes in docs/" reicht.

Wiki.js: Wenn die Weboberfläche sein muss

Manche Teams wollen ein Wiki mit Rich-Text-Editor, Suchfunktion, Versionierung und Rechteverwaltung. Wiki.js liefert das, inklusive Markdown-Import und Git-Synchronisation.

BookStack ist die Alternative mit hierarchischer Struktur (Regale → Bücher → Kapitel → Seiten), die sich für strukturierte Wissensdatenbanken besser eignet als ein flaches Wiki.

Beide laufen als Docker-Container, beide können hinter dem Reverse Proxy stehen, beide können SSO via Keycloak.

Was dokumentiert werden muss

Die Liste ist kurz und pragmatisch:

Architekturentscheidungen: Warum Proxmox, warum Ceph, warum Caddy — nicht was, sondern warum
Konfigurationsbesonderheiten: Abweichungen vom Default, die in fünf Jahren keiner mehr errät
Wiederherstellungsprozeduren: Backup-Zurückspielen, Cluster-Wiederherstellung, Disaster-Recovery
Zugänge und Verantwortlichkeiten: Wer hat welche Schlüssel, wo liegen sie?

Nicht dokumentiert werden muss: Alles, was im Code steht. Alles, was automatisch aus den Systemen abfragbar ist. Alles, was nach einem Jahr irrelevant ist.

NIS2-Relevanz

NIS2 verlangt dokumentierte Sicherheitsmassnahmen. Markdown im Git, versioniert und mit Änderungshistorie, ist dafür ein valider und auditierbarer Nachweis.

Fazit

Dokumentation-as-Code ist die niedrigste Hürde, die es gibt. Markdown im Git, vom Agenten mitgeschrieben, von Menschen geprüft. Wer mehr Struktur braucht, nimmt Wiki.js oder BookStack dazu — aber die Basis bleibt das Textformat, das jeder lesen kann.

FAQ

Warum Markdown im Git statt eines fertigen Wikis wie Wiki.js?+

Weil ein docs/-Ordner im bestehenden Repo keine neue Anmeldung, kein neues Backup und keine neue Oberfläche braucht — die Hürde zu schreiben sinkt auf null. Wiki.js und BookStack sind gut, sobald Rich-Text-Editoren und Rechteverwaltung gefragt sind, aber sie sind ein weiteres System, das gepflegt werden will. Wer die Doku eh nie anfasst, weil sie zu umständlich zu erreichen ist, hat mit Markdown im Git die niedrigste Einstiegshürde, die es gibt.

Kann ein KI-Agent die Dokumentation wirklich mitschreiben?+

Ja, wenn man es über eine CLAUDE.md-Regel anweist. Ein Agent wie Claude Code oder Codex liest den docs/-Ordner, wenn er Code für ein System schreibt, und trägt Änderungen dort nach. Das Ergebnis ist keine Selbstverständlichkeit ohne Prüfung — ein Mensch kontrolliert den Diff wie beim Code auch. Der Gewinn ist, dass Dokumentation überhaupt entsteht, weil sie im selben Workflow wie der Code entsteht und nicht als lästige Nebensache liegenbleibt.

Hilft Dokumentation-as-Code bei NIS2?+

Ja. NIS2 verlangt dokumentierte Sicherheitsmassnahmen mit nachvollziehbarer Änderungshistorie. Markdown im Git ist versioniert, jeder Commit ist ein auditierbarer Nachweis, wer wann was geändert hat. Das ersetzt nicht den inhaltlichen Aufwand der Risikobewertung, aber es liefert den technischen Beweis, den ein Auditor sehen will — ohne separates Compliance-Tool oder ein weiteres System, das manzusätzlich pflegen muss.