Clarification on Official Container Images, Supported Python Versions, and the Recommended LangGraph Deployment Path

OSS Product Help LangChain
, ,
1

Hi team,

We’re trying to align our containerization strategy with the officially supported approach for LangChain/LangGraph, and we need clarification on what the upstream-supported path looks like today.

Context

  • The last published langchain/langchain Docker Hub image appears to be from ~2023 and no longer updated.

  • LangGraph seems to be the current recommended mechanism for deployable, containerized applications.

  • The only actively updated images we can find are:

    • langchain/langgraph-api:3.11

    • langchain/langgraph-api:3.12

    • langchain/langgraphjs-api:20

Before we move forward, we want to make sure we’re following the intended upstream direction rather than recreating an out-of-date image or relying on deprecated tooling.

Questions

  1. Are the legacy langchain/langchain Docker images officially deprecated or unsupported?
    We want to confirm whether they should be considered EOL.

  2. Are the LangGraph API base images the only officially supported container images going forward?
    i.e., is all containerized deployment expected to happen through LangGraph?

  3. Which Python versions are officially supported for LangGraph-based container deployments?
    Currently we see 3.11 and `3.12 — is this the complete support matrix?

  4. Is the LangGraph CLI (and its build pipeline) now the authoritative way to build production images?
    Or is there another recommended pattern we should follow?

We want to ensure we build on top of the supported path and avoid reconstructing deprecated images.

Thanks for your help, any guidance or official stance would be appreciated.

2

Hello @rahulduvedi
Short answer: Use the LangGraph base images + the LangGraph CLI workflow, do not build new deployments from the old langchain/langchain Docker Hub image.**

The docs and CLI-generated Dockerfiles show the supported path is LangGraph (Agent runtime) + LangSmith deployment tooling. You should develop/test with langgraph dev, have the CLI generate the Dockerfile and build with langgraph build (it uses langchain/langgraph-api or langchain/langgraphjs-api base images), push that image to your registry, and deploy via the LangSmith control plane or self-hosted listeners.

What changed and why this matters

LangGraph is now the canonical runtime for long‑running, stateful agents; the docs and build tooling generate Dockerfiles that start from langchain/langgraph-api:<tag> (Python) or langchain/langgraphjs-api:<tag> (Node). That is the upstream-supported container base for Agent Servers and LangSmith Deployment. The old langchain/langchain Docker Hub image is effectively legacy for deployment use, don’t base new production builds on it.

Which images / Python versions to rely on

  • Official base images used by the CLI examples: langchain/langgraph-api:<tag> for Python and langchain/langgraphjs-api:<tag> for Node.
  • Documented Python tags you’ve seen in examples: 3.11 and 3.12 (use the image tags published in the registry). For Node, examples use Node 20 (langchain/langgraphjs-api:20).
    Pin the exact image tag you want (e.g., langchain/langgraph-api:3.12) when building your image.

Recommended deployment flow (canonical)

  1. Iterate and test locally:
    • langgraph dev — run the Agent Server locally.
  2. Author langgraph.json (declare deps, graphs, env, optional dockerfile_lines) and then:
    • langgraph build -t my-registry/my-agent:1.0.0 — CLI generates Dockerfile (starts FROM langchain/langgraph-api:<tag>) and builds the image.
  3. Push to your registry:
    • docker push my-registry/my-agent:1.0.0
  4. Deploy:
    • Use LangSmith control plane (UI/API) to create a Deployment referring to your image, or run the image directly for a standalone/self-hosted Agent Server (Docker Compose / Kubernetes + Helm).

Example langgraph.json + build commands

{
  "dependencies": ["."],
  "graphs": {
    "agent": "./src/agent.py:graph"
  },
  "env": ".env",
  "dockerfile_lines": [
    "RUN apt-get update && apt-get install -y libjpeg-dev zlib1g-dev libpng-dev",
    "RUN pip install Pillow"
  ]
}

# Test locally
langgraph dev

# Build the production image (CLI generates Dockerfile using langgraph-api base)
langgraph build -t my-registry/my-agent:1.0.0

# Push and deploy
docker push my-registry/my-agent:1.0.0
# Then deploy via LangSmith control plane (or run the image for standalone)

Why use langgraph build instead of hand-crafting the old image?

  • The CLI emits a Dockerfile that matches the current runtime expectations (constraints file, dependency installation, env setup).
  • It uses the officially supported LangGraph base image so you inherit runtime fixes, environment variables, and deployment integrations.
  • If you need extra OS libs or pip installs, add dockerfile_lines to langgraph.json instead of re-creating the whole base image.

Short checklist before you switch

  • Confirm the exact LangGraph image tag you want (e.g., 3.11 vs 3.12) and pin it.
  • Move Dockerfile customizations into langgraph.json dockerfile_lines where possible.
  • Test via langgraph dev and langgraph build locally before pushing to your registry.
  • Deploy using LangSmith control plane or follow the self-host standalone server docs for Docker / Kubernetes.

Relevant docs: