Your LangGraph Agent Loses Everything When the Server Restarts

LangGraph handles the orchestration logic of stateful agent workflows: the graph structure, state transitions, human-in-the-loop interrupts, and fault recovery. It does not handle persistence, state storage, or the infrastructure those workflows run on. Those are your problems. For teams moving from a working prototype to production, that boundary shows up fast, usually when a server restarts and every conversation thread your agents were managing disappears.

Let’s say a development team builds a contract review agent using LangGraph. Multiple agents collaborate in a graph: one extracts clauses, another flags risk terms, a third summarizes. In development, everything runs on MemorySaver, which keeps state in RAM. It works well in demos. They ship to production. Two days later, a routine deployment restarts the server. Every active review thread is gone. The team digs into the LangGraph documentation and finds the fix: PostgresSaver, backed by a real Postgres instance with the right schema set up. But that means they now need a production database, a connection pool, a retention strategy before checkpoints accumulate enough to inflate query latency, and long-running compute that stays alive for the hours or days a contract review might take. None of that is hard, but none of it is automatic.

What LangGraph Manages and What It Does Not

LangGraph is, in its own documentation’s words, “a low-level orchestration framework for building, managing, and deploying long-running, stateful agents.” The key word is orchestration. LangGraph defines how agent state flows through a graph, how nodes transition, how branches resolve, and how the system recovers from mid-execution failures. It is the logic layer.

The persistence layer is separate. LangGraph defines two persistence systems that sit beneath the orchestration:

• Checkpointers save a snapshot of the graph state at every step of execution. They are scoped to a thread: a unique ID representing a continuous sequence of runs. Checkpointers enable conversation continuity (the agent remembers where it left off), human-in-the-loop workflows (a human can review and modify state before execution resumes), fault tolerance (if a node fails mid-execution, LangGraph stores completed work so it can resume from the checkpoint rather than restarting), and time travel (you can rewind to any prior checkpoint for debugging). The official LangGraph documentation is direct: MemorySaver and InMemorySaver store checkpoints in RAM and lose everything on process restart. For production, PostgresSaver is the primary recommended backend.
• Stores persist application-defined data outside the graph state. Where a checkpointer is thread-scoped and tracks the current conversation, a store is cross-thread and tracks durable information across all threads: user preferences, accumulated facts, shared knowledge, retrieved document context. Most production agent deployments need both: a checkpointer to track the current thread and a store to track durable information that the agent should carry across separate interactions.

What neither system provides: the Postgres instance for the checkpointer, the storage backend for the store, or the compute infrastructure running the agents themselves.

Why MemorySaver Is Not a Production Checkpointer

It is easy to build a LangGraph agent that works well in development. MemorySaver requires no external dependencies, starts instantly, and handles all the persistence operations the framework expects. Every demo and tutorial defaults to it. The problem is not that it works badly. The problem is that it works perfectly right up until the moment a process restarts, and then it has zero state.

The LangGraph documentation’s troubleshooting section puts it plainly: MemorySaver and InMemorySaver store checkpoints in RAM. When the process restarts, all checkpoints are lost. The fix they recommend: use a persistent checkpointer for production, specifically PostgresSaver.

For teams that ship agent applications, this matters in at least three concrete ways:

• Deployments restart processes. Any standard deployment workflow, whether a container restart, a rolling update, or a crash recovery, clears RAM. Agent threads that were mid-execution are gone.
• Long-running workflows outlast process uptime. A contract review, a research task, or a multi-step data reconciliation job might run for hours. A process lifetime is not guaranteed to match a workflow lifetime.
• Multi-instance deployments share no RAM. If your agent application scales horizontally to two instances, threads are routed to whichever instance handles the request. An in-memory checkpointer on instance A has no access to threads that started on instance B. Agents see each other as different conversations with no history.

None of these are edge cases. They are the normal operational conditions of a production service.

What PostgresSaver Requires From Your Infrastructure

PostgresSaver and AsyncPostgresSaver are the LangGraph-recommended production checkpointing backends for Python. They write graph state snapshots to a Postgres database using a schema the library sets up on initialization. The operational requirements are straightforward:

