Deploying LangGraph Agents to Production: The Full Checklist

Published: 2026-07-28 | By: Carlos Montiel | Reading time: ~4 minutes

A graph that works in a notebook is several steps away from being ready for production. This is the checklist we apply before giving the green light to a LangGraph agent with real users.

1. Real persistence, not MemorySaver

`MemorySaver` stores state in the Python process's memory: it's lost on every restart and doesn't work if you have more than one instance of the service behind a load balancer, because each instance would have its own isolated memory. For production, use `PostgresSaver` or `RedisSaver` with a database shared across instances:

from langgraph.checkpoint.postgres import PostgresSaver
from psycopg_pool import ConnectionPool

pool = ConnectionPool(
    conninfo=os.environ["DATABASE_URL"],
    max_size=20,
    kwargs={"autocommit": True, "prepare_threshold": 0},
)
checkpointer = PostgresSaver(pool)
checkpointer.setup()

app = builder.compile(checkpointer=checkpointer)

Also check your retention policy: abandoned conversations accumulate rows indefinitely if there's no scheduled job purging inactive threads after N days, according to your data policy.

2. Recursion and time limits

A graph with a poorly conditioned cycle can enter an infinite loop, burning through API budget before anyone notices. LangGraph has a default recursion limit, but it should be explicitly tuned to your case:

config = {
    "configurable": {"thread_id": thread_id},
    "recursion_limit": 25,
}
try:
    result = app.invoke(input_data, config=config)
except GraphRecursionError:
    logger.error("Graph exceeded recursion limit", extra={"thread_id": thread_id})
    result = fallback_response()

Complement this with an infrastructure-level timeout (for example, at the gateway or the worker that invokes the graph), independent of the recursion limit, to cover the case of a single node hanging while waiting on a slow external API.

3. Per-node error handling

A node that raises an uncaught exception stops the entire graph. For external tools (third-party APIs, databases), wrap the node's logic with explicit error handling that returns a readable error state instead of propagating the raw exception:

def check_inventory_node(state: AgentState):
    try:
        result = inventory_api.query(state["sku"])
        return {"inventory": result, "error": None}
    except TimeoutError:
        return {"inventory": None, "error": "inventory_timeout"}
    except Exception as e:
        logger.exception("Unexpected error checking inventory")
        return {"inventory": None, "error": "unknown_error"}

The next node in the graph can then branch based on `state["error"]`, deciding whether to retry, escalate to a human, or respond with an apology message to the user, instead of the user getting a context-free 500 error.

4. LangGraph Platform vs. self-hosted deployment

For teams that don't want to operate checkpointing, queuing, and scaling infrastructure, LangGraph Platform offers managed deployment with REST APIs auto-generated from the compiled graph, native streaming, and a dashboard for managing threads and pending interrupts. For teams with strict data residency requirements (common with financial and government clients in the region), self-hosted deployment on an ASGI server exposed with `langgraph-api` is still the option, in exchange for operating the persistence and scaling infrastructure yourself.

5. Observability from day one

Wire up LangSmith (or an equivalent tracing system) before the first real user, not after the first incident. Every invocation should carry correlation metadata — `user_id`, `thread_id`, deployed graph version — so you can filter traces when something breaks:

config = {
    "configurable": {"thread_id": thread_id, "user_id": user_id},
    "tags": ["prod", "v2.3.0"],
    "metadata": {"channel": "whatsapp"},
}

6. Regression tests against the full graph

Before every deployment, run the evaluation suite (covered in the article on LangSmith) against the full graph, not just against isolated individual nodes: a change to the supervisor node's prompt can alter routing to workers in non-obvious ways if only the modified node is tested in isolation. The minimum checklist before promoting to production: shared persistence configured, recursion limit tuned, error handling for every node that can fail externally, traceability with correlation metadata, and the evaluation suite run against the full compiled graph.

Carlos Montiel
Enterprise AI Solutions Architect
Specialist in LLMs, Agents, and Orchestration
guatemalia.com/en/#contact · info@guatemalia.com

← Back to index Next article →