🔗 For translation, open lesson in new tab and use Chrome translate
LangGraph describes short and long-term memory. LangGraph uses short-term memory to store a thread's state after each superstep. This is referred to as the checkpoint memory. Long-term memory can be read and written by all threads and is referred to as a store. When deployed, a third type of storage is also available — the container's local filesystem. Sandboxes, which are often implemented as virtual machines, could also provide storage, but are not addressed here.
This lesson describes these options. It will highlight deployment-related aspects such as:
- Storage scope: is it accessible across runs and containers or local to the container
- Lifetime: do stored objects persist beyond the duration of run, thread, deployment
- On new revision: what happens when the deployment is updated with a new image — is storage overwritten, or are entries maintained
- On failure: what happens when a container fails or is shut down
A note on terminology: On new revision means pushing a new image to an existing deployment, not deleting and re-creating the deployment itself. The deployment's database persists across image redeployments — it only goes away if the deployment is deleted.
| Storage | Storage Scope | Lifetime | On Failure | On new revision |
|---|---|---|---|---|
| Checkpointer | Deployment-wide | Thread/ Deployment | Writes rolled back; step retries from last checkpoint | Preserved — DB is scoped to the deployment, survives image updates |
| LangGraph Store | Deployment-wide | Deployment | Writes survive; retry may write again — idempotency required | Preserved — DB is scoped to the deployment, survives image updates |
| Local filesystem | Container-local | Image | writes lost | Replaced — new image brings new files; runtime writes lost |
After every superstep, LangGraph writes the current state to the checkpoint database.
The checkpointer storage scope is deployment-wide. All containers in the deployment access the same checkpointer.
A thread sees only its own checkpoints. It accumulates the full message history and state for that thread. Those checkpoints persist as long as the thread exists on that deployment. A new thread starts fresh.
You can configure a TTL to clean up old checkpoint data. See Configuring thread and checkpoint TTL.
The checkpointer provides durable compute. If execution were to fail — for example, a container fails — the checkpointer can be used to restore the thread in another container and resume execution at the start of the last node.
When redeploying, the checkpointer is preserved so the existing threads maintain their state.
The Store is long-term memory that persists across threads. It is a key-value store where each item is identified by a namespace tuple and a key. Where the checkpointer is accessed by thread_id, the Store is accessed by namespace — any caller with permission to read that namespace sees the same data, regardless of which thread (or no thread) they are on. Access is subject to the deployment's auth rules, which are discussed in more detail in the auth module.
The store scope is deployment-wide. All containers in the deployment access the same store.
On failure, completed writes persist and are available when the graph is restored. Because nodes restart execution at the beginning of the failed node, any writes made before the failure will be repeated, so an idempotent design is important.
The Store survives redeployment. It lives in the same Postgres database as the rest of the deployment, scoped to the deployment name.
You can write to the Store from outside the agent (via the SDK) or from inside a graph node.
Every deployment runs in a Docker container. The container has a local filesystem — files baked into the image are available at their expected paths. The agent can read them with plain file I/O.
Data baked into the image can be read by every agent in that container. Writes are riskier: runs can move between containers (after a container shuts down, fails, or is replaced on redeploy), and any files written at runtime don't follow. Multiple agents running on the same container also share the same filesystem — a write from one run is visible to every other run on that container.
Files baked into the image are replaced with new files on redeployment, since the new image includes its own copy. The files may be identical. But any writes the agent makes at runtime — files created or modified during a run — are lost when the container is replaced.
Updating filesystem content requires building and deploying a new image.
There are two access patterns: from outside the deployment via the SDK client, and from inside a graph node.
| Storage | SDK client | Graph node |
|---|---|---|
| Checkpointer | Read + update thread state and history (threads.get_state / getState, threads.get_history / getHistory, threads.update_state / updateState) |
Automatic — the current state is passed into the node; values the node returns become the next checkpoint via reducers. No direct calls. |
| Store | Read + write (store.put_item / putItem, store.get_item / getItem, store.search_items / searchItems) |
Read + write (store.put, store.get, store.search) |
| Local filesystem | Not accessible | Read + write — file I/O |
The SDK client connects over HTTP and requires authentication (a LangSmith API key, or a user token when auth is enabled).
Inside a graph node, the store is injected directly as a Python object — no HTTP, no authentication. The node is already within the deployment's trust boundary.