• A reliable Postgres instance. This is the dependency most teams underestimate. LangGraph itself is stateless between invocations; the database is where durability lives. A managed Postgres service or a self-hosted Postgres on dedicated hardware both work. What matters is that it is available when agents need to write checkpoints, and that it performs consistently. High write latency at the checkpoint layer translates directly into agent response latency, because checkpoint writes happen at every step of execution.
• A retention policy. The official LangGraph documentation warns explicitly: over long conversations, checkpoints accumulate. This increases latency and storage costs. The recommended fix is a periodic process to delete checkpoints older than a defined window. Building that process and deciding on the right retention window are operational decisions that belong to your team, not to LangGraph.
• Connection management. PostgresSaver connects to Postgres using psycopg3. Under load, with many concurrent agent threads, connection pooling matters. PgBouncer or a similar pooler is the standard production pattern. That adds another infrastructure component to deploy, monitor, and maintain.

For the Store layer, the requirements depend on what your agents need to remember across threads. A simple key-value store can run on Postgres as well, using LangGraph’s PostgresStore. Vector search for semantic retrieval over long-term memory is heavier and typically benefits from a dedicated embedding index, whether that is pgvector on Postgres, a standalone vector database, or object storage backing a retrieval layer.

The Compute Profile of a Production LangGraph Deployment

Agent workflows are not request-response workloads. A standard web API receives a request, does some computation, and returns a response, typically in milliseconds to seconds. A LangGraph agent receives a task, may run for minutes to hours, writes state at every step, potentially awaits human input, and eventually completes. The compute layer needs to match that profile.

Long-running processes. Serverless compute and short-lived containers are a bad fit for agent workflows. A function that times out after 30 seconds cannot run a workflow that takes 20 minutes. The compute layer needs to support long-running processes, which in practice means persistent VMs or containers with no execution time cap. OpenStack on bare metal gives you VMs that run as long as the workflow runs.

RAM for context and concurrent state. LangGraph checkpoints carry graph state, which for conversational agents includes message history, retrieved context, and tool outputs. A single long-running agent thread with a large context window might hold several hundred megabytes of working state. At scale, with hundreds of concurrent threads active, memory pressure becomes a real constraint. The XL v5 server at 1TB DDR5-6400 RAM gives you headroom for large concurrent workflow populations without contention. The Large v5 at 512GB handles moderate deployments. Sizing depends on your thread count and context window profile.

Predictable cost at continuous load. Agent workloads run continuously. They do not have clear off-peak hours the way batch jobs do. A customer-facing agent application handles requests at all hours. Usage-based compute billing compounds in that environment. OpenMetal’s fixed monthly pricing for dedicated bare metal means your infrastructure cost is stable regardless of whether your agents are busy or quiet.

Klarna runs LangGraph for customer support across 85 million active users, and Elastic uses it for their security AI assistant, according to LangGraph’s own documentation. At that scale, the infrastructure decisions matter as much as the framework choice.

Where OpenMetal Fits

The infrastructure a production LangGraph deployment needs maps cleanly onto what OpenMetal provides:

• The agent application and the LangGraph runtime run on dedicated compute inside a hosted private cloud. OpenStack manages the VM lifecycle. Workflows run in VMs with no execution time cap.
• PostgresSaver connects to a Postgres instance running on the same private VLAN. The 20 Gbps private bandwidth between servers in the same OpenMetal deployment means checkpoint writes and reads happen over a fast, low-latency internal link rather than crossing a public network or a managed service’s API endpoint.
• The Store layer for long-term cross-thread memory can run on Ceph, which is integrated into every OpenMetal hosted private cloud. Object storage for document archives, block storage for database volumes, and file storage for shared context are all available from the same Ceph cluster without adding external services.

Deploying this stack on OpenMetal is straightforward: provision a Cloud Core, deploy your Postgres instance and agent application as VMs inside the private cloud, connect them on the private VLAN, and run. The approximately 45-second cloud deployment and 20-minute node scaling means you can get a working stack running quickly and expand the Postgres or compute tier as workloads grow. Full hardware specifications are at OpenMetal’s hardware details page.

For teams that have already built agent sandboxes on OpenMetal, adding LangGraph persistence infrastructure is an extension of the same environment, not a separate project. The agent code execution sandbox guide covers the sandbox layer; this article covers the persistence and state layer that sits alongside it.

For teams running stateful agents on OpenStack with storage requirements beyond what Postgres handles, the Persistent Storage for Nomad guide covers CSI integration with Ceph on OpenStack in detail.

LangGraph Platform vs. Self-Hosting

LangGraph provides a managed deployment option, the LangGraph Platform (also called the Agent Server in some documentation), which handles checkpointing automatically without requiring you to configure PostgresSaver or manage database infrastructure yourself. For many teams, especially early in development or at low scale, the managed platform is the right starting point.

