FastGPT: RAG-Plattform mit visueller Workflow-Orchestrierung im Selbstbetrieb
FastGPT is a knowledge-based platform built on the LLMs, offers a comprehensive suite of out-of-the-box capabilities such as data processing, RAG retrieval, and visual AI workflow orchestration, letting you easily develop and deploy complex question-answering systems without the need for extensive setup or configuration.
Auf einen Blick
- Was ist das?
- FastGPT kombiniert Wissensdatenbank, Retrieval und einen Flow-Editor für Agenten in einer TypeScript-Anwendung. Der Docker-Start ist kurz, die Lizenz ist es nicht, und wer nur einen Chatbot über ein paar PDFs braucht, zahlt hier für viel Infrastruktur.
- Für wen ist es gedacht?
- FastGPT passt zu Teams, die Wissensdatenbank, Retrieval und Workflow-Editor in einer selbst betriebenen Instanz brauchen und den Betrieb mehrerer Dienste tragen können. Wer nur einen einzelnen Chatbot über wenige Dokumente will, sollte zu einem schlankeren RAG-Framework greifen.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem FastGPT löst und für wen
Die README beschreibt FastGPT als AI-Agent-Build-Plattform mit Datenverarbeitung und Modellaufrufen ab Werk, ergänzt durch einen Flow-Editor für visuelle Workflow-Orchestrierung. Der Adressat ist damit nicht das Einzelskript, sondern die Frage: Wer betreibt Wissensdatenbank, Retrieval, Prompt-Logik und Modellanbindung als zusammenhängende Anwendung, ohne jede Schicht selbst zu bauen? Die README listet dafür Dateiformate wie TXT, MD, HTML, PDF, Docx, PPTX, CSV und XLSX, URL-Import und CSV-Masseningest. Dazu kommen Hybrid-Retrieval mit Reranking, API-Wissensdatenbanken und Chunk-Bearbeitung. Wer eine dieser Funktionen einzeln braucht, findet sie auch in spezialisierten Bibliotheken. Der Unterschied liegt in der Bündelung: Ein Team bekommt eine Oberfläche, in der Dokumente, Abruf, Workflow und Auswertung zusammenlaufen, statt vier Dienste zu verdrahten. Die README nennt außerdem Betriebsfunktionen wie einen login-freien Freigabe-Link, iframe-Einbettung und eine zentrale Ansicht der Gesprächsprotokolle mit Annotation. Das zielt auf interne Assistenten und kundenseitige Auskunftssysteme, nicht auf Forschungsexperimente.
Der Aufbau: Next.js-Oberfläche, Flow-Editor, Wissensspeicher
Das Repository ist primär in TypeScript geschrieben, was zusammen mit dem Topic nextjs auf eine Webanwendung mit Server- und Clientanteil deutet. Die README beschreibt zwei Workflow-Typen: Dialog-Workflows und Plugin-Workflows, wobei letztere einen RPA-Grundknoten enthalten. Ein Workflow ist demnach ein gerichteter Graph aus Knoten, den der Flow-Editor visuell aufgebaut wird. Der zweite Strang ist die Wissensdatenbank: Dokumente werden geladen, in Chunks zerlegt und über Hybrid-Retrieval mit anschließendem Reranking abgerufen. Beide Stränge treffen sich im Dialog, wo laut README Zitate während der Konversation bearbeitet oder gelöscht werden können. Für die Anbindung an externe Systeme nennt die README bidirektionales MCP sowie eine OpenAPI-Dokumentation für die System-API. Die Modellanbindung läuft nicht zwingend direkt: Unter den verlinkten Projekten steht AI Proxy als Modell-Aggregations- und Lastverteilungsdienst. Das ist ein Hinweis auf die typische Produktionsform, in der mehrere Modellanbieter hinter einer Schnittstelle liegen. Was die README nicht liefert, ist ein Schichtdiagramm oder eine Beschreibung der Datenhaltung. Wer wissen muss, wo Vektoren und Chunks physisch liegen, findet das in diesem Material nicht.
Inbetriebnahme per Docker Compose
Der dokumentierte Weg ist kurz. Zuerst wird das Installationsskript geladen, das die Konfiguration abfragt: bash <(curl -fsSL https://doc.fastgpt.io/deploy/install.sh). Danach startet der Stack mit docker compose up -d. Nach vollständigem Start ist die Instanz unter http://localhost:3000 erreichbar, der dokumentierte Standardzugang lautet root mit dem Passwort 1234. Dieses Standardpasswort ist der erste Punkt, der vor jeder Exposition nach außen geändert werden muss. Die README verweist für Details auf die vollständige Docker-Anleitung und für die lokale Entwicklung auf eine eigene Seite. Beide Wege stehen im Repository nur als Links, die konkreten Umgebungsvariablen und Compose-Dateien liegen in der verlinkten Dokumentation. Für einen schnellen Test auf dem eigenen Rechner reichen die zwei Befehle. Für einen dauerhaften Betrieb ist die Frage offen, welche Dienste der generierte Stack umfasst, welche Ports er belegt und wie die Daten gesichert werden. Das Installationsskript erzeugt die Konfiguration interaktiv, was bedeutet, dass die resultierende Datei versionsabhängig ist und bei Upgrades geprüft werden sollte.
Was die Funktionsliste offen lässt
Die README markiert den Reifegrad der Funktionen mit Kontrollkästchen, und die offenen Punkte sind aussagekräftiger als die geschlossenen. Nicht vorhanden sind laut Liste: unterstützte Workflow-Generierung, ein erweiterter Debug-Modus für die Orchestrierung, Protokolle auf Knotenebene, Hot-Reload für das RAG-Modul, Hot-Reload für Agent-Loop sowie die Echtzeit-Generierung von Plugins. Ein Knoten-Log fehlt, obwohl vollständige Aufrufketten-Logs als vorhanden markiert sind. In der Praxis heißt das: Man sieht den gesamten Request, aber nicht ohne Weiteres, welcher Knoten im Graphen welchen Zwischenzustand erzeugt hat. Bei mehrstufigen Workflows mit Verzweigungen ist das der mühsame Teil der Fehlersuche. Ebenso relevant ist der fehlende Hot-Reload für das RAG-Modul. Änderungen an der Retrieval-Logik erfordern demnach einen Neustart, während Systemtools laut Liste hot-update-fähig sind. Die Liste ist eine Selbsteinschätzung des Projekts und kein geprüftes Qualitätsmaß. Als Planungsgrundlage taugt sie trotzdem, weil sie zeigt, welche Erweiterungen man selbst bauen müsste.
Lizenz: NOASSERTION ist keine Antwort
Die Lizenzkennung des Repositories lautet NOASSERTION. Das ist keine Lizenz, sondern die Aussage, dass die automatische Erkennung keine eindeutige Standardlizenz identifizieren konnte. Wer FastGPT produktiv einsetzen will, muss die Datei LICENSE im Repository selbst lesen, weil davon abhängt, ob kommerzielle Nutzung, Weitergabe oder das Betreiben als Dienst erlaubt sind. Die README verstärkt diese Unsicherheit, indem sie drei Betriebsformen nebeneinander stellt: eine gehostete Cloud-Version, die selbst gehostete Community-Version und eine kommerzielle Edition mit zusätzlichen Funktionen und Unterstützung bei der Umsetzung. Wenn ein Projekt Funktionsumfang und Support über einen kommerziellen Vertrag verkauft, ist die Grenze zwischen Community- und Kommerzversion der erste Punkt, den man klären sollte. Dass das Repository aktiv gepflegt wird, zeigt der Stand: Der letzte Push liegt laut Repository-Metadaten im September 2026, die letzten drei Releases v4.16.0, v4.16.1 und v4.16.2 stammen aus dem August und September 2026. Diese Taktung bedeutet, dass ein Selbstbetreiber regelmäßig aktualisieren muss. Ob ein Upgrade zwischen Minor-Versionen Migrationen an der Datenbank erfordert, geht aus diesem Material nicht hervor. Das gehört vor dem Produktivstart geklärt, nicht danach.
Wann FastGPT das falsche Werkzeug ist
Der Docker-Start verdeckt, wie viele bewegliche Teile der Stack enthält. Ein Installationsskript, das eine Compose-Konfiguration interaktiv erzeugt, deutet auf mehrere Dienste hin: Webanwendung, Datenhaltung, vermutlich ein Vektor- oder Suchindex. Wer nur einen Chat über eine Handvoll interner Dokumente braucht, bezahlt diese Komplexität ohne Gegenwert. In diesem Fall sind Bibliotheken wie LlamaIndex oder LangChain in einem eigenen Skript die günstigere Wahl: Man schreibt die Ingestion selbst, hat aber keine Dienste zu betreiben und keine Oberfläche zu aktualisieren. Der zweite Fall betrifft Teams mit einer festen, kleinen Anzahl von Dokumenten, die sich selten ändern. Hier ist der Aufwand für Chunk-Verwaltung, Reranking-Konfiguration und Workflow-Graph höher als der Nutzen. Drittens: Wer eine tiefe, codegesteuerte Kontrolle über jede Stufe der Retrieval-Pipeline braucht, arbeitet gegen die Abstraktion des Flow-Editors statt mit ihr. Der Editor ist auf visuelle Komposition ausgelegt, nicht auf programmatische Eingriffe in jeden Zwischenschritt. Und wer ohne Container-Erfahrung eine Instanz im Internet freigibt, sollte den Standardzugang root mit 1234 zuerst ändern.
Alternative mit anderem Ansatz
Dify verfolgt einen verwandten Zweck, aber einen anderen Schwerpunkt: Es ist ebenfalls eine Plattform für LLM-Anwendungen mit visueller Orchestrierung und Wissensdatenbank, legt den Akzent jedoch stärker auf eine breite Auswahl vorgefertigter Anwendungstypen und eine zentrale Modellverwaltung über viele Anbieter. FastGPT betont dagegen laut README die Wissensdatenbank-Seite mit Hybrid-Retrieval, Reranking, API-Wissensdatenbanken und Chunk-Bearbeitung sowie bidirektionales MCP für die Werkzeuganbindung. Der praktische Unterschied liegt damit in der Frage, ob der Kern ein präziser Abruf über eigene Dokumente ist oder ein schneller Bau verschiedener Anwendungstypen. Wer eine bestehende eigene Oberfläche hat und nur die Retrieval-Schicht sucht, ist mit einem Framework wie LlamaIndex besser bedient: Dort gibt es keine Plattform, keine Benutzerverwaltung und keinen Workflow-Editor, dafür volle Kontrolle über jeden Schritt der Pipeline. Der Preis ist, dass Ingestion, Indexpflege und Auswertung selbst gebaut werden müssen. FastGPT liefert diese Teile mit, bindet die Logik aber an seine Oberfläche.
Betriebsaufwand und was vor dem Rollout zu prüfen ist
Die Release-Historie zeigt eine schnelle Taktung: v4.16.0 im August 2026, v4.16.1 zwei Wochen später, v4.16.2 Anfang September 2026. Ein Selbstbetreiber muss entscheiden, ob er jedem Minor-Release folgt oder auf Sicherheits- und Fehlerkorrekturen wartet. Die README nennt keine Upgrade-Anleitung und keine Angaben zu Datenbankmigrationen, das steht in der verlinkten Dokumentation. Der zweite Kostenpunkt ist die Modellanbindung. FastGPT bringt keinen Modellzugang mit, die Inferenz läuft über eigene Endpunkte. Das verlinkte AI Proxy ist ein separater Dienst für Aggregation und Lastverteilung, also eine zusätzliche Komponente, die betrieben und überwacht werden will. Wer diesen Dienst nicht einsetzt, muss die Modellkonfiguration direkt in FastGPT hinterlegen. Drittens die Lizenz: Die Kennung NOASSERTION bedeutet, dass vor jedem produktiven Einsatz die Datei LICENSE zu lesen ist. Ohne diese Prüfung ist unklar, ob die selbst gehostete Community-Version für den vorgesehenen Zweck verwendet werden darf. Wer diese drei Punkte geklärt hat, kann mit bash <(curl -fsSL https://doc.fastgpt.io/deploy/install.sh) und docker compose up -d starten und den Zugang unter http://localhost:3000 sofort absichern.
Redaktionelles Fazit
FastGPT passt zu Teams, die Wissensdatenbank, Retrieval und Workflow-Editor in einer selbst betriebenen Instanz brauchen und den Betrieb mehrerer Dienste tragen können. Wer nur einen einzelnen Chatbot über wenige Dokumente will, sollte zu einem schlankeren RAG-Framework greifen. Vor dem Rollout ist die Datei LICENSE zu prüfen, weil die Kennung NOASSERTION keine Aussage über Nutzungsrechte erlaubt, und danach die eigenen Modell-Endpunkte in der Compose-Konfiguration zu hinterlegen.
Community-Notizen