You have a LangChain agent that works. It answers well in the notebook, the tool calls land, the LangGraph checkpoints do what they are supposed to. Then someone asks the obvious question: "Can I use it?" And suddenly the agent is not the problem anymore. Hosting is.

This post is the hosting half. It assumes the agent already exists and walks through getting it onto Server4Agent, where it runs as a long-lived process with persistent files, its own secrets, readable logs, and a stable URL that stays private until you say otherwise. If you have not wrapped the agent in an HTTP app yet, do that first with how to deploy a LangChain agent as a server. If you are still deciding whether this is the right kind of host at all, best servers for LangChain agents in 2026 makes the comparison. This one is for when you have decided and want the steps.

Quick answer

To host a LangChain agent on Server4Agent, create a server, create a project on it seeded from your agent's git repository, and let the on-server agent install dependencies, start the process, and confirm it answers. Set your model provider key and tool credentials as secrets before the first run, keep LangGraph checkpoints on a path inside the project workspace so they survive restarts, read the process logs when something misbehaves, and flip the project to public (or team-only) when you are ready. Every one of those steps is a tool call over MCP from the assistant you already use, and most of them are also a few lines of Python with the SDK.

Key takeaways

A LangChain agent is a long-running, stateful process. It needs a server, not a function, and it needs files that do not vanish between requests.
On Server4Agent the unit of hosting is a project inside a server. The project owns the workspace, the process, the logs, and the URL.
Seed the project from git and bring-up does the install, the start, and the health check for you, pausing to ask when it is unsure how the code runs.
Secrets are write-only environment variables bound to a server or a project. Your model key never lives in the repo.
Checkpoints, vector indexes, and cached files belong inside the workspace. They persist across restarts and redeploys.
The URL exists from day one and serves nothing until you choose public or team access. Reviewing before publishing is the default, not a discipline you have to remember.

What you need before you start

Three things, none of them exotic.

An agent behind HTTP. A FastAPI (or similar) app that builds the agent once at startup and exposes an invoke endpoint, a streaming endpoint, and a health check. The deploy guide has the full shape; the important parts are the health endpoint and reading configuration from environment variables.
A repository. Bring-up works best when it can clone your code. A private repo is fine; you store a clone token as a secret first and name it when you create the project.
A Server4Agent account with either an MCP-compatible assistant connected or an API key for the SDK. The quickstart covers both, and the integrations page lists the chat and IDE clients you can connect over MCP.

For the walkthrough I will use a real-shaped example: a support triage agent for a small hardware company, Pinegrove Robotics. It is a LangGraph graph with three tools (search the docs, look up an order, draft a reply), a SQLite checkpointer for conversation threads, and a FastAPI wrapper. It lives in a private GitHub repo. The goal is a URL the support team can point their helpdesk webhook at.

The shape of a hosted agent

It helps to hold the model in your head before making the first call, because it explains why the steps are what they are.

A server is a sized compute box (small, medium, or large) that you own. Files on it persist. Processes on it stay up. It can hold several projects.

A project is one app inside a server: its own folder in the workspace, its own process, its own logs, its own slug and URL. The triage agent is one project. If you later add a second agent, or a dashboard that reads the first one's checkpoints, that is another project on the same server, and the two can see each other's files if you let them.

A URL is minted when the project is created and never changes. Visibility decides whether it serves traffic, and access decides who may open it: anyone with the link, or only signed-in members of your team. That is the whole publishing model, and it is private by default for a reason.

Path 1: from the assistant you already use

