LangWatch selbst hosten: OpenTelemetry-Tracing, Evaluatoren und ein Go-Gateway im Verbund

Welche Lücke LangWatch schließt

Die README beschreibt den Ausgangspunkt nüchtern: Teams sollen Agenten testen, simulieren, bewerten und überwachen können, ohne eigenes Werkzeug zu bauen. Das ist eine ziemlich genaue Beschreibung des Problems. Wer einen LLM-Agenten mit Werkzeugen, Zustand und mehreren Modellaufrufen betreibt, sammelt typischerweise drei getrennte Datensätze an: Traces aus der Produktion, kuratierte Testfälle und Prompt-Versionen in einem Repository. Diese drei zusammenzuführen ist Handarbeit, und genau diese Handarbeit will LangWatch ersetzen. Die README formuliert den Kreislauf als Trace, Datensatz, Evaluation, Prompt-Optimierung und erneuter Test.

Die Zielgruppe lässt sich aus den genannten Funktionen ableiten. Es sind Teams, die bereits Agenten in Produktion oder kurz davor haben und Regressionstests brauchen. Ein einzelner Entwickler, der einen Chatbot mit einem Prompt ausprobiert, bekommt hier mehr Oberfläche als nötig. Die Szenario-Simulationen richten sich laut README ausdrücklich auf den vollen Stack aus Werkzeugen, Zustand, Nutzersimulator und Judge, also auf Systeme, bei denen ein Fehler nicht im Prompt, sondern in der Abfolge der Entscheidungen liegt.

Wie die Teile zusammenspielen

Der Integrationsweg ist OpenTelemetry beziehungsweise OTLP. Die README nennt die Plattform ausdrücklich OTLP-nativ und framework- sowie anbieterunabhängig. Das ist architektonisch die wichtigste Aussage, weil sie bestimmt, was LangWatch im Kern ist: eine Senke für Spans plus die Auswertungsschicht darüber. Traces kommen über die Integration hinein, werden zu Datensätzen verdichtet, offline evaluiert und mit Prompt-Versionen verknüpft. Die Verknüpfung von Prompt-Versionen zu Traces ist in der README als eigenes Feature aufgeführt, was darauf hindeutet, dass die Zuordnung nicht automatisch aus dem Span allein entsteht.

Unter der Oberfläche liegen mehrere spezialisierte Dienste. Der lokale Installer richtet Postgres, Redis und ClickHouse ein. ClickHouse ist typisch für analytische Abfragen über große Span-Mengen, Postgres für die Anwendungsdaten, Redis für kurzlebige Zustände und Warteschlangen. Für die lokale Entwicklung nennt die README einen abweichenden Befehl, der nur Redis, Postgres und OpenSearch startet. Diese Abweichung ist ein Detail, das man kennen sollte: Der Entwicklungsweg und der Ein-Kommando-Weg nutzen unterschiedliche Such- beziehungsweise Analysespeicher.

Das AI-Gateway als separates Go-Binary

Ein Teil von LangWatch läuft nicht im TypeScript-Kern. Die README beschreibt das AI-Gateway als OpenAI- und Anthropic-kompatiblen Proxy mit virtuellen Schlüsseln, hierarchischen Budgets, Inline-Guardrails, automatischem Fallback zwischen Anbietern und Durchleitung von Anthropics cache_control. Ausgeliefert wird es als eigenes Go-Binary unter services/aigateway/ sowie als Helm-Sub-Chart unter charts/gateway/.

Für den Betrieb heißt das: Das Gateway ist ein zusätzlicher Prozess mit eigener Upgrade-Kadenz. Die README nennt eine Hot-Path-Latenz von etwa 700 ns. Diese Zahl stammt aus der Projektdokumentation und ist nicht unabhängig überprüft. Interessanter für die Entscheidung ist die Trennung selbst. Ein Gateway, das Budgets und Guardrails durchsetzt, sitzt zwischen Anwendung und Modellanbieter. Fällt es aus, fällt der Modellzugriff aus, unabhängig davon, ob die Evaluationsplattform noch läuft. Wer das Gateway einsetzt, betreibt damit einen weiteren kritischen Pfad.

Lokaler Start in zwei Varianten

Der schnellste Weg ist laut README ein einzelner Befehl:

npx @langwatch/server

Die CLI installiert uv, postgres, redis, clickhouse, das AI-Gateway-Binary und die Laufzeit des Langy-Assistenten nach ~/.langwatch/, erzeugt eine .env mit lokal generierten Secrets, startet alle Dienste parallel und öffnet http://localhost:5560. Alles liegt unter ~/.langwatch/, und rm -rf ~/.langwatch wird als sauberer Reset bezeichnet. Das ist ein ungewöhnlich ehrlicher Hinweis auf die Menge an Zustand, die außerhalb des Projektverzeichnisses landet.

Drei Schalter steuern optionale Komponenten in ~/.langwatch/.env. LANGWATCH_ENABLE_LANGY steht standardmäßig auf true und fügt rund 45 MB für die Laufzeit des Assistenten hinzu. Die README weist ausdrücklich darauf hin, dass dessen Worker unsandboxed mit den Rechten des ausführenden Nutzers laufen. LANGWATCH_ENABLE_PRESIDIO steht auf false und bringt rund 670 MB Sprachmodell mit, mehr als die übrige Evaluator-Umgebung zusammen. LANGWATCH_ENABLE_LINGUA steht ebenfalls auf false und kostet rund 95 MB. Wichtig: Die eigene Secret- und PII-Redaktion der Traces hängt laut README nicht von Presidio ab. Der Evaluator ist also eine zusätzliche Prüfung, keine Voraussetzung für Datenschutz im Tracing.

