OpenDeepWiki: self-hosted AI docs, chat and MCP for your Git repositories

The gap OpenDeepWiki fills between a repository and its documentation

Reading an unfamiliar codebase is mostly a search problem. You know roughly what you want to find out, you do not know which file answers it, and the README covers only the entry points the original author cared about. OpenDeepWiki takes a repository source and produces a structured knowledge base from it: a README summary, a project overview, a wiki catalog, document content, optional multi-language translations, Mermaid mind maps and optional Graphify artifacts. The README describes the output as "AI-driven repository knowledge base with docs, chat, and MCP".

The intended audience is not a solo developer browsing a side project. It is a team that wants a searchable internal index over many repositories, served on SEO-friendly routes such as /{owner}/{repo}, /{owner}/{repo}/mindmap and /{owner}/{repo}/graphify, and reachable from a chat assistant or an MCP client. The admin console manages repositories, users, roles, departments, API keys, AI providers and models, skills, MCP providers and GitHub App imports, which tells you the design target is an organization rather than a laptop.

That framing matters when you evaluate it. The unit of work is a repository, and the unit of cost is a generation run against a model provider. Both scale with how much code you point it at.

How the processing pipeline actually moves data

The README gives a Mermaid diagram and a five-step description of the runtime path. The source is normalized first and a workspace is prepared under REPOSITORIES_DIRECTORY. Repository metadata, branch and language state, and processing logs are then built or refreshed. Documentation catalogs and document content are generated through the configured AI provider and model bindings. Follow-up work is queued: translation, mind map generation, Graphify artifacts and incremental updates. The final knowledge is served through the public web app, admin tooling, chat APIs and MCP endpoints.

The layer table fills in the implementation. The backend is ASP.NET Core on .NET 10 with MiniApis and background workers. AI orchestration uses Microsoft.Agents.AI with prompt assets under src/OpenDeepWiki/prompts and provider/model binding from settings. The frontend is Next.js 16 with React 19 and the App Router. Storage is SQLite or PostgreSQL. Repository processing uses LibGit2Sharp plus ZIP and local-directory ingestion.

Two design decisions stand out. First, the model binding is split into three independent slots, CHAT_*, WIKI_CATALOG_* and WIKI_CONTENT_*, each with its own model, endpoint, key and request type. Catalog generation and content generation are different workloads with different token profiles, so pointing them at different models is a real cost lever. Second, translation is optional: if WIKI_TRANSLATION_* is not set, it falls back to the content-generation provider and model. That is convenient, and it also means enabling twelve languages silently multiplies your content-generation spend unless you set the translation slot explicitly.

The workers are the part that determines how the system feels in use. Catalog and content generation are queued, so the web UI becomes useful before a large repository finishes processing. The trade-off is that a stuck worker looks like a slow import rather than an error, and the README does not document a queue inspection command.

Installing OpenDeepWiki with Docker Compose

The README's quick start assumes Docker with Compose support and at least one LLM API key compatible with your chosen provider. Clone the repository and move into it:

git clone https://github.com/AIDotNet/OpenDeepWiki.git
cd OpenDeepWiki

Next edit compose.yaml. The README says to set a real JWT secret and your AI credentials at minimum. The three groups below can point at the same provider:

services:
  opendeepwiki:
    environment:
      - JWT_SECRET_KEY=replace-this-in-production
      - CHAT_API_KEY=your-chat-api-key
      - ENDPOINT=https://api.openai.com/v1
      - CHAT_REQUEST_TYPE=OpenAI
      - WIKI_CATALOG_MODEL=gpt-4o
      - WIKI_CATALOG_ENDPOINT=https://api.openai.com/v1
      - WIKI_CATALOG_API_KEY=your-catalog-api-key
      - WIKI_CATALOG_REQUEST_TYPE=OpenAI
      - WIKI_CONTENT_MODEL=gpt-4o
      - WIKI_CONTENT_ENDPOINT=https://api.openai.com/v1
      - WIKI_CONTENT_API_KEY=your-content-api-key
      - WIKI_CONTENT_REQUEST_TYPE=OpenAI

The shipped compose.yaml maps port 18081 on the host to 8080 in the container, sets REPOSITORIES_DIRECTORY=/data, and defaults to Database__Type=sqlite with ConnectionStrings__Default=Data Source=/data/opendeepwiki.db. Start the stack with either the raw command or the Makefile shortcut:

docker compose up -d --build
make build
make up

The README lists the web UI at http://localhost:3000 and backend health at http://localhost:8080/health. On a fresh database the seeded admin account is [email protected] with password Admin@123, and the README states plainly that both the default JWT secret and the admin password should be changed before any real deployment. Note the port mismatch between the README's quick start and the repository's compose.yaml: the file publishes 18081, so check which one you actually started before assuming the UI is unreachable.

Pointing an MCP client at a repository scope

The MCP surface is the feature that distinguishes OpenDeepWiki from a documentation generator. The README says official MCP endpoints are registered at /api/mcp and /api/mcp/{owner}/{repo}, and that you can scope a repository by path or by query string. The path form looks like this:

