The best MCP server hosting platforms in 2026

The Model Context Protocol went from a specification with a handful of reference servers to the default way tools get attached to models, and the centre of gravity moved with it. The early servers all ran over stdio: your client spawned the server as a subprocess on the same machine, talked to it over pipes, and hosting never entered the conversation. The interesting servers now run somewhere else, over HTTP, serving many users at once — and that is a hosting problem with some genuinely unusual properties.

This guide is about those properties first and the platforms second, because the platforms are easy to compare once you know what you are comparing them on. If you have deployed a stateless JSON API before, at least two of the three things below will surprise you.

What a remote MCP server actually needs

Start with the transport. The current remote transport is Streamable HTTP: one endpoint, usually something like /mcp, where the client POSTs JSON-RPC messages and the server may answer either with a plain JSON body or by upgrading that response into a Server-Sent Events stream. The server can also push messages down a separate long-lived GET stream. The older HTTP+SSE transport, with its split endpoint pair, is deprecated but still deployed widely enough that many servers speak both.

Both shapes mean the same thing for hosting: you need an origin that can hold a response open for minutes and forward bytes as they are produced. Any layer in the path that buffers a response body until it is complete converts your stream into a very slow single reply. This is the single most common way a working MCP server appears broken in production.

# Does your host stream, or does it buffer? Ask before you debug for a day.
curl -N -i \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' \
  https://your-server.example.com/mcp

# Streaming host:  headers arrive, then "event:" lines trickle in.
# Buffering proxy: nothing at all until the handler finishes, then
#                  the entire body lands at once.

Second, sessions. The protocol has an initialize handshake, and a server that wants continuity across requests issues an Mcp-Session-Id header the client echoes back. If you keep that session in process memory — which is what every quickstart does — then every request in a session must reach the same process. On a single long-lived server that is free. Behind a load balancer that round-robins, it is a bug that appears only under load. On a function platform where each invocation may be a fresh instance, it is a bug that appears immediately, and the fix is either sticky routing or moving session state into Redis or a database.

Third, and most people underrate this: what the tools do. An MCP server that reads from your own read-only database is a normal web service. An MCP server whose tools run code, execute shell commands, clone repositories, or open a browser is a multi-tenant execution platform, and the model on the other end is choosing the arguments. That is not a threat model a normal app host is built for, and it changes which of the options below are actually viable.

Authorization is part of the hosting decision

MCP's authorization story is built on OAuth 2.1: the server behaves as a protected resource, advertises its authorization server through metadata, and rejects unauthenticated requests with a 401 that tells the client where to go. Clients discover the rest and run the flow themselves.

Two consequences for hosting. Your server needs a stable public HTTPS origin, because that origin is baked into the metadata and into whatever the user registered. And the platform's own auth layer must not sit in front of the endpoint — a host that puts a login page or an access-token gate in front of every route will block the discovery request that makes the flow work. Check that you can expose a specific path unauthenticated before you commit.

The platforms

• Cloudflare Workers — The most opinionated and, for a stateless-ish server, the most convenient: an official agents SDK, Durable Objects to hang session state on, and OAuth helpers. You commit to the Workers runtime, which is Web-standard rather than Node, so libraries that assume a filesystem or raw TCP need alternatives. Excellent if your tools call APIs; awkward if your tools need a machine.
• Vercel — Good developer experience and a well-trodden MCP adapter path in Next.js apps. Server routes are functions, so read the session section again and check the maximum duration against your slowest tool call. Fine for API-shaped tools, wrong for tools that hold a resource open.
• Fly.io — An ordinary long-lived process on a real VM, close to your users, with streams and sessions behaving exactly as they do on your laptop. A very sane default for a stateful server.
• Render — Build command, start command, a persistent web service, managed Postgres alongside. The least surprising way to host a Node or Python MCP server that keeps state in process.
• Railway — Fastest git-to-URL for an MCP server with a database attached, with per-branch environments that make protocol changes safe to test.
• AWS Lambda with response streaming — Viable now that streaming responses exist, and attractive if you are already deep in AWS. You are still on a function platform, so sessions belong in DynamoDB or ElastiCache, not in a module-level Map.
• A VPS behind Caddy or nginx — Cheapest, most control, and the place people most often lose streaming to a default proxy buffer. Turn buffering off explicitly and set a generous read timeout.
• PandaStack — Git-driven with no Dockerfile: it detects the build, starts your server, injects PORT and HOST, and gives the app a stable HTTPS host for the OAuth metadata. Each app is a Firecracker microVM with its own kernel, so a tool that shells out, writes files, or spawns a browser is contained by a hypervisor boundary rather than a shared kernel. Scale-to-zero is snapshot restore, so a low-traffic server can sleep without paying a container cold start on the next call. Best when your tools execute things; less compelling if your server is a thin proxy over an API you already host elsewhere.

If your tools run code, host them differently

A run_code or run_shell tool is the whole reason many MCP servers exist, and it inverts the security model. The arguments are generated by a model that may be reading untrusted content — a web page, a document, an email — which means prompt injection reaches your tool arguments directly. Assume the input is hostile, because sometimes it is.

The practical answer is to separate the two jobs: a small, boring server that speaks the protocol and holds sessions, and a disposable environment per execution that the server drives over an API. The server never runs the code itself. If the environment is destroyed after the call, the blast radius of a malicious argument is one throwaway machine.

// The MCP server stays boring. Execution happens somewhere disposable.
import { Sandbox } from "@pandastack/sdk";

server.tool(
  "run_python",
  { code: z.string() },
  async ({ code }) => {
    await using sb = await Sandbox.create({
      template: "code-interpreter",
      ttlSeconds: 120,
    });
    const out = await sb.runCode(code, "python");
    return { content: [{ type: "text", text: out.stdout || out.stderr }] };
  },
);

// The sandbox is gone before the tool call returns. Nothing the model
// generated ever touched the process serving the protocol.

Pick by situation

• Stateless tools that call APIs you already have → Cloudflare Workers or Vercel. Low latency, low operational surface, no session problem to solve.
• Stateful sessions in process memory → a long-running server: Fly.io, Render, Railway, or PandaStack. Do not fight a function platform for this.
• Tools that execute code, run shells, or drive browsers → a host with per-workload isolation, and a disposable environment per call regardless of host.
• Internal server, small team, on your own infrastructure → a VPS behind a proxy, with buffering turned off and a long read timeout.
• You need OAuth and a stable public origin → anything with a real custom domain and the ability to leave a path unauthenticated. Check that second one early.

The short version

Decide whether your server is stateful before you pick a platform, because that single answer eliminates most of the list. Stateless servers are happy on functions and at the edge. Stateful ones want a process that stays alive, and every workaround for that on a function platform is more work than moving.

Then verify streaming with curl on the real deployed URL — not locally, where there is no proxy — and confirm your platform lets you expose an unauthenticated discovery path. Those two checks take ten minutes and prevent the two failures that are hardest to diagnose after the fact.