Startseite / Artikel / Selbst gehosteter LangGraph-Agent-Server mit Postgres und Redis

LangGraph Postgres Redis Self-Hosting LLM Agents

Selbst gehosteter LangGraph-Agent-Server mit Postgres und Redis

Erfahren Sie, wie Langhost die Persistenzschicht von LangGraph durch Postgres und Redis ersetzt und Teams ermöglicht, den unveränderten Agent Server unter einer MIT-Lizenz selbst zu hosten.

1503 Wörter

Behalten Sie das LangGraph SDK, Studio und Agent Server genau so bei, wie sie sind. Bewahren Sie den dauerhaften Zustand in Postgres auf und übertragen Sie die Koordinationsaufgaben an Redis – und das alles ohne Notwendigkeit einer Laufzeit-Lizenzschlüssel.

Das Schreiben eines LangGraph-Agenten ist in der Regel der einfachste Teil.

Man führt das Graph-Modell lokal aus, die Tools arbeiten, und der Zustand fließt von Knoten zu Knoten. Dann stellt sich jemand die Frage, die aus einem Prototypen eine echte Betriebsaufgabe macht: Wie lässt sich das tatsächlich für Produktivverkehr einert

Ein Agent-Server muss weitaus mehr verfolgen als eine einfache Request-Response-API. Gespräche erfordern dauerhafte Threads, die über Sessions hinweg bestehen bleiben. Einige Ausführungen pausieren, während sie auf die Genehmigung eines Menschen für einen Schritt warten, und setzen diese viel später fort. Clients erwarten einen Strom von Ereignissen statt einer einzigen Antwort. Geplante Aufgaben müssen genau einmal ausgelöst werden, selbst wenn mehrere Worker darum konkurrieren, sie zu bearbeiten. Und falls ein Worker während der Ausführung abstürzt, muss ein anderer Worker sauber übernehmen, ohne den Zustand zu beschädigen.

langgraph dev eignet sich für die lokale Entwicklung, und LangChains eigene Dokumentation bezeichnet es als Entwicklungsserver und nicht als Produktivserver. Er speichert den Zustand im Speicher sowie in einer lokalen Dateiordnung. Der zugelassene Weg für die Produktivumgebung sind LangSmith Deployments, die entweder als verwalteter Service oder unter einer Self-Hosting-Lizenz verfügbar sind.

Langhost schlägt einen anderen Ansatz vor. Es läuft den unveränderten LangGraph Agent Server auf Postgres und Redis, wobei ein unter der MIT-Lizenz veröffentlichter Persistenz-Runtime verwendet wird.

Auf den ersten Blick scheint das ein kleiner Austausch zu sein. Tatsächlich ist es einer – und genau das macht es bemerkenswert.

Die Gestaltungsentscheidung, die Langhost interessant macht

Anstatt das Agent Protocol neu zu implementieren oder Anwendungen auf eine andere API zu zwingen, lässt Langhost das offizielle Agent Server-Paket langgraph-api unverändert. Was sich ändert, ist die darunterliegende Schicht: Das langgraph-runtime-pg-Paket übernimmt die Persistenzfunktionen.

So passen die Komponenten in etwa zueinander:

LangSmith Studio, SDK clients, Chat UI, MCP, A2A
                         |
                   langhost serve
                         |
              stock langgraph-api
                         |
              langgraph-runtime-pg
                    /          \
              Postgres        Redis

Bestehende Anwendungen behalten ihre Graph-Definitionen sowie die Datei langgraph.json unverändert bei. Die Clients kommunizieren weiterhin mit langgraph-sdk. Das Studio verbindet sich weiterhin über dieselbe Agent-Server-API, die es stets verwendet hat. Langhost vermeidet absichtlich jegliche anspruchsvollen Aktionen an dieser Schnittstelle – was genau der richtige Ansatz für Infrastruktur ist.

Weil das offizielle Serverpaket beibehalten wird, bleibt auch sein vollständiges Funktionsumfang bei dem Wechsel erhalten: Verwaltung von Assistenten, Überwachung von Threads und einzelnen Ausführungen, Bereitstellung des Schlüssel-Wert-Speichers, Auslösung von geplanten Aufgaben, Übertragung von gestreamtem Output, Aufruf von Webhooks sowie Unterstützung sowohl von MCP als auch von A2A. Eine konkurrierende Serverimplementierung müsste ständig alle Protokolländerungen verfolgen, um all das weiterhin funktionieren zu lassen. Langhost umgeht diese Wartungslast vollständig, indem es das Protokollverhalten dem upstream-Server überlässt und sich ausschließlich auf Speicherung und Koordination konzentriert.

