Serving & Deploying — LangServe, Platform, Studio

Lesson 8: Serving & Deploying — LangServe, LangGraph Platform, Studio

You've built a chain or a graph. Now: how does it become an API? The Lang universe has three answers, from simplest to most full-featured: LangServe for plain chains, the LangGraph Platform for production agents, and LangGraph Studio for local development. Understanding which serves what keeps you from over- or under-deploying — and knowing which of these the maintainers still recommend.

Heads-up (verified 2026): LangServe was archived May 5, 2026 — the repo is read-only with a deprecation notice, superseded by the LangGraph Platform. It still works and many existing apps run on it, but new projects should not build on LangServe: use the LangGraph Platform (or plain FastAPI) instead. The rest of this lesson explains what LangServe was and what replaced it.
Key idea: "Serve" is the layer that turns your Python object into an HTTP endpoint with streaming, batch, and playground support. LangServe was the lightweight option for LCEL chains (archived May 2026 — use FastAPI or the Platform for new work); the LangGraph Platform is the heavyweight for stateful, checkpointed agents at scale.

LangServe — chains as REST APIs (archived 2026)

LangServe wrapped a Runnable in a FastAPI app in a few lines, exposing /invoke, /batch, /stream, and a web playground:

from fastapi import FastAPI
from langserve import add_routes

app = FastAPI(title="My Chain API")
add_routes(app, chain, path="/chain")

# Now live at http://localhost:8000/chain/playground

LangServe was ideal for LCEL pipelines: minimal code, immediate HTTP + streaming + playground. Its limitation: it served a stateless runnable. If your app needed threads, checkpoints, or human-in-the-loop resumption, you needed graph infrastructure — exactly what the Platform provides. Since the May 2026 archive, the migration path is: keep existing LangServe deployments running (it still works), but point new work at the LangGraph Platform — or skip the serving layer entirely and expose your chain with plain FastAPI, which is a few lines anyway.

LangGraph Platform — production agents

The LangGraph Platform (formerly LangGraph Cloud) is a deployment stack purpose-built for LangGraph apps. It runs your graph as a managed service — either in LangChain's cloud or self-hosted (Docker/K8s) — and adds what a bare API can't:

  • Threads — persistent conversation sessions with checkpointing across requests
  • Assistants — versioned, configurable graph deployments (one graph, many configs)
  • Cron jobs — scheduled graph runs (e.g., a daily report agent)
  • Human-in-the-loop APIs — interrupt/resume endpoints for approval workflows
  • LangSmith integration — tracing and evals wired in by default
LANGSERVE vs LANGGRAPH PLATFORM LangServe — ARCHIVED 2026 LCEL chains only stateless · REST + stream superseded by Platform LangGraph Platform stateful agents threads · cron · HITL managed or self-hosted

LangGraph Studio — the IDE

LangGraph Studio is a visual development environment for graphs: you run a graph locally, and Studio renders the state machine, lets you step through nodes, inject interrupts, inspect checkpoints, and even edit state mid-run (time travel for debugging). It's the fastest way to understand why an agent did what it did.

Choosing a serving layer

You have…Use…
An LCEL chain, stateless, new projectPlain FastAPI (LangServe is archived — don't start new work on it)
A LangGraph agent needing threads/persistenceLangGraph Platform (managed or self-hosted)
Complex custom API logic around the modelPlain FastAPI, calling the graph as a library
An existing LangServe deploymentKeep it running, but plan a migration to FastAPI or the Platform
Local development/debugging of a graphLangGraph Studio + langgraph dev
Pitfall: Don't reach for the Platform for a single stateless endpoint — you'll pay (in complexity and possibly dollars) for threads and checkpointing you don't need. Conversely, don't try to bolt persistence onto LangServe; you'll end up rebuilding the Platform badly.
Rule of thumb: Stateless → FastAPI (or an existing LangServe deployment, but don't start new ones). Stateful agent → Platform. Custom app → FastAPI calling the graph directly. The graph object itself is just a Python callable — you can always skip the serving layer entirely and host it however you like.

🧠 Knowledge Check

1. What does LangServe add on top of a Runnable?

2. Which feature belongs to the LangGraph Platform but NOT LangServe?

3. What is LangGraph Studio?

Further Reading