app.invoke() in a notebook proves your graph works. It doesn't give you an API other services can call, a way to run more than one user's conversation at a time, or somewhere for checkpoints to live once your laptop isn't the thing running the process. Getting from "it works locally" to "it's a service" is what this guide covers, and LangGraph gives you three real paths to get there.
What actually needs to change
Under the hood, a deployed graph needs the same things any backend service needs: an HTTP API wrapping your graph, a real database backing the checkpointer (not MemorySaver, which forgets everything on restart), a way to handle many runs at once instead of one blocking call, and somewhere to see what's happening when something goes wrong. You can build all of that yourself with a web framework and a Postgres instance, or you can let LangGraph handle it.
LangGraph Platform: the managed path
LangGraph Platform takes a graph you've already built and turns it into a running API, without you writing the server layer yourself. You define your graph and a small langgraph.json config file pointing to it, then deploy with the LangGraph CLI. In return you get a persistent API with endpoints for creating threads, starting runs, and streaming results, checkpointing backed by a real database automatically, horizontal scaling for concurrent runs, and a direct connection to LangGraph Studio (covered in the next guide) for inspecting live runs.
Self-hosting it yourself
If you'd rather not depend on the Platform at all, the underlying pieces are available as open packages: langgraph-api gives you the server layer, and you supply your own Postgres (for checkpoints) and Redis (for run queuing) alongside it, typically packaged as Docker containers. This is the most work, but it's the option with the fewest constraints if you already run your own infrastructure and have opinions about how it should be set up.
| Option | Who manages infra | Best for |
|---|---|---|
| Platform (cloud) | LangChain | Fastest path from working graph to production API |
| Platform (self-hosted) | You, using LangChain's images | Compliance/data residency needs, same feature set as cloud |
| Fully self-built | You, from scratch | Teams with existing infra and specific requirements Platform doesn't fit |
Don't reach for this on day one
Every guide in this series up to now has used MemorySaver or a local SqliteSaver and invoke() in a script, and that's the right amount of infrastructure for building and testing an agent. Deployment is a separate concern that only matters once the agent's behavior is actually settled. Standing up a production deployment for a graph whose prompts and logic are still changing daily means redeploying constantly for no benefit, get the agent working locally first, then deploy it once.