Context7 and DeepWiki on a private repo: what does each one cover?

Context7 indexes a project's written documentation; DeepWiki builds a conversational wiki from a repository, and its public server only covers public repos. On a private repository both switch you to a paid plan, and neither product's documentation describes access to commits or diffs.

That last sentence is the one that matters if you are shopping for an alternative for your own product. What separates these tools is not quality, which is good on both sides. It is three lines: what they read, who is allowed to ask, and whether they can answer a question about change. Here are the facts, taken from their public documentation on 16 September 2026, followed by the tree that settles the choice in three questions.

Two short definitions

Context7, published by Upstash, presents itself as up-to-date documentation for LLMs and AI code editors. You hand it a repository and it reads the documentation files: .md, .mdx, .markdown, .rst, .txt, .ipynb. Its docs are candid about the boundary: "Raw source code files (.py, .ts, .go, and so on) are not indexed when documentation is present." When docs exist, the docs are the source, not the code. For a public repository with no documentation, examples are generated from the sources instead. On the private side, adding a source requires a Pro or Enterprise plan, with a git token or a connected GitHub account, and generating docs from code is an option you tick (generateDocs through the API). Refreshing happens automatically based on library popularity, and a GitHub Action can trigger it on every push to the default branch.

DeepWiki, published by Cognition — the team behind Devin — builds a wiki of a repository and makes it conversational. Its MCP server lives at https://mcp.deepwiki.com/mcp, and its documentation describes a free, remote, no-authentication service giving access to public repositories. It exposes three tools: read_wiki_structure, read_wiki_contents, ask_question. For a private repository, the same page sends you to a Devin account and the Devin MCP server, with an API key.

Hold on to the shape of each one. Context7 is an index of text. DeepWiki is a generated artefact you read back. Both are good objects, and they answer different questions.

The decision tree, in three closed questions

Take your repository and walk down. Each answer rules something out.

Question 1: is your repository public?

If yes, stop here. Both tools are on home ground, the DeepWiki server is free and needs no token, and Context7 covers most of the libraries your code imports. Nothing below applies to you, and wiring both into your editor is a good move.

If no, keep going.

Question 2: is the answer you want already written in your documentation?

If yes, Context7 on a Pro plan does the job: it will read your Markdown files and serve them to your agents. That is the right pick when documentation is rich, kept current, and the questions people ask are about what it contains.

If no — if the answer lives in the code and nowhere else — keep going.

Question 3: is your question about a state or about a change?

A state: what is this setting called, what is its default, which endpoint does what. A generated wiki or an indexed doc set can carry that, provided they were regenerated after your last deploy.

A change: what moved since v2.3, why does this behaviour differ now, does this release break an integration. Here you have walked out of both tools' territory. A difference needs two states and the machinery that links them, which is git history. Neither documents access to commits or diffs; DeepWiki's three tools read a wiki structure, read wiki contents, and ask a question, and not one of them takes a date or a range.

The gap, and why it is not an oversight

The gap is nobody's failure. Context7 was built so your coding assistant stops inventing a library's API from training memories, and it does that well. DeepWiki was built so you can understand a repository you did not write, quickly, and the generated wiki often beats the README.

Both missions share one assumption: the subject of the question is a stable project you are discovering. Your private product is not that. It moves several times a day, the people asking already know it, and what they want is almost always what has shifted since last time.

There is a second difference, less visible and more decisive day to day: who does the asking. Context7's paid tier and Devin's model both run through an account and a key on the requester's side. Your Intercom support agent has no Devin account. An agency's client under NDA will never hold a token on the repository. These requesters are not edge cases. They are the ones asking the most questions about your product.

"I'll generate my docs and feed them to Context7"

This objection deserves a real answer, because it partly works. A pipeline that generates documentation on every release, pushed into a repository indexed by Context7 with the GitHub Action, gives you a private index that is current at every push. Plenty of teams will be fine with that, and they will be right.

Two things do not follow. Generated documentation contains what the generator was taught to put in it, and drift starts at that boundary: a default value changed in a config file only shows up if someone planned for it. And an index stays an index. It knows the latest published state, not the sequence of states. The "why" is never in it, because the intent behind a change lives in the diff and the commit message, not in the page describing the result.

The tooled option exists too, and we have written it up plainly: the official GitHub MCP server gives access to the GitHub API, diffs included. It wants a token per requester, which lands you back on the previous question.

"But DeployIt reads your repository as well"

It does, and the frame is the one we expect others to state. The GitHub connection is read-only and revocable at any time. One project, one server, and no window from one into another. Content is resynced on every push, with no human gesture to remember.

What leaves the server is answers sourced from commits and diffs, never raw source code handed back. That asymmetry is what lets you wire in a third-party platform without giving it a GitHub token: it gets the information, not the access. The mechanism is laid out in our comparison of MCP and RAG for codebase knowledge.

What we are not replacing

Let us be clear about the split. For the open source libraries your code imports, Context7 is the right tool, and one MCP server per project does not pretend to replace it. To read an unfamiliar public repository before contributing to it, DeepWiki's wiki is free and fast, and there is no reason to look further.

All three sit side by side in the same agent, in fact. An assistant can query Context7 for a framework function signature, DeepWiki for the architecture of an open source dependency, and your product's own expert for what your last release changed. They are not competing for the same slot.

Mini-FAQ

Will Context7 read my code if I have no documentation? On a public repository with no docs, its page explains that examples are generated from the sources. On a private repository that generation is an option you enable, on a paid plan.

Can the free DeepWiki server see my private repo if I give it the URL? Its documentation describes a no-authentication service providing access to public repositories, and routes private repos to Devin. A private URL does not cross that boundary.

Does every person need a GitHub token to query a product expert? No, and that is the difference in model. The server is connected to the repository once; requesters query the server, not GitHub.

How often does the index refresh? With Context7, automatically by popularity, or on every push through the GitHub Action. With DeployIt the question works differently: there is no index to regenerate, the question triggers the read. We cover that in Claude project knowledge compared with an MCP server.

What to take away

Context7 indexes written documentation and shines on public libraries. DeepWiki generates a conversational wiki and shines on public repositories you are discovering. Both open a paid door to private code, and neither promises history.

If your questions are about your private product and start with "what changed", you are looking for something else: a source wired to the code and its history, queryable by the people and the agents who have no access to the repository.

DeployIt is free during early access; paid plans arrive in January 2027. The MCP server is still in early access: the design partner program opens it to teams willing to put it to the test on their own repository.