Servidor de agente LangGraph autohospedado con Postgres y Redis

Mantenga el LangGraph SDK, Studio y Agent Server tal como están. Transfiera el estado duradero a Postgres y delegue las tareas de coordinación en Redis, todo ello sin necesidad de una clave de licencia en tiempo de ejecución.

Escribir un agente LangGraph suele ser la parte más sencilla.

Ejecuta el grafo localmente, las herramientas se activan y el estado fluye de nodo en nodo. Luego surge la pregunta que convierte un prototipo en un problema real de operaciones: ¿cómo se ejecuta esto realmente con tráfico de producción?

Un servidor de agentes debe rastrear mucho más que lo que haría una API simple de solicitud-respuesta. Las conversaciones requieren hilos duraderos que persistan a través de las sesiones. Algunas ejecuciones se detienen esperando que un humano apruebe una acción y luego continúan mucho más tarde. Los clientes esperan un flujo de eventos en lugar de una sola respuesta. Las tareas programadas deben ejecutarse exactamente una vez, incluso cuando varios trabajadores compiten por procesarlas. Y si un trabajador falla durante su ejecución, otro debe tomar el control de manera limpia sin dañar el estado.

langgraph dev es adecuado para el desarrollo local, y la propia documentación de LangChain lo presenta como un servidor de desarrollo y no uno para producción. Mantiene el estado en la memoria y en una carpeta local. La opción oficial para producción es LangSmith Deployments, disponible tanto como servicio gestionado como bajo una licencia de auto-hospedaje.

Langhost propone un enfoque diferente. Ejecuta el Servidor de Agente LangGraph sin modificaciones sobre Postgres y Redis, utilizando un entorno de ejecución para persistencia publicado bajo la licencia MIT.

A primera vista parece un cambio menor. Lo es, pero precisamente por eso merece atención.

La elección de diseño que hace interesante a Langhost

En lugar de reimplementar el Protocolo de Agente o forzar a las aplicaciones a usar una API diferente, Langhost mantiene intacto el paquete oficial del Servidor de Agente, langgraph-api. Lo que cambia es la capa subyacente: el paquete langgraph-runtime-pg se encarga de la persistencia.

Aproximadamente así es como se integran las partes:

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

Las aplicaciones ya existentes mantienen sus definiciones de grafo y el archivo langgraph.json sin cambios. Los clientes siguen comunicándose con langgraph-sdk. Studio sigue conectándose a través de la misma API del Servidor de Agentes que siempre ha utilizado. Langhost evita intencionalmente realizar cualquier acción significativa en ese punto de conexión, lo cual es exactamente el instinto adecuado para la infraestructura.

Dado que el paquete del servidor oficial permanece en su lugar, todo su conjunto de funcionalidades también sobrevive al cambio: gestión de asistentes, seguimiento de hilos y ejecuciones individuales, exposición del almacén clave-valor, ejecución de tareas programadas, envío de resultados en tiempo real, llamada a webhooks y soporte tanto para MCP como para A2A. Una implementación de servidor competidora tendría que seguir de cerca cada cambio en los protocolos para mantener todo esto funcionando. Langhost evita por completo esa carga de mantenimiento al dejar el comportamiento de los protocolos en manos del servidor original y centrarse únicamente en el almacenamiento y la coordinación.

Qué hacen Postgres y Redis

Postgres almacena todo lo necesario para sobrevivir a un reinicio: configuraciones de asistentes, historial de hilos, registros de ejecución, definiciones de tareas programadas, puntos de control y cualquier dato de la aplicación que se conserve en el almacenamiento. Las migraciones de esquema se realizan mediante Alembic. Para despliegues en producción, la guía del proyecto indica aplicar las migraciones antes del lanzamiento y desactivar la migración automática al iniciar el servidor.

Redis está reservado para tareas de coordinación de corta duración. Notifica a los trabajadores cuando llega una nueva ejecución a la cola, transmite eventos en tiempo real a los servidores procesadores conectados y hace un seguimiento de las señales de actividad de los trabajadores.

Esa división se vuelve importante una vez que se escala a múltiples réplicas. Cuando un trabajador quiere tomar un proceso pendiente, reclama la fila en Postgres utilizando SKIP LOCKED, lo que impide que otro trabajador obtenga ese mismo proceso al mismo tiempo. Los mensajes de estado de Redis confirman que el trabajador sigue activo; si se produce una interrupción en estos mensajes, la cola puede reasignar ese proceso a otra persona. El conjunto de pruebas del proyecto abarca la exclusividad en las reclamaciones, la recuperación ante trabajadores bloqueados, los hilos concurrentes, el comportamiento de transmisión en tiempo real, la cancelación y las actualizaciones de estado que ocurren mientras un proceso está en curso.

Este es exactamente el aspecto que muchos guías de “cómo desplegar tu agente” pasan por alto. Iniciar un servidor ASGI es algo sencillo. Asegurarse de que la propiedad de la cola y la recuperación ante fallos funcionen correctamente bajo carga concurrente es el verdadero desafío técnico.

Mover un proyecto existente

Si ya cuenta con un proyecto Python LangGraph que incluye un archivo langgraph.json, adoptar Langhost solo requiere unos pocos pasos.

Instálelo:

uv add langhost

Luego diríjalo hacia sus instancias de Postgres y Redis:

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

