Self-Hosting LangGraph Agent Server With Postgres and Redis

Retain the LangGraph SDK, Studio, and Agent Server exactly as they are. Move durable state into Postgres and hand coordination duties to Redis, all without needing a runtime license key.

Writing a LangGraph agent is usually the straightforward part.

You run the graph locally, tools execute, state flows from node to node. Then someone raises the question that turns a prototype into a real operations concern: how do you actually run this for production traffic?

An agent server has to track far more than a simple request-response API would. Conversations require durable threads that persist across sessions. Some runs pause waiting for a human to approve a step, then resume much later. Clients expect a stream of events rather than a single response. Scheduled jobs must trigger exactly once even when multiple workers are racing to pick them up. And if a worker crashes mid-run, another worker needs to take over cleanly without leaving the state corrupted.

langgraph dev is fine for local development, and LangChain's documentation itself frames it as a development server rather than a production one. It keeps state in memory and a local folder. The sanctioned path to production is LangSmith Deployments, available either as a managed service or under a self-hosting license.

Langhost proposes a different path. It runs the unmodified LangGraph Agent Server on top of Postgres and Redis, using a persistence runtime released under the MIT license.

On the surface that looks like a minor swap. It is minor. That is precisely what makes it worth paying attention to.

The design choice that makes Langhost interesting

Rather than reimplementing the Agent Protocol or forcing applications onto a different API, Langhost keeps the official Agent Server package, langgraph-api, untouched. What changes is the layer underneath it: the langgraph-runtime-pg package takes over persistence.

Here is roughly how the pieces fit together:

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

Applications that already exist keep their graph definitions and langgraph.json file as-is. Clients keep talking to langgraph-sdk. Studio keeps connecting through the same Agent Server API it always used. Langhost intentionally avoids doing anything interesting at that boundary, which is exactly the right instinct for infrastructure.

Because the official server package stays in place, its full set of capabilities survives the swap too: managing assistants, tracking threads and individual runs, exposing the key-value store, firing scheduled jobs, pushing streamed output, calling webhooks, and supporting both MCP and A2A. A competing server implementation would need to continuously track every protocol change to keep all of that working. Langhost sidesteps that maintenance burden entirely by leaving protocol behavior to the upstream server and focusing only on storage and coordination.

What Postgres and Redis each do

Postgres holds everything that needs to survive a restart: assistant configurations, thread history, run records, scheduled job definitions, checkpoints, and any application data kept in the store. Schema migrations run through Alembic. For production deployments, the project's guidance is to apply migrations ahead of rollout and turn off automatic migration at server startup.

Redis is reserved for short-lived coordination tasks. It notifies workers when a new run lands in the queue, broadcasts stream events out to whichever server processes are connected, and keeps track of worker heartbeats.

That division becomes important once you scale out to multiple replicas. When a worker wants to pick up a pending run, it claims the row in Postgres using SKIP LOCKED, which prevents any other worker from grabbing the same run simultaneously. Redis heartbeats confirm the worker is still alive; if a heartbeat lapses, the queue is free to reassign that run to someone else. The project's test suite covers claim exclusivity, recovery from a stalled worker, concurrent threads, streaming behavior, cancellation, and state updates that happen while a run is still in progress.

This is exactly the piece that many "how to deploy your agent" guides gloss over. Spinning up an ASGI server is trivial. Making sure queue ownership and failure recovery work correctly under concurrent load is the actual engineering problem.

Moving an existing project

If you already have a Python LangGraph project with a langgraph.json file, adopting Langhost takes only a few steps.

Install it:

uv add langhost

Then point it at your Postgres and Redis instances:

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

And launch the server:

uv run langhost serve --reload

For a production process, bind explicitly to the network interface and set a fixed worker count:

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

By default it listens on port 31296. When it starts, the banner prints out links for the API itself, its documentation, LangSmith Studio, and the Agent Chat UI. Your existing client code keeps working unchanged, still using the 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())

This low-friction migration path is arguably Langhost's strongest selling point. A team can try it out without touching the application code or swapping any client libraries first.

The license boundary needs a careful reading

The langhost CLI and langgraph-runtime-pg ship under the MIT license. The standard langgraph-api package, however, still falls under the Elastic License 2.0. What Langhost actually does is swap out the proprietary Postgres and Redis runtime layer. It has no bearing on the licensing terms of the official server package itself.

That nuance tends to get lost when people label the whole stack "open source." The persistence layer you run and can modify via Langhost genuinely is MIT licensed. But the server component sitting on top of it stays source-available under Elastic 2.0, and you're still bound by those terms.

Even so, for many organizations the practical shift is meaningful. They gain the ability to run durable LangGraph workloads against self-managed databases without needing a runtime license key. It also means the application's state can remain entirely inside their own cloud account or internal network. That said, anyone considering this for company use should have legal or procurement teams read through both licenses directly, rather than trusting a marketing summary.

What you take on by self-hosting

Langhost lifts a licensing and runtime restriction. It does not lift the operational burden.

You become responsible for Postgres capacity planning, backups, recovery drills, connection pool limits, and schema migrations. You're also responsible for Redis uptime and memory eviction policy. On top of that, you need visibility - metrics and logs that reveal whether the job queue is backing up, whether workers have stalled, or whether streams are silently dropping. And before exposing the API beyond a trusted network, you need to lock it down properly.

Keep in mind that this project is still early-stage. The current release on PyPI is 0.11.1.post1, tagged with a beta classifier. It pins a specific matching version of langgraph-api, which keeps compatibility solid for that particular release but also means the project must continuously track upstream changes to stay current. The repository's test suite runs both its own first-party tests and the upstream Python SDK's integration tests against a live Agent Server, which is reassuring - but it's no replacement for validating your own graphs, traffic patterns, failure scenarios, and upgrade procedures.

For teams that would rather not operate any of this themselves, a managed LangSmith Deployment remains the more sensible route. Langhost is a better fit for teams already comfortable running Postgres and Redis, who need explicit control over where their state physically resides, or who simply can't adopt a licensed self-hosted runtime.

A practical way to evaluate it

Rather than starting from a list of features, take a staging copy of a LangGraph application you already have running and point it at Langhost instead.

Reuse the same langgraph.json, the same SDK client, and the same Studio workflow you rely on today. Spin up a durable thread. Stream a long-running execution. Interrupt it mid-flight and resume it later. Bring up more than one worker process. Kill a worker while it's mid-job and check that the run still completes correctly. Then take a Postgres backup, restore it to a separate environment, and confirm the thread history survives intact.

If your setup clears all of these checks, you'll have answered the question that actually matters - whether Langhost can quietly settle into your infrastructure without becoming a liability.

The source code, setup guide, and issue tracker are available at langhost/langhost on GitHub.