Was Postgres und Redis jeweils leisten

Postgres speichert alles, was für einen Neustart erforderlich ist: Assistentenkonfigurationen, Thread-Verläufe, Ausführungsprotokolle, Definitionen von geplanten Aufgaben, Checkpoints sowie alle in der Datenbank gespeicherten Anwendungsdaten. Schema-Migrationen werden über Alembic durchgeführt. Für Produktivumgebungen empfiehlt das Projekt, die Migrationen vor dem Rollout durchzuführen und die automatische Migration beim Server-Start auszuschalten.

Redis wird für kurzfristige Koordinierungsaufgaben verwendet. Er informiert die Worker, wenn eine neue Aufgabe in der Warteschlange ankommt, strahlt Stream-Ereignisse an alle verbundenen Server-Prozesse aus und überwacht die Aktivität der Worker.

Diese Trennung wird wichtig, sobald man auf mehrere Replikas ausweitet. Wenn ein Worker eine ausstehende Ausführung übernehmen möchte, beansprucht er die Zeile in Postgres mithilfe von SKIP LOCKED, wodurch verhindert wird, dass ein anderer Worker dieselbe Ausführung gleichzeitig erfasst. Redis-Heartbeat-Nachrichten bestätigen, dass der Worker noch aktiv ist; falls ein Heartbeat ausfällt, kann die Warteschlange diese Ausführung an jemand anderen zuweisen. Das Testumfeld des Projekts umfasst Tests zur Exklusivität der Beantragung, zum Wiederherstellen nach Ausfällen eines Workers, zu parallelen Threads, zum Streaming-Verhalten, zur Stornierung sowie zu Zustandsaktualisierungen, die während einer noch laufenden Ausführung stattfinden.

Genau dieses Thema wird in vielen „Wie deployt man seinen Agenten“-Leitfäden übergangen. Ein ASGI-Server zu starten ist trivial – das eigentliche ingenieurtechnische Problem besteht darin, sicherzustellen, dass die Warteschlangenverwaltung und das Fehlerrückgewinnungsverfahren unter konkurrierender Last korrekt funktionieren.

Übertragung eines bestehenden Projekts

Falls Sie bereits ein Python LangGraph-Projekt mit einer langgraph.json-Datei haben, erfordert die Nutzung von Langhost nur wenige Schritte.

Installieren Sie es:

uv add langhost

Dann weisen Sie es auf Ihre Postgres- und Redis-Instanzen hin:

DATABASE_URI=postgresql+asyncpg://postgres:postgres@localhost:5432/langgraph?sslmode=disable
REDIS_URI=redis://localhost:6379/0

Und starten Sie den Server:

uv run langhost serve --reload

Für einen Produktivbetrieb sollten Sie den Server explizit an die Netzwerkschnittstelle binden und eine feste Anzahl an Arbeitern festlegen:

uv run langhost serve --host 0.0.0.0 --workers 4

Standardmäßig lauscht der Server auf Port 31296. Beim Start werden Links zur API selbst, zu deren Dokumentation, zum LangSmith Studio sowie zur Agent Chat UI angezeigt. Ihr vorhandener Client-Code funktioniert unverändert weiter und verwendet weiterhin das Standard-SDK:

import asyncio
from langgraph_sdk import get_client

client = get_client(url="http://127.0.0.1:31296")async def main():
    async for chunk in client.runs.stream(
        None,
        "agent",
        input={
            "messages": [
                {"role": "human", "content": "What is LangGraph?"}
            ]
        },
    ):
        print(chunk.event, chunk.data)asyncio.run(main())

Dieser einfache Migrationsweg ist wohl der stärkste Verkaufsargument von Langhost. Ein Team kann es ausprobieren, ohne den Anwendungscode anzufassen oder vorher irgendwelche Client-Bibliotheken auszutauschen.

Die Lizenzbedingungen müssen sorgfältig gelesen werden

Die langhost CLI sowie langgraph-runtime-pg werden unter der MIT-Lizenz bereitgestellt. Das Standardpaket langgraph-api fällt hingegen weiterhin unter die Elastic License 2.0. Was Langhost tatsächlich tut, ist, die proprietären Postgres- und Redis-Runtime-Schichten durch eigene zu ersetzen. Dies hat keinen Einfluss auf die Lizenzbedingungen des offiziellen Serverpakets selbst.