The trade-off is the same one that applies to any managed service: your agent state lives in infrastructure you do not control. For many agent applications that is acceptable. For applications where the data your agents process is sensitive, regulated, or subject to strict residency requirements, it is not.

Self-hosting on OpenMetal gives you the operational overhead of running Postgres and managing checkpoint retention, in exchange for knowing exactly where your state lives, who can access it, and what happens to it. That trade-off is worth making when:

Your agents process data that cannot leave your infrastructure, such as source code, customer records, or regulated financial or healthcare data. The LangGraph Platform stores checkpoint state on infrastructure you do not administer.

You need audit access to agent state for compliance purposes, including EU AI Act Article 12 logging obligations for high-risk AI deployments.

Your call volume is high enough that the economics of dedicated infrastructure beat the per-request pricing of a managed service.

Who This Makes Sense For

This infrastructure approach fits teams that:

• Are moving a LangGraph prototype to production and have already hit the MemorySaver restart problem
• Build multi-step agent workflows that run for minutes or hours, such as document review, research pipelines, or multi-agent coordination tasks where session state must survive restarts
• Process sensitive or regulated data in agent workflows where state must stay inside a controlled environment
• Run agent applications at continuous load where fixed compute cost is more predictable than usage-based billing
• Already operate on OpenMetal for other workloads and want to run their LangGraph persistence layer on the same private network without adding external managed services

This approach adds operational overhead you may not need if:

• You are in early development or prototyping and the managed platform handles your scale without compliance constraints
• Your agent workflows are short-lived and stateless, completing in a single interaction with no need for cross-session memory
• You do not have the engineering capacity to manage a self-hosted Postgres instance and checkpoint retention process

The Infrastructure Boundary Is Yours to Define

LangGraph draws a clear line: the framework handles orchestration, and the persistence layer handles state. Where that persistence layer runs, how it is backed up, what retention policy applies, and what the compute looks like are decisions that belong to whoever deploys the system. Getting those decisions right early is easier than retrofitting them after a production incident.

Start a proof of concept or contact our team to walk through what a production LangGraph infrastructure stack looks like on your workload.

Frequently Asked Questions

Why Does LangGraph Use MemorySaver as the Default If It Does Not Work in Production?

MemorySaver requires no external dependencies, which makes it ideal for development, testing, and tutorials. LangGraph’s documentation explicitly categorizes it as a development tool and recommends PostgresSaver for any production deployment. The default exists to lower the barrier to getting started, not to imply it is production-ready.

Can LangGraph’s Store Layer Run on the Same Postgres Instance as the Checkpointer?

Yes. LangGraph provides PostgresStore as a store implementation backed by Postgres, which can run on the same database instance as PostgresSaver. For workloads requiring semantic retrieval over long-term memory, the pgvector extension on Postgres adds vector search capabilities without requiring a separate vector database. Whether to run them on the same instance or separate them depends on load characteristics and your preference for operational simplicity vs. resource isolation.

What Is the Difference Between a LangGraph Checkpointer and a Store?

A checkpointer saves thread-scoped graph state snapshots at every execution step. It enables conversation continuity, fault recovery, human-in-the-loop workflows, and debugging. A store persists application-defined data across threads: user preferences, accumulated facts, shared knowledge, or retrieved document context that should be available across separate conversations. Most production deployments need both. The LangGraph documentation describes them as complementary: a checkpointer tracks the current thread, a store tracks durable information across threads.

Does Running LangGraph on Bare Metal Require Any Changes to the Framework?

No. LangGraph is infrastructure-agnostic. You configure PostgresSaver with a connection string pointing to your Postgres instance regardless of where that instance runs. The only difference between running on managed cloud infrastructure and running on OpenMetal bare metal is where Postgres is hosted and what network path the connection takes. On OpenMetal, Postgres and the agent application run on the same private VLAN, which reduces latency on checkpoint reads and writes.

How Much RAM Does a Production LangGraph Deployment Need?

It depends on the number of concurrent agent threads, the size of the context each thread carries, and whether your agents do local inference or call external APIs. A deployment with dozens of concurrent threads and moderate context windows runs comfortably on a Large v5 server at 512GB. A deployment with hundreds of concurrent threads or large context windows benefits from the XL v5 at 1TB. The XL v5 also supports Intel TDX for deployments where confidential computing is a requirement. Hardware details are at openmetal.io/resources/hardware-details/.