Accueil / Articles / Serveur d’agent LangGraph auto-hébergé avec Postgres et Redis

LangGraphPostgresRedisSelf-HostingLLMAgents

Serveur d’agent LangGraph auto-hébergé avec Postgres et Redis

Découvrez comment Langhost remplace la couche de persistance de LangGraph par Postgres et Redis, permettant aux équipes d’héberger elles-mêmes le Agent Server non modifié sous une licence MIT.

1503 mots

Gardez le LangGraph SDK, Studio et Agent Server tels qu’ils sont. Déplacez l’état persistant dans Postgres et confiez les tâches de coordination à Redis, tout cela sans avoir besoin d’une clé de licence en temps de exécution.

Rédiger un agent LangGraph est généralement la partie la plus simple.

Un agent serveur doit suivre bien plus que ce qu’une simple API demande-réponse permettrait. Les conversations nécessitent des threads durables qui persistent entre les sessions. Certaines exécutions s’arrêtent en attendant qu’un humain approuve une étape, puis reprennent bien plus tard. Les clients s’attendent à un flux d’événements plutôt qu’à une seule réponse. Les tâches planifiées doivent s’exécuter exactement une fois, même lorsque plusieurs travailleurs tentent de les traiter en même temps. Et si un travailleur plante au milieu d’une exécution, un autre doit reprendre le relais proprement sans endommager l’état actuel.

langgraph dev convient pour le développement local, et la documentation même de LangChain le présente comme un serveur de développement et non comme un serveur en production. Il conserve l’état en mémoire ainsi que dans un dossier local. La solution reconnue pour la production est LangSmith Deployments, disponible soit en tant que service géré, soit sous licence d’hébergement autonome.

Langhost propose une approche différente. Il exécute le serveur Agent LangGraph non modifié sur Postgres et Redis, en utilisant un environnement de durée de vie des données publié sous licence MIT.

À première vue, cela ressemble à un simple changement mineur. C’est effectivement le cas, et c’est précisément ce qui rend cela digne d’attention.

Le choix de conception qui rend Langhost intéressant

Au lieu de réimplémenter le protocole Agent ou d’obliger les applications à utiliser une API différente, Langhost laisse intact le paquet officiel du serveur Agent, langgraph-api. Ce qui change, c’est la couche en dessous : le paquet langgraph-runtime-pg prend en charge la gestion de la persistance.

Voici à peu près comment les éléments s’assemblent :

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

Les applications existantes conservent leurs définitions de graphes ainsi que le fichier langgraph.json tel quel. Les clients continuent de communiquer avec langgraph-sdk. Studio reste connecté via la même API Agent Server qu’il utilisait auparavant. Langhost évite délibérément de faire quoi que ce soit d’intéressant à cet égard, ce qui est précisément l’attitude appropriée pour une infrastructure.

Puisque le paquet serveur officiel reste en place, l’ensemble de ses fonctionnalités survit également au changement : gestion des assistants, suivi des threads et des exécutions individuelles, mise à disposition du stockage clé-valeur, exécution de tâches planifiées, envoi d’informations en flux continu, appel de webhooks, ainsi que prise en charge à la fois de MCP et d’A2A. Une implémentation serveur concurrente devrait suivre en permanence chaque modification de protocole pour que tout cela continue de fonctionner. Langhost évite complètement cette charge de maintenance en laissant le comportement des protocoles au serveur source et en se concentrant uniquement sur le stockage et la coordination.

Quel est le rôle de Postgres et Redis ?

Postgres conserve tout ce qui doit survivre à une redémarrage : les configurations des assistants, l’historique des threads, les enregistrements des exécutions, les définitions des tâches planifiées, les points de contrôle, ainsi que tous les données d’application stockées. Les migrations de schéma s’effectuent via Alembic. Pour les déploiements en production, la recommandation du projet est d’appliquer les migrations avant le lancement et de désactiver la migration automatique au démarrage du serveur.

Redis est réservé aux tâches de coordination à courte durée. Il notifie les travailleurs lorsqu’une nouvelle exécution arrive dans la file d’attente, diffuse les événements en flux vers tous les serveurs de traitement connectés, et suit l’état des travailleurs.

Cette séparation devient importante lorsque l’on passe à plusieurs réplicas. Lorsqu’un travailleur souhaite reprendre une tâche en attente, il réserve la ligne dans Postgres en utilisant SKIP LOCKED, ce qui empêche tout autre travailleur de saisir la même tâche en même temps. Les signaux de vie envoyés par Redis confirment que le travailleur est toujours actif ; si un signal de vie manque, la file d’attente peut réaffecter cette tâche à quelqu’un d’autre. Le jeu de tests du projet couvre l’exclusivité des réservations, la récupération en cas de travailleur bloqué, les threads concurrents, le comportement en flux continu, la cancellation ainsi que les mises à jour d’état qui ont lieu pendant qu’une tâche est encore en cours.

C’est précisément ce point que de nombreux guides « comment déployer votre agent » omettent. Mettre en place un serveur ASGI est trivial. S’assurer que la propriété de la file d’attente et la récupération en cas de panne fonctionnent correctement sous charge concurrente, voilà le véritable défi technique.