{
  "mcpServers": {
    "OpenDeepWiki": {
      "url": "http://localhost:8080/api/mcp/AIDotNet/OpenDeepWiki"
    }
  }
}

The query-based alternative is http://localhost:8080/api/mcp?owner=AIDotNet&name=OpenDeepWiki. MCP can be turned off with MCP_ENABLED=false.

The important detail is the scoping model. /api/mcp exposes the whole instance, while /api/mcp/{owner}/{repo} restricts the endpoint to one repository. In a multi-tenant deployment that distinction is the difference between an assistant that can see every indexed repository and one that can only see the repository you pointed it at. The README does not describe how MCP endpoint authorization interacts with the users, roles and API keys managed in the admin console, so treat the unscoped endpoint as an internal-only surface until you have confirmed that behaviour against your own deployment.

Where OpenDeepWiki is the wrong tool

The clearest limitation is that output quality is entirely a function of the model you bind. Nothing in the pipeline verifies generated documentation against the source, and the README does not describe a review or approval step between generation and publication. On the public routes, generated content is served directly. If a catalog model hallucinates a module boundary, that error ships to the same URL a reader trusts.

Cost is the second constraint, and it is easy to underestimate because the parallel count is a single knob. WIKI_PARALLEL_COUNT defaults to 5, and WIKI_LANGUAGES defaults to en,zh,zh-tw,ja,ko,es,fr,de,pt-br,pl,ru,ar. Twelve languages across a large repository is twelve times the content-generation work unless you trim the language list or bind translation to a cheaper model. The README does not publish token estimates per repository, so there is no way to predict the bill from the documentation alone.

Operationally, the stack is heavier than a static site generator. You are running .NET 10, Next.js 16, a database and background workers. The compose file sets user: "0:0", which runs the container as root, and RepositoryAnalyzer__AllowedLocalPathRoots__0 defaults to a host path used for approved local-directory imports. That default is a development convenience, not a production boundary. And if your need is a single README for a small library you already understand, a generation pipeline with a database and a worker queue is more machinery than the task deserves.

OpenDeepWiki compared with hosted DeepWiki

The related searches pair OpenDeepWiki against the hosted DeepWiki service, and the difference is not cosmetic. The hosted service indexes public repositories and you read the result; you supply nothing and you control nothing. OpenDeepWiki is the version you operate: you supply the Git credentials, the model keys, the database and the storage, and in exchange you can index private repositories, local directories and uploaded ZIP archives that a hosted service would never see.

That trade runs in both directions. With the hosted route, indexing quality is someone else's problem and the marginal cost of adding a repository is zero to you. With OpenDeepWiki, every repository is a generation run against your provider account, and every language you enable multiplies it. You also inherit the upgrade cycle: the project has shipped v2.0.4, v2.0.5 and v2.0.6, with the most recent release on 2026-09-08, so the API surface and the environment variables are still moving.

There is a middle path worth naming. If you only need the chat and MCP surface over repositories you already index elsewhere, OpenDeepWiki's MCP endpoints are the part to evaluate, and you can leave WIKI_LANGUAGES at a single language to keep generation cheap. If you need the full public documentation site with mind maps and Graphify artifacts, you are committing to the whole pipeline.

Maintenance, licence and the upgrade surface

OpenDeepWiki is MIT licensed, which places few restrictions on how you run or modify it. The practical licence question is not the code but the generated content: documentation produced by your model provider is subject to that provider's terms, and the repository's MIT licence says nothing about it. That is worth checking with whoever owns your provider contract rather than assuming the project's licence settles it.

The repository is not archived and the last push was on 2026-09-08, so the project is being worked on. The upgrade surface is wide. Configuration is spread across environment variables with two naming conventions for the same setting: Database__Type and DB_TYPE, or ConnectionStrings__Default and CONNECTION_STRING. The README presents these as equivalent pairs, which is helpful at first contact and awkward later, because a deployment can drift between the two styles. The compose.yaml uses the double-underscore form while .env.example uses the flat form, so a team copying from both files can end up with contradictory values and no obvious signal about which wins.

Before upgrading, the things to diff are the environment variable names and the compose files. The project ships compose.yaml and compose.pgsql.yaml separately, and the PostgreSQL path requires either the bundled stack or a hand-written connection string. There is no documented migration command for the SQLite database, so back up the file at /data/opendeepwiki.db before pulling a new release.

Editorial conclusion

Adopt OpenDeepWiki if you want repository documentation, chat and MCP endpoints inside your own network, and you are willing to run a .NET 10 backend, a Next.js frontend and at least one LLM provider key. Do not adopt it if you need a zero-configuration hosted service, or if you cannot absorb the per-generation model spend across a large repository set. Before rolling it out, verify three things: that your chosen provider works with the WIKI_CATALOG_* and WIKI_CONTENT_* bindings, that the generated output for one representative repository is accurate enough to publish, and that your JWT_SECRET_KEY and the seeded admin password have both been replaced.

Frequently asked questions

Official sources

1. AIDotNet/OpenDeepWiki on GitHub
2. License: MIT
3. Project website
4. README
5. Releases