Deploy a LangChain Agent to Production: Hosting Compared

What It Takes to Deploy a LangChain Agent to Production

The gap between a LangChain script that works in a notebook and a service you can deploy a LangChain agent to production with is wider than most tutorials admit. The prototype runs once, prints an answer, and exits. Production means the process stays alive, keeps its state across restarts, holds API keys without leaking them, and is reachable over the network. None of that is about the agent's reasoning. It is about where and how the agent runs.

This article does two things. First, it shows a minimal but real LangChain agent and a container to ship it in. Second, it compares the hosting options honestly, bare VPS, serverless, container platforms, Kubernetes, and managed agent runtimes, so you can match the deployment to what your agent actually needs. If you are still weighing the broader build-versus-buy question, the AI agent platform comparison frames frameworks against managed runtimes before you get to code.

A Minimal LangChain Agent

Here is a small agent with one tool. It is deliberately plain so the deployment discussion, not the agent code, stays in focus. LangChain's own documentation goes deeper on tools, memory, and LangGraph.

import os
from langchain_openai import ChatOpenAI
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.tools import tool


@tool
def word_count(text: str) -> int:
    """Return the number of words in the given text."""
    return len(text.split())


llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a concise assistant. Use tools when helpful."),
    ("human", "{input}"),
    ("placeholder", "{agent_scratchpad}"),
])

agent = create_tool_calling_agent(llm, [word_count], prompt)
executor = AgentExecutor(agent=agent, tools=[word_count], verbose=False)

if __name__ == "__main__":
    result = executor.invoke({"input": "How many words are in this sentence?"})
    print(result["output"])

import os
from langchain_openai import ChatOpenAI
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.tools import tool


@tool
def word_count(text: str) -> int:
    """Return the number of words in the given text."""
    return len(text.split())


llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a concise assistant. Use tools when helpful."),
    ("human", "{input}"),
    ("placeholder", "{agent_scratchpad}"),
])

agent = create_tool_calling_agent(llm, [word_count], prompt)
executor = AgentExecutor(agent=agent, tools=[word_count], verbose=False)

if __name__ == "__main__":
    result = executor.invoke({"input": "How many words are in this sentence?"})
    print(result["output"])

To make this a service rather than a one-shot script, you wrap the executor in a small web server (FastAPI is the common choice) so requests come in over HTTP and the process stays up between them. That single change, from run-and-exit to stay-alive-and-serve, is what forces every hosting decision below.

Containerizing the Agent

You want the same artifact in every environment, so package it as a container. A minimal Dockerfile looks like this (shown in a shell block for readability):

# Dockerfile
FROM python:3.12-slim

WORKDIR /app

# Install dependencies first so this layer caches
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy the app
COPY . .

# The agent serves HTTP; do not bake secrets into the image
ENV PORT=8000
EXPOSE 8000

CMD ["uvicorn", "server:app", "--host", "0.0.0.0", "--port", "8000"]

# Dockerfile
FROM python:3.12-slim

WORKDIR /app

# Install dependencies first so this layer caches
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy the app
COPY . .

# The agent serves HTTP; do not bake secrets into the image
ENV PORT=8000
EXPOSE 8000

CMD ["uvicorn", "server:app", "--host", "0.0.0.0", "--port", "8000"]

Two rules matter here. Keep secrets out of the image; inject the OpenAI key as an environment variable at runtime. And install dependencies in their own layer so rebuilds are fast. With a container in hand, the deployment target becomes a genuine choice rather than a rewrite. You can build and run it locally to confirm before pushing anywhere:

docker build -t my-langchain-agent .
docker run -p 8000:8000 -e OPENAI_API_KEY=$OPENAI_API_KEY my-langchain-agent

docker build -t my-langchain-agent .
docker run -p 8000:8000 -e OPENAI_API_KEY=$OPENAI_API_KEY my-langchain-agent

Hosting Options Compared

Now the real decision. Here is how the common targets stack up against the criteria that decide whether a long-running LangChain agent is happy.

Why serverless fights stateful agents

Serverless functions like AWS Lambda are built for short, stateless, request-and-done work. A LangChain agent frequently violates all three assumptions. Agents can run for minutes on a multi-step chain, and Lambda enforces a hard timeout (15 minutes) that a long tool-using loop can blow past. Agents accumulate state in memory and on disk during a task, and each Lambda invocation may land on a fresh, empty environment, so anything you cached is gone. Cold starts add latency at exactly the wrong moment. You can force agents into serverless with external state stores and careful chunking, but you are fighting the model. Serverless shines for a thin stateless endpoint in front of an agent, not for the agent itself.

Why containers and Kubernetes fit better