Déplacer un projet existant

Si vous disposez déjà d’un projet Python LangGraph avec un fichier langgraph.json, intégrer Langhost ne nécessite que quelques étapes.

Installez-le :

uv add langhost

Puis pointez-le vers vos instances Postgres et Redis :

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

Et lancez le serveur :

uv run langhost serve --reload

Pour un environnement de production, liez-le explicitement à l’interface réseau et définitz un nombre fixe d’ouvriers :

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

Par défaut, il écoute sur le port 31296. Lorsqu’il démarre, l’afficheur affiche des liens vers l’API elle-même, sa documentation, LangSmith Studio et l’interface Agent Chat. Votre code client existant continue de fonctionner sans modification, en utilisant toujours le SDK standard :

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())

Cette méthode de migration simple est sans doute le principal atout de Langhost. Une équipe peut l’essayer sans avoir à modifier le code de l’application ni à changer de bibliothèques clients au préalable.

Il convient de lire attentivement les conditions de licence

La CLI langhost ainsi que langgraph-runtime-pg sont distribuées sous licence MIT. En revanche, le paquet standard langgraph-api reste soumis à la licence Elastic License 2.0. Ce que fait réellement Langhost, c’est remplacer la couche de runtime propriétaire Postgres et Redis ; cela n’a aucun impact sur les conditions de licence du paquet serveur officiel lui-même.

Cette nuance est souvent négligée lorsque l’on qualifie l’ensemble de la stack de « open source ». La couche de persistance que vous exécutez et que vous pouvez modifier via Langhost est effectivement sous licence MIT. Mais le composant serveur qui la surmonte reste accessible en source sous Elastic 2.0, et vous êtes toujours lié par ces conditions.

Même ainsi, pour de nombreuses organisations, ce changement pratique est significatif. Elles gagnent la capacité d’exécuter des charges de travail LangGraph fiables sur des bases de données gérées en interne, sans avoir besoin d’une clé de licence pour l’exécution. Cela signifie également que l’état de l’application peut rester entièrement contenu dans leur propre compte cloud ou réseau interne. Néanmoins, toute personne envisageant d’utiliser cette solution au sein de son entreprise devrait faire examiner les deux licences directement par des équipes juridiques ou de achats, plutôt que de se fier à un résumé marketing.

Les conséquences du self-hosting

Langhost supprime les restrictions liées aux licences et à l’exécution. Il ne supprime pas cependant la charge opérationnelle.

Vous êtes responsable de la planification des capacités de Postgres, des sauvegardes, des exercices de récupération, des limites du pool de connexions et des migrations de schéma. Vous êtes également responsable du temps de fonctionnement de Redis ainsi que de la politique d’éviction de la mémoire. De plus, vous avez besoin de visibilité : des métriques et des journaux qui révèlent si la file d’attente des tâches est en cours de sauvegarde, si les travailleurs sont bloqués ou si les flux sont silencieusement perdus. Et avant d’exposer l’API en dehors d’un réseau fiable, vous devez la sécuriser correctement.

N’oubliez pas que ce projet en est encore à un stade précoce. La dernière version disponible sur PyPI est 0.11.1.post1, marquée comme bêta. Elle fixe une version spécifique de langgraph-api, ce qui assure la compatibilité pour cette version particulière, mais cela signifie également que le projet doit suivre en permanence les modifications apportées par l’origine pour rester à jour. Le jeu de tests du répertoire exécute à la fois ses propres tests et les tests d’intégration du SDK Python source, sur un serveur Agent en direct, ce qui est rassurant – mais cela ne remplace pas la validation de vos propres graphes, modèles de trafic, scénarios d’échec et procédures de mise à niveau.

Pour les équipes qui préfèrent ne pas gérer tout cela elles-mêmes, une déploiement LangSmith géré reste la solution la plus judicieuse. Langhost convient mieux aux équipes déjà à l’aise avec Postgres et Redis, qui ont besoin d’un contrôle précis sur l’emplacement physique de leur état, ou qui ne peuvent tout simplement pas adopter un environnement d’exécution auto-hébergé sous licence.

Une façon pratique de l’évaluer

Au lieu de partir d’une liste de fonctionnalités, prenez une copie de test d’une application LangGraph que vous exécutez déjà et pointez-la vers Langhost à la place.

Réutilisez le même langgraph.json, le même client SDK et le même flux de travail Studio que vous utilisez actuellement. Créez un thread durable, diffusez une exécution de longue durée, interrompez-la en cours d’exécution puis reprenez-la plus tard. Lancez plusieurs processus travailleurs, arrêtez-en un en plein traitement et vérifiez que l’exécution se termine correctement. Ensuite, effectuez une sauvegarde de Postgres, restaurez-la dans un environnement distinct et confirmez que l’historique des threads reste intact.

Si votre configuration passe tous ces tests, vous aurez répondu à la vraie question : Langhost peut-il s’intégrer discrètement dans votre infrastructure sans devenir un fardeau.

Le code source, le guide de configuration et le suivi des problèmes sont disponibles à langhost/langhost sur GitHub.

Lectures complémentaires

Tous les articlesEnvoyer le brief