Diese Nuance geht oft verloren, wenn Menschen den gesamten Stack als „Open Source“ bezeichnen. Die Persistenzschicht, die man über Langhost ausführt und modifizieren kann, ist tatsächlich unter der MIT-Lizenz lizenziert. Doch der darauf aufbauende Serverkomponent bleibt unter der Elastic 2.0 lizenziert und bindet den Nutzer weiterhin an diese Bedingungen.

Trotzdem ist der praktische Wandel für viele Organisationen von Bedeutung. Sie erhalten die Möglichkeit, zuverlässige LangGraph-Arbeitlasten auf selbst verwalteten Datenbanken auszuführen, ohne eine Laufzeit-Lizenzschlüssel benötigen zu müssen. Zudem kann der Zustand der Anwendung vollständig in ihrem eigenen Cloud-Konto oder im internen Netzwerk verbleiben. Wer dies für den Unternehmenseinsatz in Betracht zieht, sollte jedoch rechtliche oder Einkaufsteams beauftragen, beide Lizenzen direkt durchzulesen, anstatt sich auf eine Marketing-Zusammenfassung zu verlassen.

Was man durch Selbsthosting auf sich nimmt

Langhost beseitigt Lizenz- und Laufzeitbeschränkungen. Es beseitigt jedoch nicht die betrieblichen Herausforderungen.

Sie sind für die Kapazitätsplanung von Postgres, Backups, Wiederherstellungsszenarien, Limits für Verbindungs-Pools sowie Schemamigrationen verantwortlich. Zudem tragen Sie die Verantwortung für die Verfügbarkeit von Redis sowie die Richtlinien zur Freigabe von Speicher. Darüber hinaus benötigen Sie Transparenz – Metriken und Protokolle, die zeigen, ob der Job-Queue Backups durchführt, ob Worker blockiert sind oder ob Datenströme stillschweigend verloren gehen. Und bevor Sie die API außerhalb eines vertrauenswürdigen Netzwerks zugänglich machen, müssen Sie sie ordnungsgemäß sichern.

Bedenken Sie, dass dieses Projekt sich noch in einer frühen Entwicklungsphase befindet. Die aktuelle Veröffentlichung auf PyPI ist 0.11.1.post1 und trägt den Beta-Status. Sie festlegt eine bestimmte Version von langgraph-api, wodurch die Kompatibilität für diese spezielle Version gewährleistet bleibt, bedeutet aber auch, dass das Projekt ständig die Änderungen im Quellcode verfolgen muss, um auf dem neuesten Stand zu bleiben. Das Testframework des Repositoriums führt sowohl eigene Tests als auch die Integrationstests des Python SDK gegen einen aktiven Agent Server durch, was beruhigend ist – es ersetzt jedoch nicht die Überprüfung Ihrer eigenen Graphen, Verkehrsmuster, Fehlerfälle sowie Upgrade-Prozeduren.

Für Teams, die lieber nicht selbst mit all dem arbeiten möchten, bleibt eine verwaltete LangSmith-Deployment-Lösung der sinnvollere Weg. Langhost eignet sich besser für Teams, die bereits Erfahrung im Betrieb von Postgres und Redis haben, eine explizite Kontrolle darüber benötigen, wo ihr Zustand physisch gespeichert ist, oder einfach keinen lizenzierten selbst gehosteten Laufzeitumgebung nutzen können.

Eine praktische Methode zur Bewertung

Anstatt mit einer Liste von Funktionen zu beginnen, nehmen Sie eine Testkopie einer bereits laufenden LangGraph-Anwendung und richten Sie diese stattdessen auf Langhost aus.

Verwenden Sie weiterhin denselben langgraph.json, denselben SDK-Client sowie denselben Studio-Arbeitsablauf, auf den Sie heute angewiesen sind. Starten Sie einen dauerhaften Thread. Streamen Sie eine lang andauernde Ausführung. Unterbrechen Sie sie während des Laufs und setzen Sie sie später fort. Starten Sie mehr als einen Worker-Prozess. Beenden Sie einen Worker mitten in einer Aufgabe und überprüfen Sie, ob die Ausführung dennoch korrekt abgeschlossen wird. Führen Sie anschließend einen Backup von Postgres durch, stellen Sie es in einer separaten Umgebung wieder her und bestätigen Sie, dass die Thread-Historie unverändert erhalten bleibt.

Falls Ihre Einrichtung alle diese Überprüfungen bestehen lässt, haben Sie die wirklich wichtige Frage beantwortet – ob Langhost sich unauffällig in Ihre Infrastruktur integrieren kann, ohne zu einer Belastung zu werden.

Der Quellcode, die Einrichtungsanleitung sowie der Issue-Tracker sind unter langhost/langhost auf GitHub verfügbar.