Y inicie el servidor:

uv run langhost serve --reload

Para un entorno de producción, vincúlelo explícitamente a la interfaz de red y establezca un número fijo de trabajadores:

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

Por defecto, escucha en el puerto 31296. Al iniciar, se muestran enlaces a la propia API, su documentación, LangSmith Studio y la interfaz de usuario de Agent Chat. Su código de cliente existente seguirá funcionando sin cambios, utilizando aún el SDK estándar:

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

Este proceso de migración sencillo es, sin duda, el punto más fuerte de Langhost. Un equipo puede probarlo sin tocar el código de la aplicación ni cambiar ninguna biblioteca de cliente primero.

Es necesario leer con atención los términos de la licencia

La CLI langhost y langgraph-runtime-pg se distribuyen bajo la licencia MIT. Sin embargo, el paquete estándar langgraph-api sigue estando sujeto a la Licencia Elastic 2.0. Lo que realmente hace Langhost es reemplazar la capa de ejecución propietaria de Postgres y Redis. Esto no afecta en absoluto los términos de licenciamiento del paquete oficial del servidor en sí.

Esa sutileza suele pasarse por alto cuando la gente denomina a toda la solución “código abierto”. La capa de persistencia que se ejecuta y que se puede modificar a través de Langhost sí está licenciada bajo MIT. Pero el componente del servidor que se encuentra encima de ella sigue estando disponible con su código fuente bajo la licencia Elastic 2.0, por lo que sigues estando sujeto a dichos términos.

Aun así, para muchas organizaciones el cambio práctico es significativo. Obtienen la capacidad de ejecutar cargas de trabajo duraderas de LangGraph en bases de datos autogestionadas sin necesidad de una clave de licencia de tiempo de ejecución. También significa que el estado de la aplicación puede permanecer completamente dentro de su propia cuenta en la nube o red interna. Dicho esto, cualquiera que considere utilizarlo en la empresa debe hacer que los equipos legales o de adquisiciones lean directamente ambas licencias, en lugar de confiar en un resumen publicitario.

Qué implica el autoalojamiento

Langhost elimina las restricciones de licenciamiento y tiempo de ejecución. No elimina la carga operativa.

Usted será responsable de la planificación de capacidad de Postgres, las copias de seguridad, los ejercicios de recuperación, los límites del pool de conexiones y las migraciones de esquema. También será responsable del tiempo de actividad de Redis y de la política de eliminación de memoria. Además, necesita tener visibilidad: métricas y registros que muestren si la cola de tareas está realizando copias de seguridad, si los procesos se han detenido o si los flujos de datos se están perdiendo silenciosamente. Y antes de exponer la API más allá de una red confiable, debe protegerla adecuadamente.

Tenga en cuenta que este proyecto aún se encuentra en una fase inicial. La versión actual en PyPI es 0.11.1.post1, etiquetada como beta. Esta versión fija una versión específica de langgraph-api, lo que garantiza la compatibilidad para dicha versión en particular, pero también implica que el proyecto debe seguir de cerca los cambios en la fuente para mantenerse actualizado. El conjunto de pruebas del repositorio ejecuta tanto sus propias pruebas como las pruebas de integración del SDK de Python original contra un Servidor Agente en funcionamiento, lo cual es alentador; sin embargo, no sustituye la validación de sus propios grafos, patrones de tráfico, escenarios de fallo y procedimientos de actualización.

Para los equipos que prefieren no gestionar todo esto por sí mismos, una implementación gestionada de LangSmith sigue siendo la opción más sensata. Langhost es más adecuado para equipos que ya están familiarizados con el uso de Postgres y Redis, que necesitan un control explícito sobre dónde reside físicamente su estado, o para aquellos que simplemente no pueden adoptar un entorno autohospedado con licencia.

Una forma práctica de evaluarlo

En lugar de comenzar con una lista de funciones, tome una copia de pruebas de una aplicación LangGraph que ya esté en ejecución y diríjala hacia Langhost.

Reutilice el mismo langgraph.json, el mismo cliente SDK y el mismo flujo de trabajo de Studio en el que confía actualmente. Cree un hilo duradero, transmita una ejecución de larga duración, interrúmpala en curso y reanúdela más tarde. Inicie más de un proceso trabajador; detenga uno mientras está ejecutando una tarea y verifique que la ejecución se complete correctamente. Luego realice una copia de seguridad en Postgres, restórela en un entorno separado y confirme que el historial de los hilos se mantenga intacto.

Si su configuración supera todas estas pruebas, habrá respondido a la pregunta realmente importante: si Langhost puede integrarse silenciosamente en su infraestructura sin convertirse en una carga.

El código fuente, la guía de configuración y el sistema de seguimiento de problemas están disponibles en langhost/langhost en GitHub.

Lecturas relacionadas

• Construyendo agentes de IA seguros con límites y middleware de LangChain — Aprenda cómo funcionan los límites deterministas y basados en modelos en LangChain para detectar fugas de PII, aplicar reglas empresariales y agregar pasos de aprobación humana a los agentes de IA.
• Qué realmente automatiza LangChain una vez que ha creado un bucle de agente — Explica cómo LangChain, LangGraph y SDK similares envuelven el mismo bucle de agente básico creado desde cero, y cuándo recurrir a un framework ayuda o perjudica.