DeepWiki-Open: aus einer Repository-URL ein Wiki mit Codemap machen

Was DeepWiki-Open aus einer Repository-URL macht

AsyncFuncAI/deepwiki-open nennt sich im Untertitel eine eigene Nachimplementierung von DeepWiki. Der Ablauf ist knapp beschrieben: Man gibt einen Repository-Namen ein, und das Werkzeug analysiert die Struktur des Codes, schreibt eine Dokumentation, erzeugt Diagramme, sortiert alles in ein navigierbares Wiki und legt einen Codemap für geführte Rundgänge durch den Code an. Unterstützt werden laut README Repositories auf GitHub, GitLab und Bitbucket. Das Repository selbst ist in TypeScript geführt und steht unter MIT.

Die Zielgruppe sind Menschen, die fremden Code lesen müssen, ohne ihn lokal aufzusetzen. Genau daran scheitert die Einarbeitung meist zuerst: Die README eines unbekannten Projekts beschreibt den Einstieg, aber selten, welche Module zusammenhalten. Ein erzeugtes Wiki verschiebt die Arbeit vom Lesen auf das Prüfen, und ob das trägt, hängt an der Qualität der Texte. Dazu macht das README keine messbaren Angaben.

FastAPI unter api/ und Next.js unter src/: der Weg vom Klonen zum Wiki

Der Aufbau teilt sich in eine API und eine Weboberfläche. Im Verzeichnis api/ liegt ein FastAPI-Server, der das Klonen, die Analyse, die Vektoreinbettungen und das Erzeugen der Dokumente übernimmt; dort finden sich auch eigene Module für die abrufgestützte Beantwortung und für die Datenaufbereitung. Das Frontend unter src/ ist eine Next.js-Anwendung und zeichnet die Diagramme über eine eigene Mermaid-Komponente. Der Ablauf beginnt mit einer URL, prüft, ob das Repository privat ist, klont den Code, baut Einbettungen auf, wählt einen Modellanbieter, schreibt Texte und Diagramme und stellt das Ergebnis als Wiki dar.

Für private Repositories ist laut README ein persönliches Zugriffstoken nötig. Damit liegt der Quellcode eines internen Projekts während der Verarbeitung auf dem Rechner, der DeepWiki-Open betreibt, und zusätzlich bei dem Modellanbieter, der die Texte erzeugt. Wer das Werkzeug für firmeninterne Repositories einsetzen will, sollte diese beiden Abflüsse vorher klären. Das README geht darauf nicht ein, obwohl es die entscheidende Frage für diese Nutzungsart ist.

docker-compose mit .env oder Poetry plus npm run dev

Für den lokalen Betrieb nennt das README zwei Wege. Der kürzere führt über Docker: Repository klonen, eine .env-Datei mit den API-Schlüsseln anlegen und docker-compose aufrufen. Dabei wird ein Verzeichnis des Hosts eingehängt, damit geklonte Repositories, Einbettungen und zwischengespeicherte Wiki-Inhalte über einen Neustart des Containers hinaus erhalten bleiben. Wer ohne diesen Mount arbeitet, baut bei jedem Neustart alles neu auf und bezahlt die Einbettungen erneut.

Der zweite Weg ist die manuelle Einrichtung. Die Python-Abhängigkeiten kommen über Poetry, mit python -m pip install poetry==2.0.1 und poetry install -C api, danach startet python -m api.main den API-Server. Für die Oberfläche folgen npm install oder yarn install sowie npm run dev oder yarn dev, erreichbar unter http://localhost:3000. Der API-Server liegt auf Port 8001. Das README rät bei Problemen, beide Server neu zu starten, und empfiehlt für große Repositories, zunächst ein kleineres auszuprobieren. Diese Empfehlung ist aufschlussreich, weil sie einräumt, dass die Größe des Repositories ein praktisches Limit setzt.

GOOGLE_API_KEY, OPENAI_API_KEY und der OpenAI-Schlüssel für Ollama-Nutzer

Als Modellanbieter kommen Google Gemini, OpenAI, OpenRouter und lokal betriebenes Ollama in Frage. Als Vorgabe nennt das README gemini-2.5-flash für Google, gpt-5-nano für OpenAI und llama3 für Ollama. Die Schlüssel gehören in die .env-Datei, namentlich GOOGLE_API_KEY, OPENAI_API_KEY und OPENROUTER_API_KEY. Ein Punkt wird ausdrücklich erwähnt und wird leicht übersehen: Wer kein Ollama einsetzt, braucht trotzdem einen OpenAI-Schlüssel, weil die Einbettungen darüber laufen. Lokale Modelle befreien also nicht vollständig von einem externen Anbieter.

