OpenDeepWiki (AIDotNet)

Built by AIDotNet.

An open-source (MIT, ~3.5k★) platform that turns a code repository into a browsable wiki: point it at a Git remote, a ZIP, or a local directory and it indexes the contents, then generates a README summary, a project overview, a wiki catalog, translations into other languages, and a Mermaid mind map. The result is served as a public documentation site with chat over it, an embedding API, and a per-repository MCP endpoint. Written in ASP.NET Core (.NET 10) with a Next.js/React front end, SQLite or Postgres behind it, and background workers doing the translation, mind-mapping, and scheduled re-generation; ships as Docker Compose. An admin console manages repositories, users, roles, API keys, and which AI provider does the generating.

Tier: T3 — first-party project README. Everything below is the maintainers’ description of their own software; there is no independent evaluation of how good the generated documentation actually is, which is the number the whole sub-genre is missing.

What it adds to the thread

The wiki-memory essay named a codebase-documentation sub-genre of the llm-wiki pattern and gave two examples, deepwiki (Cognition) and autowiki (Factory). Both are hosted vendor products. This is the same idea as a self-hostable MIT-licensed component you point at your own provider key — the sub-genre’s open-source instance, and the first one this wiki holds where you can read what the thing actually does rather than the marketing page for it.

Two details are worth keeping:

• Scheduled re-generation. autowiki‘s pitch is documentation that stays current; here that durability claim is a background worker on a schedule. It re-derives the wiki from the repository rather than editing it in place, so the code is the only source of truth and the wiki is a rendering of it. That’s the opposite arrangement from this hub, where raw/ is immutable and the pages accumulate judgment that no re-run could reproduce.
• The wiki as an endpoint. Serving each repository over MCP makes the generated documentation an agent-readable interface, not just a website. The read path is neither of the two poles llm-knowledge-base set out (grep an index vs embed and retrieve) — it is a third: the wiki is published as a tool another agent calls. (Cross-spoke: MCP-as-integration-surface is agentic-tooling-wiki’s subject; the wiki-as-substrate half is here.)

Where it is thin

Generation is one-directional. Nothing in the description covers what happens when the generated wiki is wrong — no human correction path, no contradiction flagging, no log of what changed between runs. The maintenance question this lineage keeps circling, Bush’s “who keeps the trails?”, is answered by deleting the trails and drawing new ones each cycle. That works for documentation whose only referent is the code. It is not available to a wiki whose value is the synthesis across sources.

Related

deepwiki · autowiki · wiki-memory · llm-wiki · llm-knowledge-base · model-context-protocol