A long-running, stateful agent wants a process that stays up and a disk that persists. Containers give you the first. Kubernetes gives you both plus self-healing (it restarts a crashed pod), persistent volumes (state that survives a restart), horizontal scaling, and network policy to isolate one agent from another. That maps almost exactly onto what a production LangChain agent needs: keep the /workspace between runs, come back up automatically after a crash, and never let one tenant reach another's data. The tradeoff is operational weight. Running Kubernetes yourself means owning upgrades, networking, storage classes, and security patches.

There is a subtler reason containers win for agents. LangChain agents often shell out: they run generated code, call CLI tools, write scratch files, or clone a repo to work in. A container gives that behavior a real filesystem and a predictable environment, so the tool the agent expects is actually present. Serverless environments are read-only in most places except a small temporary directory that is wiped between invocations, which quietly breaks any agent that assumed it could keep files around.

Secrets, Observability, and Scaling in Production

Choosing a host is most of the battle, but three operational concerns decide whether the deployment survives its first month.

Secrets. Your OpenAI or Anthropic key is a live billing credential. Never bake it into the image or commit it to the repo. Inject it at runtime through the platform's secret mechanism (environment variables from a secret store, not from your Dockerfile). On Kubernetes that means a Secret object mounted into the pod; on a managed runtime it means the platform's secret manager. Rotate keys on a schedule and scope them as narrowly as the provider allows.

Observability. Agents fail in ways plain application logs do not explain, because the interesting failure is usually "the model chose the wrong tool" or "the retrieval returned junk," not a stack trace. Add tracing so you can see each step: the prompt, the tool calls, the intermediate outputs, the tokens spent. LangChain integrates with tracing tools that record every step of an agent run, which turns a vague "it gave a bad answer" report into a specific line you can fix. Track token spend per request too, because an agent that loops can run up a bill fast.

Scaling. Agents are memory-hungry and can hold a request open for a long time, so the naive "add more replicas" plan needs thought. Set concurrency limits per instance so one long task does not starve others. Use a queue for work that does not need a synchronous response. And put timeouts and spend caps on autonomous loops so a wandering agent cannot run forever. These are the same concerns as any long-running service, sharpened by the fact that each request can be slow and expensive.

Matching the Option to Your Agent

The right target follows from three questions about your specific agent.

• How long does a single task run? Seconds favor almost anything, including serverless. Minutes or open-ended loops rule serverless out and point to containers or Kubernetes.

• Does it accumulate state that must survive a restart? If the agent writes files, caches embeddings, or keeps a working directory it must not lose, you need persistent storage, which means a VPS you manage, Kubernetes, or a managed runtime, not stateless serverless.

• How many agents, and how isolated must they be? One internal agent is happy on a container platform. Many agents, or multi-tenant with strict isolation, is Kubernetes territory.

A useful default: for a single stateless-ish agent, a container platform like Railway or Render is the fastest good answer. For long-running stateful agents, especially several of them with isolation requirements, Kubernetes is the right engine, and the only real question is whether you operate it yourself. For a lighter personal setup, the guide on how to deploy a personal AI agent covers the small-scale path.

Where a Managed Runtime Fits

If your LangChain agent is long-running and stateful, must keep its /workspace across restarts and redeploys, and needs to stay isolated from other agents, Kubernetes is the right foundation but a heavy thing to operate. A managed agent runtime closes part of that gap, with one honest boundary: Sokko doesn't host your custom LangChain container. It deploys one of four ready-made agent runtimes (OpenClaw, Hermes, Paperclip, OpenSRE) from the dashboard in a couple of clicks, on infrastructure managed for you, with saved files that survive restarts, automatic restart-on-crash, team roles for owner, admin, and dev, and every agent walled off in its own private space. You bring your own model keys or use Sokko credits. If what you actually need is an always-on assistant, that replaces the DIY build; if you need your own LangChain code in production, the container you built above belongs on a VPS, a container platform, or Kubernetes that you run.

That is not the answer for every case. A tiny stateless webhook is overserved by a cluster and belongs on serverless or a container platform. A team with a dedicated platform group and high utilization may prefer to run Kubernetes themselves for cost reasons. The point is to match the host to the workload.

The Short Version

To deploy a LangChain agent to production, separate two decisions you might otherwise blur together: how the agent reasons (LangChain, tools, memory) and where it runs (VPS, serverless, containers, Kubernetes, managed runtime). Containerize once, then choose a target from the agent's real behavior. Serverless is a poor host for long-running stateful agents and a fine one for thin stateless endpoints. Containers and Kubernetes fit stateful agents because they keep the process alive and the disk intact. And if you want the Kubernetes result without the Kubernetes operations, a managed runtime closes the gap. To see how the broader ecosystem of frameworks stacks up before you commit, the roundup of open source AI agents is the companion piece to this one.