Die Konfiguration liegt in api/config/ und steuert Generator, Einbettungen sowie das Verhalten beim Klonen. Ihr Ort lässt sich mit DEEPWIKI_CONFIG_DIR verschieben, was bei einem Container-Setup mit eingehängten Volumes hilfreich ist. Für OpenAI-kompatible Einbettungsmodelle wie Alibaba Qwen beschreibt das README eine eigene Konfigurationsdatei und das Setzen von OPENAI_BASE_URL. Welche Schlüssel die Dateien im Einzelnen enthalten, steht im README nicht.

RAG-Fragen und Deep Research mit maximal fünf Iterationen

Neben der Dokumentationserzeugung gibt es eine Frage-Antwort-Funktion auf RAG-Basis, die Antworten aus tatsächlichen Code-Ausschnitten zieht, sie in Echtzeit streamt und einen Gesprächsverlauf mitführt. Der Verlauf ist der Grund, warum sich Rückfragen stellen lassen, ohne den Kontext neu aufzubauen. Er kostet aber auch Token, und wie lange er gehalten wird, ist nicht dokumentiert.

Die zweite Funktion trägt den Namen Deep Research. Sie legt zuerst einen Forschungsplan an, liefert dann über mehrere Iterationen Zwischenergebnisse und schließt mit einer Zusammenfassung. Die Untersuchung läuft von selbst weiter, bis ein Abschluss erreicht ist, höchstens jedoch über fünf Iterationen. Aktiviert wird sie über einen Schalter in der Oberfläche, bevor eine Frage gestellt wird. Diese Obergrenze ist vernünftig, weil eine Schleife ohne Ende bei einem Modell, das sich in Details verfängt, teuer wird. Fünf Iterationen sind keine Garantie für Vollständigkeit, sondern eine Kostenbremse.

DEEPWIKI_AUTH_MODE ist keine Grenze, und was Ausgabe 2.0 verschiebt

Zur Absicherung existiert ein Autorisierungsmodus, der über DEEPWIKI_AUTH_MODE aktiviert wird und die Wiki-Erzeugung auf Nutzer mit gültigem Code beschränkt. Das README sagt dazu selbst, dass dieser Modus den direkten Zugriff auf die API nicht vollständig blockieren kann und deshalb keine Sicherheitsgrenze darstellt. Wer das Werkzeug in einem Netz mit mehreren Nutzern betreibt, muss die Absicherung vor dem API-Server einrichten und darf sie nicht im Werkzeug suchen. Zusammen mit dem Hinweis, bei Problemen beide Server neu zu starten, zeichnet das ein Bild eines Werkzeugs, das für den Betrieb durch eine Person oder ein kleines Team gedacht ist.

Daneben steht die MIT-Lizenz, die Nutzung, Veränderung und Vertrieb erlaubt und jede Gewährleistung ausschließt. Eine zweite Beobachtung betrifft die Ausrichtung des Projekts: Das README kündigt die Ausgabe 2.0 an, die unter dem Namen Grok Wiki zum Herunterladen bereitsteht, und die Startseite des Projekts verweist auf genau diese Adresse. Wer nur Wikis erzeugen will, kann dieses fertige Programm nehmen und spart sich Container, Schlüssel und Ports. Wer den Code im eigenen Netz behalten muss, bleibt beim Selbstbetrieb und trägt dafür den Abgleich der Versionen selbst.

Redaktionelles Fazit

Geeignet ist DeepWiki-Open für Teams, die ein fremdes Repository schnell überschaubar machen wollen und einen Modellanbieter samt Schlüssel zur Hand haben. Weniger geeignet ist es als abgesichertes System für mehrere Nutzer, weil DEEPWIKI_AUTH_MODE nach Auskunft des README den direkten API-Zugriff offen lässt. Vor dem Einsatz prüfen: ob ein Schlüssel für GOOGLE_API_KEY oder OPENAI_API_KEY vorliegt, ob für private Repositories ein Zugriffstoken bereitsteht und ob das größte Repository im Projekt überhaupt im Rahmen bleibt.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository