DeepWiki self-hosted: deepwiki-open with a local model for your private repositories

A code wiki from your own repositories, on your own GPU

A self-hosted DeepWiki reads a private repository, generates documentation from the codebase as a wiki with architecture pages and diagrams, and answers questions about the code, all on a server in your network. The independent open-source project deepwiki-open (MIT) does this with a local LLM through Ollama or an OpenAI-compatible server such as vLLM. A workstation with one NVIDIA RTX PRO 5000 Blackwell 72 GB runs both the embedding model and a 30B coding model for a development department.

The original DeepWiki comes from Cognition. Its documentation describes a free version for public GitHub repositories at deepwiki.com, while wikis for the repositories a team connects are generated inside the Devin app, with medium- and high-effort wikis billed against the team's usage. The page mentions no self-hosted or on-premises option, so companies that cannot send code to a cloud service use one of the open-source rebuilds below.

What the tools do is the same in outline. They clone the repository, cut the code into chunks, turn each chunk into a vector with an embedding model, plan a page structure, and write each page with a language model that sees the most relevant chunks; deepwiki-open generates its diagrams as Mermaid code. The same index then serves a chat over the repository. This helps with onboarding new developers, with documenting code whose authors have left, and with the handover of a project from a contractor. For interactive coding help see our guide to a private coding assistant; this page is about documentation.

deepwiki-open in October 2026

deepwiki-open is published by AsyncFuncAI under the MIT licence and shows 18.3k stars on GitHub. Its commit history continues: the newest commits are of 28 October 2026 (a fix for DeepResearch) and 23 October 2026 (raised dependency floors for security advisories), and in September 2026 a LiteLLM Docker profile and an opt-in setting for storing prompts and responses in LiteLLM's spend logs were added. The English README has been cut down to a short description and a link titled "Deepwiki-Open 2.0 (Grok Wiki is now live)". Grok-Wiki is a different product: its site describes "a local-first desktop workspace", offers a macOS download and sends model calls through command-line agents such as Codex CLI or Claude Code. The self-hosted server is still in the repository with its Dockerfiles, configuration files and the Ollama instructions, and the translated READMEs, the French one for example, keep the full setup guide.

The setup guide describes a Next.js front end on port 3000 and an API on port 8001, started with docker-compose up or the image ghcr.io/asyncfuncai/deepwiki-open:latest. Data persists in ~/.adalflow, mounted into the container: cloned repositories in repos/, embeddings and indexes in databases/, generated pages in wikicache/. The compose file limits the container to 6 GB of memory. Private repositories are reached with a personal access token entered in the interface; the guide describes this for GitHub and GitLab and lists Bitbucket as a supported host. It does not mention self-managed GitLab or Bitbucket instances; the Ollama instructions show how to mount a local checkout under /app/local-repos, which works for any Git server you can clone from.

Keeping the code local by switching both model roles

deepwiki-open uses two models, and its defaults send both jobs to the cloud. In generator.json the default provider is Google with gemini-2.5-flash; in embedder.json the default embedder is OpenAI's text-embedding-3-small. The README states that an OpenAI key is needed for embeddings unless Ollama mode is used. A company that wants the code to stay in its network has to switch both roles.

The documented route is Ollama. The Ollama instructions pull nomic-embed-text for the index and qwen3:1.7b for the pages, and the embedder_ollama entry replaces the OpenAI embedder. The generator file lists three Ollama models with their context: qwen3:1.7b and qwen3:8b with num_ctx 32,000 and llama3:8b with 8,000. Any model you have pulled can be entered there, and a larger one writes better pages: the instructions themselves note that "Local models may not match the quality of the latest cloud models". The second route is an OpenAI-compatible server: OPENAI_BASE_URL points the OpenAI provider at your vLLM endpoint, and the README describes a separate embedder file for OpenAI-compatible embedding services.

The retrieval settings in embedder.json explain the load. The text splitter cuts by words into chunks of 350 with an overlap of 100, so a new chunk starts every 250 words, and each retrieval returns the top 20 chunks. A request built on one retrieval therefore carries about 7,000 words of code and text by our arithmetic, plus the instructions; how many tokens that is depends on the language and the code, as our article on tokens per word explains. A context of 32K tokens is the sensible minimum.

The file filter in repo.json matters as much as the models. By default it skips docs directories, lock files, configuration files such as .env and pyproject.toml, CI files and binaries, and reads a fixed list of code and document extensions: Python, JavaScript and TypeScript, Java, C and C++, Go, Rust, PHP, Swift, C#, HTML and CSS, plus Markdown, text, JSON and YAML. Kotlin or COBOL files, for example, are not in the default list, so check it against your languages before the first run.

You can order the workstation alone, the setup of Ollama or vLLM, nomic-embed-text, a coding model and deepwiki-open alone, or both together: the workstation delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

OpenDeepWiki and other DeepWiki alternatives

