Where to deploy LangChain agents in production.Without paying AWS prices or hitting Vercel timeouts.

What a LangChain agent actually needs in production

A LangChain agent in development is a Python script. In production it is an HTTP service that must stay alive, handle concurrent users, store conversation history, manage secrets securely, and respond in 30-90 seconds without timing out.

That checklist rules out several hosting choices:

• xServerless platforms with 5-10 second execution limits. Most LangChain tool call chains exceed this.
• xPlatforms that restart containers on every request. Conversation memory requires a persistent process or an external database.
• xPlatforms that charge per-invocation fees. A chatbot handling 1,000 daily conversations makes many invocations per session, and the costs stack fast.

What works:

• +A long-running container that stays alive between requests.
• +A Postgres database for conversation history, task state, and user data.
• +Secure secret injection for your model API keys.
• +Usage-based compute billing so idle time does not cost you.

Deploying a LangChain agent on Varity

Varity is designed for exactly this use case. The platform's intelligent orchestration algorithm auto-detects Python projects, provisions and connects the database, and deploys the container with your secrets injected. The deploy command is:

npx varity@latest init
varity deploy

Output:

Detecting framework: Python / FastAPI
Configuring compute...   done
Configuring database...  done
Injecting secrets...     done
Deploying...

Live at https://varity.app/your-agent/

Your agent is now reachable at a public HTTPS endpoint. The container stays alive. Concurrent requests are handled. No configuration files were written beyond your application code.

Persisting conversation memory

LangChain supports multiple memory backends. On Varity, the recommended approach is PostgresChatMessageHistory, which stores conversation turns in the Postgres database Varity provisioned automatically.

from langchain_community.chat_message_histories import (
    PostgresChatMessageHistory,
)
import os

history = PostgresChatMessageHistory(
    connection_string=os.environ["DATABASE_URL"],
    session_id=session_id,
)

# Use history in your chain
chain = ConversationChain(
    llm=llm,
    memory=ConversationBufferMemory(
        chat_memory=history
    ),
)

DATABASE_URL is already in your environment because Varity injected it at deploy time. You do not create a database account or write a connection string.

Managing API keys securely

LangChain agents need API keys for model providers. These should never be committed to your repo or hardcoded in your deployment config.

In the Varity developer portal, go to your app and add your environment variables: OPENAI_API_KEY, ANTHROPIC_API_KEY, or whatever model provider you are using. They are encrypted at rest and injected into your container at deploy time. Your Python code reads them the same way it does in local development:

import os
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    api_key=os.environ["OPENAI_API_KEY"],
    model="gpt-4o",
)

Cost comparison for LangChain hosting

A typical LangChain agent in production: Python FastAPI backend, Postgres for conversation history, 1,000 daily conversations at 5 turns each.

Estimates. Model API costs are roughly the same regardless of platform and are not included. See varity.so/pricing for current per-second rates.

Varity is 60-80% cheaper than AWS for this workload because database and auth are included, compute is billed by the second, and there are no per-invocation fees.

LangGraph and multi-agent workflows

LangGraph agents have the same hosting requirements as LangChain but with additional state management. Graph state needs to persist across tool calls within a single run and across multiple runs for a user session.

Varity handles this the same way: the Postgres database stores graph state, and the long-running container keeps your agent process alive through multi-step tool chains that exceed serverless timeouts.

For multi-agent setups where one agent spawns subtasks for other agents, Varity's compute scales with the workload on a per-second basis. You are not pre-allocating capacity for peak load that only hits once a day.

Getting your LangChain agent live

If your agent is a FastAPI or Flask app, the deploy is two commands:

npx varity@latest init
varity deploy

Then add your model API keys in the developer portal. The agent is live, the database is running, and your keys are injected. No cloud console, no configuration files, no infrastructure knowledge required.

See the broader AI agent hosting guide for a full breakdown of what Varity auto-configures for AI workloads.