huggingface/chat-ui: eine SvelteKit-Oberfläche für OpenAI-kompatible Endpunkte
The open source codebase powering HuggingChat
Auf einen Blick
- Was ist das?
- Chat UI ist die Codebasis hinter HuggingChat und lässt sich gegen jeden Dienst betreiben, der das OpenAI-Protokoll spricht. Wer eine eigene Chat-Oberfläche mit MongoDB-Historie sucht, findet hier eine schlanke Basis, muss aber mit einem harten Bruch zur Vorgängerversion leben.
- Für wen ist es gedacht?
- Wer eine eigene Chat-Oberfläche gegen llama.cpp, Ollama, OpenRouter oder den Hugging-Face-Router braucht und MongoDB ohnehin betreibt, bekommt hier eine schlanke SvelteKit-Basis unter Apache-2.0. Wer eine Provider-Abstraktion mit GGUF-Erkennung oder eingebauten Web-Search-Helfern erwartet, sollte den legacy-Branch prüfen oder eine andere Codebasis wählen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- 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
Welche Lücke Chat UI schließt und für wen
Eine Chat-Oberfläche für ein Sprachmodell ist schnell zusammengeklickt, bis Persistenz, Nutzerkonten, Dateianhänge und Modellauswahl dazukommen. Genau diese Teile liefert Chat UI fertig: laut README sind Chatverlauf, Nutzer, Einstellungen, Dateien und Statistiken in MongoDB abgelegt. Die Anwendung ist eine SvelteKit-App und betreibt die öffentliche Instanz unter huggingface.co/chat. Wer eine interne Chat-Oberfläche für ein selbst gehostetes Modell aufsetzen will, muss also nicht bei der Nachrichtenliste anfangen. Die Zielgruppe ist enger, als der Name vermuten lässt. Angesprochen sind Teams, die bereits einen OpenAI-kompatiblen Endpunkt betreiben und eine Weboberfläche mit Datenbankanbindung darüberlegen wollen. Ein Modellserver allein genügt nicht, weil die Anwendung keine Gewichte lädt und keine Inferenz ausführt. Sie ist ein Client mit eigener Persistenzschicht, kein Modellhost.
Nur OpenAI-Protokoll, alles andere ist entfernt
Die README enthält eine Warnung, die man vor der Evaluierung lesen sollte: Chat UI unterstützt ausschließlich OpenAI-kompatible APIs über `OPENAI_BASE_URL` und den `/models`-Endpunkt. Provider-spezifische Integrationen, namentlich die alte `MODELS`-Umgebungsvariable, GGUF-Erkennung, Embeddings und Web-Search-Helfer, sind entfernt. Das ist ein bewusster Schnitt und kein Versehen. Die Konsequenz: Jeder Dienst, der das OpenAI-Protokoll spricht, funktioniert ohne Anpassung. Die README nennt llama.cpp server, Ollama über eine OpenAI-kompatible Brücke, OpenRouter und Poe als Beispiele. Umgekehrt gilt: Wer eine native Anbindung an einen Anbieter mit eigenem Protokoll braucht, findet sie in diesem Branch nicht mehr. Die alte Version liegt auf dem legacy-Branch. Das ist die zentrale Designentscheidung des Projekts und gleichzeitig die größte Einschränkung für Bestandsnutzer, die von einer älteren Version aktualisieren wollen. Wer die entfernten Funktionen benötigt, muss entweder auf dem legacy-Branch bleiben oder sie selbst nachbauen.
Start in zwei Umgebungsvariablen
Der Schnellstart ist knapp dokumentiert. Zuerst eine `.env.local` anlegen, in der `OPENAI_BASE_URL` und `OPENAI_API_KEY` gesetzt werden. Die README zeigt für den Hugging-Face-Inference-Providers-Router die Werte `https://router.huggingface.co/v1` und einen Schlüssel der Form `hf_***`. Für einen lokalen llama.cpp-Server nennt die Tabelle `http://127.0.0.1:8080/v1` und weist darauf hin, dass der Schlüssel beliebig sein kann, weil llama.cpp ihn ignoriert. Danach folgen die üblichen Befehle: `git clone`, `cd chat-ui`, `npm install`, `npm run dev -- --open`. Der Entwicklungsserver lauscht laut README standardmäßig auf `http://localhost:5173`. Für Produktionsbuilds sind `npm run build` und `npm run preview` vorgesehen. Wer MongoDB nicht selbst betreiben will, kann das Image `ghcr.io/huggingface/chat-ui-db:latest` verwenden, das MongoDB im Container mitbringt und über `-v chat-ui-data:/data` persistiert. Alle Variablen aus `.env.local` lassen sich dort als `-e`-Flags übergeben. Der vollständige Satz optionaler Variablen steht laut README in der Vorlage `.env` im Wurzelverzeichnis.
MongoDB als einzige Zustandsschicht
Die Datenbankentscheidung ist nicht optional, aber sie hat eine Hintertür für die Entwicklung. Wenn `MONGODB_URL` nicht gesetzt ist, fällt Chat UI laut README auf eine eingebettete MongoDB zurück, die nach `./db` schreibt. Für lokales Ausprobieren ist das bequem. Für alles andere ist es eine Falle: Der Standardwert `MONGODB_DB_NAME=chat-ui` bleibt bestehen, solange man ihn nicht pro Umgebung überschreibt, und eine eingebettete Datenbank im Projektverzeichnis überlebt kein Container-Deployment. Die README beschreibt zwei Wege für einen echten Betrieb. Managed über MongoDB Atlas, wo man Cluster, IP-Zugriffsliste und Datenbanknutzer anlegt und die Verbindungszeichenfolge in `MONGODB_URL` einträgt. Oder lokal per Container mit `docker run -d -p 27017:27017 --name mongo-chatui mongo:latest` und anschließend `MONGODB_URL=mongodb://localhost:27017`. Die README spricht von MongoDB 6 und 7 als unterstützten Versionen. Wer bereits eine MongoDB betreibt, hat damit keinen zusätzlichen Dienst im Stack. Wer keine betreibt, bekommt hier eine zweite Zustandsmaschine neben dem Modellserver, inklusive Backup- und Upgrade-Pflicht.
Der optionale LLM-Router und seine Konfigurationslücken
Interessant ist der serverseitige Router, weil er ohne separates Routing-Modell auskommt. Laut README arbeitet er mit einer lokalen Heuristik und ruft keinen Auswahlmodell-Dienst auf. In der Oberfläche erscheint ein virtueller Modellalias, standardmäßig Omni, der pro Nachricht eine Route wählt: Bildanhänge gehen an eine `multimodal`-Route, Anfragen mit aktiviertem MCP-Werkzeug an eine `agentic`-Route, alles andere an `default`. Die Routen kommen aus einer JSON-Datei, auf die `LLM_ROUTER_ROUTES_PATH` zeigt. Hier wird die Dokumentation dünn, und das sollte man vor dem Einbau wissen: Die README stellt ausdrücklich fest, dass in diesem Branch keine Beispieldatei mitgeliefert wird. Man muss die JSON selbst schreiben, etwa als `config/routes.chat.json` im eigenen Projekt, mit `name`, `description`, `primary_model` und optional `fallback_models` pro Eintrag. Erkannt werden nur die Routennamen `default`, `multimodal` und `agentic`. Der Standardroutennamen lässt sich über `LLM_ROUTER_DEFAULT_ROUTE` ändern. Scheitern alle Modelle einer Route, greift `LLM_ROUTER_FALLBACK_MODEL`. Die Aliasdarstellung steuern `PUBLIC_LLM_ROUTER_ALIAS_ID`, `PUBLIC_LLM_ROUTER_DISPLAY_NAME` und optional `PUBLIC_LLM_ROUTER_LOGO_URL`. Wer diese Funktion nicht braucht, ignoriert sie einfach, denn sie ist ausdrücklich optional.
Theming über vier Variablen und der Datenfreigabe-Schalter
Die Anpassung an die eigene Marke ist auf wenige Variablen beschränkt. `PUBLIC_APP_NAME` setzt den Titel in der gesamten Anwendung, Vorgabe `ChatUI`. `PUBLIC_APP_ASSETS` bestimmt, wo Logos und Favicons gesucht werden, nämlich unter `static/$PUBLIC_APP_ASSETS`, wobei die README aktuell `chatui` und `huggingchat` als Optionen nennt. `PUBLIC_APP_DESCRIPTION` füllt die Beschreibung. Interessant für Betreiber mit Modellanbietern ist `PUBLIC_APP_DATA_SHARING`: Auf 1 gesetzt, erscheint in den Nutzereinstellungen ein Schalter, mit dem Nutzer der Datenfreigabe an den Modellersteller zustimmen können. Wer diesen Schalter sichtbar macht, übernimmt damit auch die Verantwortung für das, was hinter der Zustimmung passiert. Die README beschreibt nur die Existenz des Schalters, nicht die Weiterverarbeitung der Daten. Für den Datenschutzteil einer Deployment-Entscheidung reicht dieses Material nicht aus, und das sollte man offen sagen. Wer den Schalter nicht setzt, hat ihn schlicht nicht in der Oberfläche.
Wann Chat UI das falsche Werkzeug ist
Der klarste Fall gegen Chat UI ist ein Team, das eine Anbindung an einen Anbieter mit eigenem, nicht OpenAI-kompatiblem Protokoll braucht. Die README macht deutlich, dass solche Integrationen entfernt wurden. Ein weiterer Fall sind Installationen, die keine MongoDB betreiben wollen oder dürfen. Die eingebettete Datenbank ist laut README ausdrücklich für die lokale Entwicklung gedacht, nicht als Produktionspfad. Drittens: Wer GGUF-Modelle automatisch erkennen lassen will, findet diese Funktion nicht mehr. Viertens sollte man die Dokumentationslage beim Router ernst nehmen. Dass keine Beispieldatei für die Routen mitgeliefert wird, bedeutet, dass man das Format aus der Beschreibung rekonstruieren muss, bevor die Omni-Route überhaupt etwas tut. Ein falsch aufgebautes JSON führt nicht zu einem hilfreichen Fehlerbild, sondern zu einer Route, die ihre Modelle nicht findet. Wer diese Konfiguration nicht selbst pflegen will, sollte den Router deaktiviert lassen und Modelle direkt auswählen.
Alternative: eine generische OpenAI-Client-Oberfläche
Die naheliegende Alternative ist eine Oberfläche, die selbst nur ein OpenAI-kompatibler Client ist und die Zustandsverwaltung dem Betreiber überlässt, etwa ein Frontend, das direkt gegen `OPENAI_BASE_URL` spricht und den Verlauf im Browser hält. Der Unterschied liegt nicht in der Modellunterstützung, denn beide Wege sprechen dasselbe Protokoll. Er liegt in der Zustandsschicht. Chat UI bringt MongoDB-Schemata für Nutzer, Sitzungen, Einstellungen, Dateien und Statistiken mit und verlangt dafür einen Datenbankbetrieb. Eine reine Browserlösung hat diesen Betrieb nicht, verliert aber den Verlauf beim Gerätewechsel und kennt keine serverseitigen Nutzerkonten. Für eine Einzelperson mit lokalem llama.cpp-Server ist der Unterschied gering. Für eine Gruppe, die denselben Verlauf auf mehreren Geräten sehen soll, ist die Datenbank der Punkt, an dem Chat UI seinen Aufwand rechtfertigt. Umgekehrt ist genau diese Datenbank der Grund, warum man Chat UI nicht mal eben in eine bestehende statische Website einhängt.
Wartung, Versionen und Lizenz
Die Release-Historie zeigt einen unregelmäßigen Takt: v0.9.5 im Juni 2025, v0.9.6 im Januar 2026, v0.10.0 im Mai 2026. Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten im September 2026. Wer auf v0.9.x aufsetzt, sollte den Sprung auf v0.10.0 prüfen, weil die Entfernung der Provider-Integrationen und der `MODELS`-Umgebungsvariablen ein Bruch ist, der sich nicht durch Konfiguration auffangen lässt. Für Bestandsinstallationen bedeutet das entweder ein Fork der entfernten Integrationen oder der Verbleib auf dem legacy-Branch. Die Lizenz ist Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die üblichen Pflichten: Beibehaltung der Lizenz- und Urheberrechtshinweise und Kennzeichnung geänderter Dateien. Wer die Anwendung als gehosteten Dienst anbietet, sollte die Trademark-Frage unabhängig davon prüfen, denn die Apache-2.0-Lizenz gewährt keine Markenrechte, und die Standardwerte `PUBLIC_APP_NAME=ChatUI` sowie `PUBLIC_APP_ASSETS=chatui` verweisen auf die Hugging-Face-Instanz. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stellen, an denen man vor einem öffentlichen Deploy genauer hinsehen sollte.
Redaktionelles Fazit
Wer eine eigene Chat-Oberfläche gegen llama.cpp, Ollama, OpenRouter oder den Hugging-Face-Router braucht und MongoDB ohnehin betreibt, bekommt hier eine schlanke SvelteKit-Basis unter Apache-2.0. Wer eine Provider-Abstraktion mit GGUF-Erkennung oder eingebauten Web-Search-Helfern erwartet, sollte den legacy-Branch prüfen oder eine andere Codebasis wählen. Vor dem ersten Deploy: `MONGODB_URL` und `MONGODB_DB_NAME` bewusst setzen, sonst schreibt die Anwendung in eine eingebettete Datenbank unter `./db`, und die Modellliste gegen `${OPENAI_BASE_URL}/models` verifizieren.
Community-Notizen