Documentation-as-Code: Wiki.js, BookStack or Markdown in Git?

Documentation is the first thing that gets neglected under pressure. And it’s the first thing whose absence is regretted when a system fails at three in the morning and no one remembers how it was configured. The solution is not more discipline, but fewer barriers.

Why Markdown in Git Wins

Wiki.js and BookStack are good — but they are another system with its own login, its own interface, its own backup. Markdown in Git is not another system. It is a docs/ folder in the existing repository that every team member already has open.

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

The agent — Claude Code, Codex — knows this folder. It can read from it when writing code for a system, and it can document its changes there. A CLAUDE.md rule like "document changes in docs/" is enough.

Wiki.js: When the Web Interface Is Required

Some teams want a wiki with a rich-text editor, search function, versioning, and rights management. Wiki.js delivers that, including Markdown import and Git synchronization.

BookStack is the alternative with hierarchical structure (shelves → books → chapters → pages), which is better suited for structured knowledge bases than a flat wiki.

Both run as Docker containers, both can sit behind a reverse proxy, and both can support SSO via Keycloak.

What Needs to Be Documented

The list is short and pragmatic:

Architectural decisions: Why Proxmox, why Ceph, why Caddy — not what, but why
Configuration peculiarities: Deviations from the default that no one will guess in five years
Recovery procedures: Restoring backups, cluster recovery, disaster recovery
Access and responsibilities: Who has which keys, where are they stored?

Not to be documented: Anything that is in the code. Anything that can be automatically queried from the systems. Anything that becomes irrelevant after a year.

NIS2 Relevance

NIS2 requires documented security measures. Markdown in Git, versioned and with change history, is a valid and auditable proof for this.

Conclusion

Documentation-as-Code is the lowest barrier there is. Markdown in Git, written by the agent and reviewed by people. If more structure is needed, Wiki.js or BookStack can be added — but the foundation remains the text format that anyone can read.

FAQ

Why Markdown in Git instead of a finished wiki like Wiki.js?+

Because a docs/ folder in your existing repository needs no new login, no new backup, and no new interface — the barrier to writing drops to zero. Wiki.js and BookStack are good once rich-text editing and rights management matter, but they are another system that needs maintenance. If your team never touches the docs because they are too cumbersome to reach, Markdown in Git is the lowest entry barrier there is.

Can an AI agent really co-author the documentation?+

Yes, if you instruct it via a CLAUDE.md rule. An agent like Claude Code or Codex reads the docs/ folder when it writes code for a system and records its changes there. The result is not a finished text you trust without review — a human checks the diff just as with code. The gain is that documentation gets written at all, because it lives in the same workflow as the code rather than being deferred as a chore.

Does documentation-as-code help with NIS2?+

Yes. NIS2 demands documented security measures with a traceable change history. Markdown in Git is versioned, and every commit is an auditable proof of who changed what and when. That does not replace the substantive work of risk assessment, but it provides the technical evidence an auditor expects to see — without a separate compliance tool or yet another system to maintain.