Wer Docker bevorzugt, klont das Repository, wechselt nach platform/app, kopiert platform/app/.env.example nach platform/app/.env und startet docker compose up -d --wait --build. Der Dienst ist danach ebenfalls unter http://localhost:5560 erreichbar.

Wo der Ansatz an Grenzen stößt

Der Ein-Kommando-Start installiert vier Daten- und Hilfsdienste plus ein Gateway-Binary plus optional Modellgewichte. Auf einem Entwicklungsrechner ist das bequem. Auf einer Maschine mit knappem Speicher oder ohne Netzwerkzugang während der Installation ist es eine Zumutung. Die Presidio-Variante allein bringt rund 670 MB Modell mit, und das ist ein Evaluator von mehreren.

Der zweite Punkt ist die Sandbox. Die README sagt offen, dass die Langy-Worker unsandboxed als der ausführende Nutzer laufen. Wer LangWatch auf einer Maschine mit Zugriff auf Produktionsdaten oder Cloud-Anmeldedaten startet, sollte LANGWATCH_ENABLE_LANGY auf false setzen, solange er den Assistenten nicht wirklich braucht. Das ist keine theoretische Sorge, sondern eine Konsequenz aus dem Standardwert true.

Drittens die Abfrage-Engines. Der Entwicklungsweg nutzt OpenSearch, der npx-Weg ClickHouse. Wer zwischen beiden wechselt, arbeitet gegen unterschiedliche Speicher. Das ist kein Fehler, aber es erschwert das Nachvollziehen von Abfrageverhalten zwischen Umgebungen. Wer Fehler in der Auswertung sucht, muss zuerst wissen, welche Engine gerade antwortet.

Was LangWatch von reinen Tracing-Backends unterscheidet

Man kann dieselben Spans auch in ein generisches OpenTelemetry-Backend schicken und dort auswerten. Der Unterschied liegt nicht in der Erfassung, sondern in der Schicht darüber. LangWatch liefert laut README Datensätze, Offline-Evaluation, Prompt-Verwaltung mit GitHub-Integration und Annotationswarteschlangen für Fachexperten mit. Ein generisches Tracing-Backend beantwortet die Frage, was passiert ist. Es beantwortet nicht, ob eine Änderung am Prompt die Qualität verschlechtert hat.

Der zweite Unterschied ist die Szenario-Simulation. Statt nur echte Traces zu bewerten, führt LangWatch Szenarien gegen den vollen Stack aus, inklusive Nutzersimulator und Judge. Das ist ein anderer Testbegriff: nicht Beobachtung, sondern kontrollierte Wiederholung. Für Teams, die bereits ein Tracing-Backend betreiben, ist die relevante Frage daher, ob sie die Evaluations- und Prompt-Schicht separat bauen wollen. Wenn ja, bleibt LangWatch überflüssig. Wenn nein, ist der OTLP-Einstieg der günstigste Weg, es auszuprobieren, weil die Instrumentierung dann nicht an LangWatch gebunden ist.

Lizenz, Wartung und Upgrade-Aufwand

Das Repository steht unter Apache-2.0. Das Lizenzschild in der README nennt zusätzlich eine Enterprise-Erweiterung, das Projekt ist also Open-Core. Wer die Plattform selbst hostet, sollte vor der Entscheidung klären, welche Funktionen im Apache-2.0-Teil liegen und welche der Enterprise-Teil abdeckt. Aus dem vorliegenden Material geht diese Aufteilung nicht hervor. Eine rechtliche Einschätzung ist hier nicht möglich und auch nicht beabsichtigt.

Die Wartungslast verteilt sich auf mehrere bewegliche Teile: das TypeScript-Kernsystem, das Go-Gateway, die SDKs und die Modelldateien der optionalen Evaluatoren. Die letzten Releases zeigen getrennte Versionslinien für sdks/go (v1.0.0), typescript-sdk (v1.13.0) und skills (v1.4.0). Solche getrennten Tags bedeuten, dass ein Upgrade nicht an einer einzigen Versionsnummer hängt. Wer das Gateway als Helm-Sub-Chart betreibt, muss dessen Chart-Version unabhängig vom Anwendungs-Chart verfolgen.

Der Reset-Pfad über rm -rf ~/.langwatch ist für lokale Installationen praktisch, aber er löscht auch die lokalen Datenbanken. Für Evaluationsläufe, die man später vergleichen will, ist das eine Falle. Wer reproduzierbare Ergebnisse braucht, sollte Datensätze vorher exportieren oder von Anfang an gegen eine persistente Postgres- und ClickHouse-Instanz arbeiten.

Redaktionelles Fazit

Für Teams, die Agenten vor dem Release gegen Szenarien testen und parallel Traces aus der Produktion auswerten wollen, ist LangWatch dann sinnvoll, wenn der Betrieb der Datenbanken ohnehin Teil der Infrastruktur ist. Wer nur ein schlankes Tracing-Backend sucht oder keine Postgres-, Redis- und ClickHouse-Instanzen betreiben will, sollte zuerst prüfen, ob ein reiner OTLP-Collector mit bestehender Speicherlösung den Bedarf deckt. Vor dem ersten Produktionslauf sind drei Dinge zu klären: ob das AI-Gateway als eigenes Go-Binary in eurer Umgebung mitläuft, ob der Presidio-Evaluator mit seinen rund 670 MB Modellgröße auf die Zielmaschine passt, und ob die Enterprise-Erweiterung Funktionen abdeckt, die ihr braucht, denn das Repository selbst steht unter Apache-2.0.

Offizielle Quellen

1. langwatch/langwatch on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases