# How to Deploy a LangChain App to Production in 2026

> Deploy a LangChain application from GitHub with Kuberns. Configure FastAPI, model keys, RAG, streaming, persistent state, health checks, and production logs.
- **Author**: jaikishan-singh-rajawat
- **Published**: 2026-05-05
- **Modified**: 2026-10-05
- **Category**: Deployment Guides
- **URL**: https://kuberns.com/blogs/deploy-langchain-app/

---

The simplest way to deploy a Python LangChain application is to expose it through a production web API, push the project to GitHub, and connect the repository to Kuberns. Kuberns analyzes the source, proposes the Python runtime and deployment configuration, and turns the approved configuration into a live HTTPS service without requiring you to begin with a VPS or a hand-written deployment pipeline.

Deployment still involves more than making the endpoint reachable. A production LangChain app must protect model-provider credentials, validate requests, handle slow or streaming responses, persist any state that must survive a restart, and expose enough logs and health information to diagnose failures.

This guide covers the complete GitHub-to-production workflow, what Kuberns automates, what remains the developer's responsibility, and how to verify a chain, RAG API, or stateful agent after deployment.

**TL;DR**

- Expose the LangChain application through FastAPI or another production HTTP server.
- Commit the application, dependency or lock files, and a lightweight health endpoint to GitHub.
- Keep model keys, database connections, vector-store credentials, and tracing settings outside the repository.
- Connect the repository to Kuberns and review the runtime, process, port, variables, and resources detected by the Agentic AI.
- Deploy, then test the health route, inference endpoint, streaming behavior, persistence, and runtime logs.
- Use durable PostgreSQL or Redis storage for agent state that must survive restarts or multiple replicas.

## What a LangChain App Needs Before Production

LangChain is an application framework, not a public web server. A Python chain or agent needs an HTTP layer before a browser, frontend, or another service can call it. FastAPI is a practical choice because it supports typed request validation, asynchronous handlers, streaming responses, and generated API documentation.

A deployable repository should contain:

- **An API entry point:** Expose only the routes clients need and validate their inputs with Pydantic models.
- **A production server dependency:** Include an ASGI server such as Uvicorn. Do not use a local development server or the `--reload` flag in production.
- **A reproducible dependency set:** Commit `requirements.txt`, `uv.lock`, `poetry.lock`, or another lock file containing versions you have tested together.
- **A lightweight health route:** Return a simple success response without calling a model or rebuilding an embedding index.
- **Externalized configuration:** Read model names, provider keys, database URLs, tracing settings, and application secrets from the environment.
- **A persistence plan:** Use durable storage when conversations, checkpoints, scheduled work, or user state must survive restarts.

Here is a minimal FastAPI shape for a stateless LangChain endpoint:

```python
import os

from fastapi import FastAPI
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI
from pydantic import BaseModel, Field

app = FastAPI()

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a helpful assistant."),
    ("user", "{question}"),
])

model = ChatOpenAI(
    model=os.environ["MODEL_NAME"],
    api_key=os.environ["OPENAI_API_KEY"],
)

chain = prompt | model | StrOutputParser()

class QueryRequest(BaseModel):
    question: str = Field(min_length=1, max_length=4000)

@app.post("/ask")
async def ask(request: QueryRequest):
    answer = await chain.ainvoke({"question": request.question})
    return {"answer": answer}

@app.get("/health")
async def health():
    return {"status": "ok"}
```

Add the packages the application actually imports and lock the versions after testing. A basic example may include `fastapi`, `uvicorn[standard]`, `langchain`, and the integration package for the selected model provider. Do not copy unbounded version ranges into production without checking compatibility.

The app must also run on the interface and port provided by its environment. A typical process command is:

```bash
uvicorn main:app --host 0.0.0.0 --port $PORT
```

Kuberns can detect the application and propose its process configuration for a supported repository. Add a custom command only when the project structure or runtime behavior cannot be inferred correctly.

> If the repository contains a broader Python service, the [Python deployment guide](https://kuberns.com/blogs/how-to-deploy-python-app-with-ai/) explains dependency files, production servers, ports, and framework detection in more detail.

## The Best Way to Deploy a LangChain App Is on Kuberns

![Kuberns Agentic AI platform for deploying LangChain applications](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/kuberns-home-page-new.png)

[Kuberns](https://kuberns.com/) is an Agentic AI platform for deployment. Its agent-first workflow examines a connected repository and proposes the framework, runtime, application root, dependency files, build process, start process, web port, environment-variable names, and resource categories it finds. You review that result before the platform builds and deploys the service.

### Step 1: Push the application to GitHub

Commit the API code, tested dependency or lock files, health route, and any database migrations. Keep `.env`, provider keys, service credentials, local vector indexes, and generated data out of source control. Before pushing, run the application with production-like settings and confirm that the health and inference routes work locally.

### Step 2: Connect the repository to Kuberns

![Connect a LangChain GitHub repository to Kuberns](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/kuberns-registration.png)

Create a service, connect GitHub, and choose the repository and branch that should represent production. If the repository contains multiple applications, confirm that the detected application root points to the LangChain API.

### Step 3: Review the detected configuration

![Kuberns Agentic AI analyzing a LangChain repository](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/agent-deployment-process.png)

Review the Python runtime, dependency file, API entry point, build process, start process, web port, environment-variable names, and proposed resources. Repository analysis reduces manual setup, but it does not replace this approval step. Correct an incorrect project root or process command before deploying.

### Step 4: Add environment values and resources

![Configure LangChain environment variables on Kuberns](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/environment-variable-kuberns.png)

The repository may reveal which variable names the application expects, but secret values must come from you.

| Variable category | Examples | Why it is needed |
|---|---|---|
| Model provider | `OPENAI_API_KEY`, `ANTHROPIC_API_KEY` | Authenticates calls to the selected provider |
| Model configuration | `MODEL_NAME` | Keeps model selection outside the code |
| Persistence | `DATABASE_URL`, `REDIS_URL` | Stores application data, threads, or checkpoints |
| Retrieval | Vector-store URL and credentials | Connects a RAG application to its external index |
| Observability | LangSmith or another tracing configuration | Records chain and agent execution where enabled |
| Application security | Authentication and signing secrets | Protects the public API and user sessions |

Add PostgreSQL, Redis, or another required resource only when the application architecture needs it. Kuberns handles the accepted infrastructure configuration, while your code remains responsible for schemas, migrations, authorization, and safe data access.

### Step 5: Deploy and inspect the logs

Approve the configuration and start the deployment. Watch the build logs for dependency and import failures, then inspect service logs to confirm that the web process starts and continues running.

![LangChain application deployment dashboard on Kuberns](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/deployed-dashboard.png)

Open the generated HTTPS endpoint and test it with a real request:

```bash
curl -X POST "https://your-app.example/ask" \
  -H "Content-Type: application/json" \
  -d '{"question":"What is LangChain?"}'
```

A successful build is not enough. The API must start, remain healthy, reach its model and data providers, and return a valid response.

> Once the production branch is connected, the guide to [automatically deploying an app from GitHub](https://kuberns.com/blogs/how-to-auto-deploy-your-apps-from-github-in-one-click/) explains how later repository updates move through a repeatable deployment workflow.

## Configure Models, State, RAG, and Streaming

Kuberns can prepare and run the approved deployment environment, but production behavior still comes from the application.

| Workload | Application responsibility | Deployment consideration |
|---|---|---|
| Stateless chain | Validate input and enforce provider limits | Request duration, retries, and provider failures |
| Streaming chat | Emit an async stream and handle disconnects | Long-lived connections and proxy timeouts |
| Stateful agent | Associate threads with authenticated users | Durable checkpoints and shared storage |
| RAG application | Maintain document ingestion and retrieval logic | External vector storage and background ingestion |
| Tool-using agent | Restrict tools and validate tool inputs | Least-privilege credentials, timeouts, and audit logs |

### Keep state outside the web process

In-memory history is acceptable for a local demonstration, but it disappears when the process restarts and is not shared across replicas. Store conversation history, LangGraph checkpoints, or application state in a durable system such as PostgreSQL or Redis when continuity matters.

LangChain's current [deployment cookbook](https://github.com/langchain-ai/deployment-cookbook) likewise separates the agent runtime, protocol server, run management, and persistent checkpoints. That distinction becomes important as soon as an application has concurrent users or resumable work.

### Treat RAG ingestion as separate work

Do not rebuild an embedding index inside every API request or application startup. Keep the vector database external, initialize reusable clients outside request handlers, and move large document-ingestion jobs to a controlled background process. PostgreSQL with pgvector and managed vector databases are both valid choices when they fit the retrieval design.

### Stream deliberately

FastAPI can stream model output, but the application must handle client disconnects, provider errors, timeouts, and partial results. Test streaming through the public endpoint rather than assuming behavior observed on localhost will remain identical behind a production proxy.

### Protect the public API

Add authentication, authorization, input-size limits, rate or usage controls, and per-provider timeouts before exposing an endpoint publicly. Do not let user input select arbitrary tools, indexes, tenants, or system prompts without validation.

For LangGraph, distinguish between a custom FastAPI service that imports LangGraph and a dedicated agent runtime. Stateful agents may need durable execution, checkpoints, resumable runs, and concurrency controls that a stateless API does not provide.

## Verify and Troubleshoot the Production Deployment

Run these checks before directing users or another service to the deployed application:

- The health endpoint returns HTTP 200 without calling a model provider.
- A valid inference request returns the expected response shape.
- Invalid and oversized inputs are rejected clearly.
- Missing credentials produce a useful error without exposing secret values.
- Streaming responses complete through the public HTTPS endpoint.
- Required conversation or agent state survives a restart.
- Database and vector-store connections recover from temporary failures.
- Traces and runtime logs provide enough context to diagnose a failed run.
- A new commit moves through the deployment pipeline and leaves the service healthy.

### The build succeeds but the service does not start

Check the service logs for an incorrect module path, missing server dependency, missing environment value, or process that listens only on localhost. Confirm that the process binds to `0.0.0.0` and the configured platform port.

### Model requests time out

Confirm the model provider is reachable and inspect the time spent in retrieval, tool calls, and model generation. Use explicit timeouts and controlled retries. Streaming can improve perceived responsiveness, but it does not fix an unbounded agent loop or a blocked dependency.

### State disappears after deployment or scaling

The application is probably keeping history or checkpoints in process memory. Move required state to PostgreSQL, Redis, or another shared durable store and identify records by authenticated user and thread identifiers.

### RAG consumes too much memory

Do not load a large local index into every web-process replica. Use an external vector database or a persistent datastore designed for the retrieval workload, and reuse clients rather than recreating them for each request.

### An old guide recommends LangServe

LangServe was deprecated in November 2024. Its maintainers recommend LangGraph Platform for new projects. Existing LangServe applications can still be maintained, but new projects should use a current FastAPI architecture or the current LangGraph deployment path that fits their state and runtime requirements. See the official [LangServe deprecation notice](https://github.com/langchain-ai/langserve).

> For the API layer itself, the [FastAPI deployment guide](https://kuberns.com/blogs/post/fastapi-deployment-guide/) covers application detection, production processes, environment variables, and runtime troubleshooting.

## Conclusion

A LangChain application reaches production when its chain or agent is exposed through a reliable API, its configuration and credentials stay outside the repository, and any required state is stored somewhere durable. The hosting layer cannot replace authentication, input validation, model controls, persistence, or application testing.

Kuberns provides the managed GitHub-to-production path. Connect the repository, review what the Agentic AI detected, supply the values and resources the application needs, approve the deployment, and verify the live service through its endpoint and logs.

Plans start at $7. A Trial Option is available, and bundle packs provide additional savings. Check the current [Kuberns pricing](https://kuberns.com/pricing) before selecting resources.

<a href="https://dashboard.kuberns.com" target="_blank" rel="noopener noreferrer">
  <img src="https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/deploy-on-kuberns-bannner9.png" alt="Deploy a LangChain app from GitHub on Kuberns" style={{ width: "100%", height: "auto" }} />
</a>

## Frequently Asked Questions

### What is the easiest way to deploy a LangChain app?

For a Python LangChain application in GitHub, Kuberns provides a managed path to production. Connect the repository, review the runtime and process configuration detected by the Agentic AI, add the required secrets, approve the deployment, and verify the live API.

### Where can I host a LangChain application?

A LangChain application can run on a managed deployment platform such as Kuberns, a general PaaS, a container service, or a VPS. Choose a persistent runtime that supports the application's request duration, streaming, state, databases, and observability requirements.

### Do I need Docker to deploy LangChain?

A Dockerfile is not required when Kuberns can detect and configure the Python web application from its repository. Docker remains an option when the application needs system packages or runtime behavior that cannot be inferred safely.

### How do I deploy LangChain with FastAPI?

Expose the LangChain logic through validated FastAPI routes, include a production ASGI server in the dependency set, add a lightweight health endpoint, bind the server to the platform port, and deploy the repository with its environment values.

### How should a LangChain app store conversation state?

Do not rely on process memory when state must survive restarts or multiple replicas. Store conversation or agent checkpoints in a durable system such as PostgreSQL or Redis and associate records with authenticated users or thread identifiers.

### Can I deploy a LangChain RAG app with PostgreSQL or a vector database?

Yes. Keep the retrieval service external to the web process, provide its connection details through environment variables, initialize reusable clients outside request handlers, and test connectivity after deployment. PostgreSQL with pgvector and managed vector databases are common options.

### Is LangServe still recommended for new LangChain applications?

No. The LangServe project is deprecated and recommends LangGraph Platform for new projects. Existing LangServe applications can still be maintained, but a new application should use a current FastAPI architecture or the current LangGraph deployment path that fits its requirements.

### What is the difference between deploying LangChain and LangGraph?

A simple LangChain chain may only need a stateless HTTP API. A LangGraph agent can also require durable checkpoints, thread state, streaming, resumable runs, and concurrency controls. Those requirements must be designed into the application before choosing its deployment configuration.

---
- [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/)
- [All articles](https://kuberns.com/blogs/)