This is the path most people take, because it means never leaving the chat window or the IDE where the agent was written. Connect Server4Agent over MCP once (the endpoint is https://mcp.server4agent.com, authorized with OAuth), and the hosting operations show up as tools your assistant can call. You describe what you want; it makes the calls.

The instruction that started the Pinegrove deployment was one paragraph:

"Create a small server called support-triage. Create a project on it from github.com/pinegrove/triage-agent, private, with MODEL_API_KEY and HELPDESK_TOKEN as secrets (I will paste them). Bring it up, confirm /health answers, then give me the URL and the last fifty lines of the log."

Underneath, that turns into a short sequence of tool calls. Knowing what they are makes the assistant's progress notes legible and lets you steer when something goes sideways.

Step 1: create the server

The create_server tool takes a tier and, optionally, a list of server-wide secrets. Server-wide is right for a model provider key that every project on the box will use. Small is plenty for an agent that calls a hosted model; the server is coordinating network calls, not crunching numbers.

Step 2: create the project from your repo

The create_project tool accepts a source describing where the code comes from. For a git repository that is the URL, an optional ref, and the name of a secret holding a clone token if the repo is private. Project-scoped secrets go in the same call. In the assistant's hands the arguments look like this:

json

{
  "server_id": "srv_…",
  "source": {
    "kind": "git",
    "git_url": "https://github.com/pinegrove/triage-agent",
    "ref": "main",
    "auth_secret": "GITHUB_CLONE_TOKEN"
  },
  "secrets": [
    { "key": "HELPDESK_TOKEN", "value": "…", "description": "Helpdesk API, read and reply" }
  ]
}

Projects default to private and persistent, which is what you want for an agent that is supposed to keep running. The name is derived from the repo when you leave it out.

Step 3: bring it up

Creating a project from a source starts bring-up automatically: fetch the code, install dependencies, start the app, confirm it responds. You can also kick it off or resume it explicitly with init_project. Two pauses are worth knowing about, because they are where the assistant will come back to you.

The first is the run plan. On the first bring-up the on-server agent reads the code, works out how it runs, and stops to confirm before executing anything. For the triage agent that came back as: stack "Python 3.12 / FastAPI", install pip install -r requirements.txt, start uvicorn app:app --host 0.0.0.0 --port 8000, port 8000, env MODEL_API_KEY, HELPDESK_TOKEN, CHECKPOINT_DB. If it guessed wrong, say so in plain words ("the start command is python -m triage.serve") and the plan is corrected. The plan is stored on the project, so the next bring-up does not ask again.

The second pause is missing secrets. Bring-up discovers the environment variables the code reads and stops if one it thinks is required is unset. CHECKPOINT_DB was optional in our code (it has a default), so the answer was to continue with proceed: true. A genuinely missing key is fixed with set_secret and attach_secret, then resume.

Step 4: check it, then keep checking it

get_run reports where bring-up is, what the agent's latest progress note says, and what changed in the workspace. get_logs returns the tail of every log file the project's processes have written. Each long-running process appends to its own file under .server4agent/ in the project folder, so the uvicorn output is right there, and so is the output of any background worker you start later.

This is the loop that makes hosting an agent on an agent-native server different from hosting it on a box you SSH into. When the first health check failed for Pinegrove, the assistant read the log, saw a missing langgraph-checkpoint-sqlite dependency that had never made it into requirements, added it, reinstalled, and restarted. Nobody opened a terminal. If you would rather do it yourself, exec runs a shell command inside the project folder, and prompt sends a follow-up to the on-server agent scoped to that project ("add request logging with the thread id and tool name on every tool call").

Step 5: make the state durable

The SQLite checkpointer in the triage agent points at ./data/checkpoints.sqlite, and the data/ directory is inside the project workspace. That is the entire persistence story: project files persist across process restarts, server restarts, and redeploys, so the conversation threads the helpdesk started on Monday are still there on Friday. The same applies to a vector index you build on first boot, a cache of fetched documents, or anything else you would rather not recompute. If it is worth keeping, write it inside the workspace. This is the practical form of the argument in why AI agents need persistent workspaces.

Step 6: go live

Until now the URL has been private: it exists, it is stable, and it serves nothing to the outside. update_project with visibility: "public" turns it on. For an internal agent, add access: "team" so only signed-in members of your account can open it; the helpdesk webhook for Pinegrove used a public URL with the endpoint itself checking a shared token, which is the usual pattern for machine-to-machine callers.

Before flipping the switch, hit the streaming endpoint through the URL and watch tokens arrive as they are produced rather than all at once at the end. That is a thirty second check that saves a confusing bug report later.

Path 2: from Python

Sometimes the thing doing the hosting is not an assistant but a script: a CI job that stands up a fresh copy of the agent per branch, a backend that provisions one per customer, a notebook where you are trying something. The Python SDK wraps the same operations behind typed methods.

python

from pathlib import Path
from server4agent import Server4Agent

client = Server4Agent()  # reads SERVER4AGENT_API_KEY

server = client.servers.create(task="support-triage", tier="small")

# Push the agent's files into the workspace.
for path in ["app.py", "graph.py", "tools.py", "requirements.txt"]:
    server.files.write(f"triage/{path}", Path(path).read_text())

server.exec("cd triage && pip install -r requirements.txt")

# Hand the on-server agent the operational goal and wait for it.
task = server.tasks.create(
    "In ./triage, start `uvicorn app:app --host 0.0.0.0 --port 8000` as a "
    "long-running process, wait for GET /health to return 200, and report "
    "the last 20 log lines."
).wait()
print(task.status, task.result)

Two honest caveats. Secrets are not in the Python SDK yet, so set them in the dashboard or over MCP before the task runs; the process inherits them as environment variables. And a task that stops to ask a question (an unclear start command, a missing key) surfaces as an awaiting-input state rather than a failure, which the SDK's await_input.py example shows how to handle. For a repo that already builds cleanly, the MCP path with a git source is less code than this, because bring-up does the install and start for you.

Bonus: let the hosted agent provision servers itself

There is a second integration hiding here, and for some teams it is the more interesting one. Through langchain-mcp-adapters, a LangChain agent can consume any MCP server as a set of tools. Point your hosted agent at the Server4Agent endpoint with an API key and it gains the hosting operations as tools of its own.

python

import os
from langchain_mcp_adapters.client import MultiServerMCPClient

mcp = MultiServerMCPClient({
    "server4agent": {
        "url": "https://mcp.server4agent.com",
        "transport": "streamable_http",
        "headers": {"Authorization": f"Bearer {os.environ['SERVER4AGENT_API_KEY']}"},
    }
})
tools = await mcp.get_tools()   # create_server, create_project, prompt, deploy, ...

Add those tools to the graph and the triage agent can do things like stand up a private status page for an incident it noticed, or spin up a one-off ephemeral project to run an analysis and clean it up afterwards. The agent is hosted on a server, and it can host things. Scope the API key to the servers it should be allowed to touch, and set a budget cap so an enthusiastic loop cannot become a surprise.

What this costs to run

An agent that mostly waits on a model API is a cheap tenant. Small tier, one process, files measured in megabytes. Where cost shows up is in agent runs, the on-server work that bring-up, follow-up prompts, and structured builds do on your behalf, and that is metered against your plan's credits with a cap you set. The get_usage tool (and the dashboard) shows spend against budget, and dispatch simply refuses once a ceiling is reached rather than running past it. The pricing model is laid out in compute pricing, credits, and budget caps.

Common mistakes

Checkpoints outside the workspace. A path under /tmp is not persistent anywhere. Keep state under the project folder.
A health check that lies. If /health returns 200 before the graph is compiled, bring-up declares victory early and the first real request hits a half-built agent. Report agent_ready honestly.
Keys in the repo. Bring-up will happily run a .env you committed, and so will anyone who reads the repo. Use secrets; they are write-only and never returned by any tool.
Skipping the run plan. Reading the proposed start command takes ten seconds and catches the wrong module path, the wrong port, or a missing --host 0.0.0.0 before they cost you a debugging session.
Publishing to test. You do not need the project public to try it. Review on the private URL, then publish the exact same URL.
No tool timeouts. A hanging HTTP call inside a tool holds a run open indefinitely. Set timeouts in the agent, not just in the host.

FAQ

Does this work for LangGraph, or only classic LangChain agents?

Both. A compiled LangGraph graph exposes the same ainvoke and astream interface, so the HTTP wrapper is identical. LangGraph's built-in checkpointing makes the persistent-workspace part more important, not less, because the graph expects its checkpoints to still be there.

Do I need a Dockerfile?

No. Bring-up reads the code and proposes an install and start command; you confirm or correct it. If you already have a Dockerfile it stays useful as a record of how the app runs, but the run plan you confirm is what bring-up actually executes, and nothing requires one.

Can I run more than one agent on a server?

Yes. Each is a project with its own process, logs, and URL. The small tier holds three projects; medium and large hold more. Projects on a server share the machine, and the project_sharing setting decides whether an agent run in one project may read or change the others.

How do teammates call it without making it public?

Set visibility to public and access to team. The URL then requires a Server4Agent sign-in and membership of your account. For a machine caller like a webhook, use a public URL and validate a shared token inside the endpoint.

How is this different from LangGraph Platform or LangServe?

Those are deployment targets shaped around the LangChain ecosystem's own server and assistant abstractions. Server4Agent hosts a plain process: your FastAPI app, your checkpointer, your files, on a box the agent (or you) operates through tools. The tradeoff is fewer built-in framework conveniences in exchange for a general server that also hosts the dashboards, monitors, and internal tools the agent goes on to build. The comparison with the ecosystem's sandbox offering is on the LangChain sandboxes alternative page.

Where do I start?

Get started free, connect the assistant you already use, and paste in a repo. The first bring-up of a straightforward FastAPI agent is a few minutes end to end, most of it waiting on pip.

How to host a LangChain agent on Server4Agent