OpenDeepWiki, from AIDotNet, is a second open-source rebuild under the MIT licence, with 3.6k stars. Its README describes a backend on ASP.NET Core with .NET 10, a Next.js front end, SQLite or PostgreSQL, and imports from Git URLs, ZIP archives or approved local directories. AI providers and models are managed in its admin console; in compose.yaml the main model is set with ENDPOINT and the request type OpenAI, which is where an OpenAI-compatible server such as vLLM is entered (test it in a pilot), while OPENAI_BASE_URL and the Ollama settings belong to the optional Graphify add-on. It has user accounts with JWT, roles, departments and API keys, which deepwiki-open's documentation does not describe, and repository-scoped MCP endpoints at /api/mcp. The README publishes the default seeded administrator credentials and itself says to change the JWT secret and the admin password before any real deployment.

Teams that already run an internal AI search across Confluence or SharePoint may prefer to add repositories there; our article on Onyx as a self-hosted AI search covers that route. A wiki generator differs in that it writes structured pages per repository, which a new developer reads in order.

Which GPU runs a self-hosted DeepWiki

Both models fit on one card for a small team. nomic-embed-text v1.5 has 137 million parameters, is 274 MB in Ollama's library and is licensed under Apache 2.0; its Hugging Face card lists a sequence length of 8,192. The generation model takes the rest. We size by our users-per-card rule: 90 per cent of the memory the driver reports, less 3 GiB per card, less the weights of both models, divided by the cache per request. That leaves 18.5 GiB on a 24 GB RTX PRO 4000, 40.0 GiB on the RTX PRO 5000 48 GB, 61.5 GiB on the 72 GB version and 83.0 GiB on a 96 GB RTX PRO 6000.

Requests of 32K tokens at once by our users-per-card rule, beside nomic-embed-text (274 MB), BF16 cache (FP8 cache in brackets; gpt-oss-20b with BF16 cache only). Weights from Hugging Face, read 30 October 2026: gpt-oss-20b 13.76 GB, Qwen3-Coder-30B-A3B FP8 31.2 GB. Cache per 32K: 0.75 GiB (gpt-oss-20b), 3 GiB (Coder-30B-A3B), by our arithmetic from each config.json.

gpt-oss-20b is a 21B model with 3.6B active parameters under Apache 2.0, which OpenAI's card says runs "within 16GB of memory" thanks to MXFP4. It writes readable pages and fits the smallest card. Qwen3-Coder-30B-A3B (30.5B, 3.3B active, Apache 2.0) is a model trained for code and needs the 48 or 72 GB card; on the 48 GB version the room for requests is small, so the 72 GB card is the comfortable mid tier, as our comparison of the RTX PRO 5000 48 GB and 72 GB sets out. Both versions of the RTX PRO 5000 are 300 W cards; a workstation with one of them draws about 0.75 kW at the wall by our estimate (300 W plus a 350 W-class processor, plus 15 per cent for the rest).

How long the first pass over a repository takes depends on the size of the repository, the number of pages in the wiki, the length of each page and how many requests the tool sends at once. deepwiki-open publishes no throughput figures. The nearest published number is NVIDIA's maximum-throughput table, in which one RTX PRO 6000 Server Edition produces 1,914 output tokens per second on Qwen3-30B-A3B in FP4 with 8,192-token prompts and 374 with 32,768-token prompts, with all requests queued at once; a tool that writes one page after another reaches far less. The embedding pass is small by comparison: a repository with two million words of code gives about 8,000 chunks by our arithmetic, each embedded once per full index.

Keeping the wiki current and correct

A generated wiki ages with every merge. deepwiki-open caches generated pages in wikicache/ and documents no update per merge, so plan a regeneration as a scheduled job outside working hours, and test how your version triggers it. Nightly is enough for most teams; a repository in a large refactoring may need it after each release instead. On a server shared with the coding assistant, these runs fill the hours when the developers' agents are idle, as in our article on batch LLM inference. If you plan such a shared server, ask us which cards suit both jobs.

The pages are drafts, and a language model can describe an architecture that is not there. Mark the wiki as generated, give each repository a maintainer who reads the overview pages after the first run, and keep the hand-written architecture decisions where they are.

Access control for the wiki and the model server

A wiki built from a private repository contains the same knowledge as the repository, and everyone who can open the wiki reads it. deepwiki-open has one shared protection, an authorisation code set with DEEPWIKI_AUTH_MODE and DEEPWIKI_AUTH_CODE, and its README warns that this code does not fully prevent generation if the API endpoints are reached directly. The compose file publishes ports 3000 and 8001 on the host. Put the server behind a reverse proxy with your company sign-in, keep port 8001 off the network, and run separate instances for repositories with different readers, or use OpenDeepWiki with its roles. The access tokens for the Git server should be read-only and belong to a service account.

The model server needs the same care: Ollama 0.35.0 or later and vLLM on an internal address only, as our article on securing a GPU server explains. An offline installation, with models and images brought in without internet access, follows our guide to an air-gapped LLM server.

We set up the wiki, the models and the access in front of them on your system; tell us how many repositories you want documented and who should read them, and we propose the configuration for your tasks and budget.

FAQ