How to Deploy & Host an MCP Server (2026)

TL;DR + decision snapshot

Hosting an MCP server means two things: switch its transport from stdio (local subprocess) to Streamable HTTP (network-reachable), then run it somewhere that stays up. There are two real paths in July 2026:

• Managed MCP platforms — Manufact (built on the open-source mcp-use SDK) and Prefect Horizon (built by the FastMCP team) turn a git push into a live URL, usually in under a minute, with preview URLs per pull request. Smithery and Glama add a registry on top and can host the compute too.
• DIY on generic infrastructure — package your server in a Dockerfile, deploy it to Cloudflare Workers, Fly.io, or Railway. More setup, full control, no vendor tied to your MCP server specifically.

Skip to the decision table if you already know which trade-off you want, or the managed walkthrough for the fastest path to a working link.

Why host an MCP server at all

A local server is the right default while you’re building — it’s free, it’s private, and restarting it is one keystroke away. Three situations push you past that:

• More than one person needs it. Stdio servers live in one config file on one machine. The moment a teammate wants the same tools, you’re either walking them through a local install or you host one instance and everyone points at the same URL.
• You want it in ChatGPT or Claude’s web app. Browser-based AI clients and their connector ecosystems can only reach servers over HTTP. A process that only exists on your laptop is invisible to them, full stop.
• You want it always-on. A local server dies when you close your laptop or your client restarts. A hosted one keeps running for scheduled jobs, webhooks, or teammates in other timezones.

If none of those apply — it’s just you, in one client, on one machine — stay on stdio. Hosting adds a public attack surface for zero benefit in that case. See what MCP actually is if the client/server split itself is still fuzzy.

Transport reality: stdio vs Streamable HTTP

This is the one line that decides everything else in this guide. Stdio cannot cross a network boundary — it’s a subprocess your client spawns and talks to over standard input/output, on the same machine, full stop. To be reachable by another machine, a server has to speak Streamable HTTP: JSON-RPC over an HTTP POST endpoint, with an optional upgrade to Server-Sent Events for streaming responses. It replaced the older HTTP+SSE transport, which the spec has deprecated.

In FastMCP, the difference is one argument to run():

from fastmcp import FastMCP

mcp = FastMCP("My MCP Server")

@mcp.tool
def greet(name: str) -> str:
    return f"Hello, {name}!"

if __name__ == "__main__":
    mcp.run()  # stdio — local only, the default
    # mcp.run(transport="http", port=8000)  # remote — hostable

That second line is the entire code change. Everything else in this guide — the platforms, the Docker images, the auth — exists to answer one follow-up question: now that it listens on a port, where does that port live so someone else can reach it? For the authorization side of that question specifically, see our OAuth 2.1 for remote MCP servers guide — this post covers where the process runs, not the auth handshake in detail.

Two paths: managed platform or DIY

Once your server speaks Streamable HTTP, you have exactly two categories of place to run it. A managed platform builds and runs the process for you from a repo. A generic PaaS runs any container you hand it — MCP has no special status there.

LOCAL                                    REMOTE
+------------------+     stdio           one URL, many clients
|  MCP server      |     (only you,            |
|  on your laptop  |<--  this machine)          |
+------------------+                            |  Streamable HTTP
                          +---------------------+----------------------+
                          |                                            |
                 MANAGED PLATFORM                                 DIY / PaaS
         Manufact . Prefect Horizon                     Cloudflare Workers
              Smithery . Glama                             Fly.io . Railway
         git push  -->  live URL                     Dockerfile  -->  deploy

Manufact and Prefect Horizon are MCP-native end to end: they detect an MCP entrypoint, build it, and hand back a URL. Smithery and Glama sit a layer up — primarily a registry where clients discover servers, with hosted compute as an add-on rather than the whole product. Cloudflare Workers, Fly.io, and Railway don’t know or care that your container happens to speak MCP; you get a template or a Dockerfile and you’re on your own for the MCP-specific parts.

Our take: reach for a managed platform first. The entire value of hosting is removing your laptop as a single point of failure — a platform that also removes the deploy pipeline as a chore is strictly ahead, unless you already run infrastructure on a specific cloud for other reasons.

Decision table — verified July 2026

This landscape moves monthly; we date-stamp it for exactly that reason. Every row below was checked directly against the vendor’s own site or docs while writing this guide, not pulled from a stale roundup.

One name on that list is doing double duty on purpose. FastMCP Cloud is the name most developers still search for; as of this writing the product lives on as Prefect Horizon, built by the same FastMCP team. We cover the rename in what we got wrong below, because it’s a useful example of exactly how fast this space drifts.

Managed walkthrough: mcp-use → Manufact, end to end

This is the shortest path from nothing to a live, shareable URL. Manufact is built by the team behind the open-source mcp-use SDK, and the two are designed to hand off to each other — the project’s own framing is “mcp-use is to Manufact as Next.js is to Vercel.”

1. Scaffold.

   npx create-mcp-use-app@latest my-mcp-server
   cd my-mcp-server

   This generates a working MCP project in TypeScript or Python, already wired for Streamable HTTP.
2. Build your tools locally first. Run it, point a client at the local URL, confirm the tools do what you expect — hosting a broken server just makes the broken version reachable by more people, faster.
3. Push to GitHub, then connect the repo. Manufact Cloud installs as a GitHub App: pick the repo, and “every push auto-deploys” from then on — no YAML, no manual build step.
4. Get your URL. The platform’s own claim is a live endpoint in under 60 seconds after a push. Paste that URL into any Streamable-HTTP-capable client to test it for real.
5. Open a pull request. Every PR gets its own preview URL, so you can test a change against a real deployed instance before it touches the URL anyone else is using.
6. Publish, if you want distribution. Manufact’s Cloud Inspector lets you debug from a browser and swap models across GPT, Claude, and Gemini before submitting the same build to the ChatGPT, Claude, and Gemini app directories.

Prefect Horizon’s flow is nearly identical in shape: sign in with GitHub at horizon.prefect.io, pick a repo, set the Python entrypoint (main.py:mcp), toggle auth on or off, and deploy. Same GitHub-push model, same sub-minute claim, same per-PR previews — it’s the pick if you’re already building with FastMCP specifically.

DIY walkthrough: Docker → Fly

For full control, package the server yourself and deploy the container. Fly.io is a clean reference because its CLI reads an existing Dockerfile with no extra config.

A minimal Dockerfile for a Python/FastMCP server:

FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN pip install fastmcp
EXPOSE 8000
CMD ["python", "server.py"]

Where server.py ends with mcp.run(transport="http", port=8000) from the transport section above — and, inside a container, that process needs to listen on all interfaces, not just localhost, or Fly’s proxy can’t reach it.

1. Launch.

   fly launch

   Run from the project directory. It detects the Dockerfile, builds it, and generates a fly.toml from your answers to a few prompts. Add --no-deploy if you want to review the generated config before anything ships.
2. Set secrets.

   fly secrets set API_KEY="your_key_here"

   Secrets are injected as environment variables at runtime, never written into the image or the repo.
3. Deploy.

   fly deploy

   Re-run this any time you change the Dockerfile or the app; fly launch already did the first deploy for you.
4. Get your URL. The app is live at https://your-app-name.fly.dev. Point your MCP client’s remote-server config at that URL plus your server’s path.

The same Dockerfile deploys almost unchanged to Railway (connect the repo, it auto-deploys on push, Nixpacks or your Dockerfile builds it) or to Cloudflare Workers if you start from their template instead:

npm create cloudflare@latest -- my-mcp-server \
  --template=cloudflare/ai/demos/remote-mcp-authless
cd my-mcp-server
npx wrangler@latest deploy

Workers deploys to a *.workers.dev subdomain and hands you TLS and global distribution for free; the trade is a more constrained, serverless execution model than a persistent Fly or Railway process.

Auth & safety for a public server

The moment your server has a public URL, your threat model changes from “what can I break on my own machine” to “what can anyone on the internet reach.” Every platform in the decision table gives you a lever for this — none of them turn it on by default:

• Cloudflare Workers — Cloudflare Access for org-internal use, or wire up a third-party OAuth provider (GitHub, Google, Slack, Auth0, WorkOS, and others are supported patterns) for broader access.
• Prefect Horizon — a toggle at deploy time; switch it on and only authenticated users in your organization can connect.
• Smithery and Glama — both sit in front of your server as a gateway with managed OAuth credentials and automatic token refresh, so you don’t hand-roll the flow yourself.
• Fly and Railway — nothing built in. You own the auth layer, typically by putting an OAuth-aware proxy in front of your process or implementing the check inside it.

The mechanics of an OAuth 2.1 flow for Streamable HTTP — PKCE, discovery, token scoping — are covered in full in our dedicated OAuth 2.1 guide. Here’s the pattern that matters most in practice:

A URL is not a secret. Anything a search crawler, a browser history sync, or a copy-pasted Slack message can leak, an attacker can request.

What we got wrong researching this

Two assumptions we walked in with turned out to be stale or imprecise — worth naming, because they’re the exact kind of drift that makes a hosting roundup dangerous to trust six months after publication.

We assumed “FastMCP Cloud” was still the current product name. It was, as recently as mid-2026 — older community roundups still list it under that name. But fastmcp.cloud now 301-redirects to horizon.prefect.io, and FastMCP’s own deployment docs point to Prefect Horizon as “managed, zero-configuration deployment,” with no mention of the old name. The underlying capability didn’t disappear; the brand did.

We verified this against FastMCP’s own docs before writing the decision table, rather than trusting the name we started with.

We assumed Smithery hosts every listed server on its own infrastructure by default. Its own publish docs say otherwise: the primary flow is “bring your own hosting” — you run the server, Smithery points a registry entry at your public URL and acts as a distribution and OAuth-credential layer in front of it. A separate, opt-in path (a smithery.yaml plus a Dockerfile, deployed with smithery deploy) does have Smithery build and host the container itself. Both are real; they are not the same default, and a roundup that treats Smithery as pure compute-hosting is describing the less common path as the main one.

Common mistakes

• Deploying a stdio server unchanged. The single most common failure: pushing a server that still calls mcp.run() with no transport argument to a PaaS. It builds fine and then answers nothing on the exposed port, because it’s still waiting for a parent process to talk to it over stdio. Root cause is always the same one-line miss from the transport section.
• Binding to localhost inside a container. A server listening on 127.0.0.1 is invisible to the platform’s own proxy, which connects from outside the container. It has to bind to all interfaces to be reachable at all.
• Secrets committed to the repo, then deployed verbatim. Every platform here has a secrets mechanism — fly secrets set, an env block, a dashboard field. A key in a committed .env ships to every deploy and every clone of the repo, forever, even after you rotate it later.
• Testing only against localhost, then trusting the hosted URL blind. A deploy succeeding is not the same as tools working. Networking, auth, and environment differences between local and hosted are exactly where servers break; always run one real tool call against the live URL before calling it done.
• Treating a registry listing as a hosting plan. Publishing to Smithery or Glama’s registry gets you discovered. It does not, by itself, keep a bring-your-own-hosted server running — that’s still your infrastructure, and your uptime.

Cost & cold starts

Exact pricing changes too often to print responsibly here — check each platform’s current pricing page before committing. The architectural trade-offs are stable, though, and matter more than the dollar figures:

• Serverless (Cloudflare Workers) scales to zero and back automatically, which is cheap for spiky, low-traffic tools but means a genuinely idle server can add latency to its first request after a quiet period.
• Always-on (Railway, and Fly by default) runs your process continuously as a long-running program, not a function — no cold start, but you’re paying for idle time too.
• Managed MCP platforms (Manufact, Horizon) abstract this choice away entirely; you get a URL, not a scaling policy to tune.
• Context cost is separate from hosting cost. A remote server with a huge tool list still spends the same input tokens per request as a local one — hosting doesn’t change what the model pays to see your tools, only where the process runs.

Who this is for — and who it isn’t

Host it if: more than one person needs the same server, you want it reachable from ChatGPT or Claude’s web app, you want it running without your laptop, or you’re submitting to an app marketplace that requires a hosted URL.

Stay local if: it’s a single-user tool only you invoke, it touches local files or credentials that shouldn’t leave your machine, or it’s a rough prototype that isn’t ready to be anyone else’s attack surface yet. Stdio costs nothing to run and has zero public exposure — don’t give that up before you need to.

Community signal

Manufact’s mcp-use team launched on Hacker News as “Launch HN: Manufact (YC S25) – MCP Cloud” and it landed with real engagement: 111 points, 70 comments. The praise was practical — one commenter liked the demo’s testing and analytics but pushed for clearer pricing and auth guidance up front.

The skepticism was pointed, too: one reader abandoned the site after being asked to sign up before browsing available MCPs at all, and another pushed back hard on the framing that “MCPs are the new websites,” arguing they’re a protocol — like REST or SOAP — not a product category worth that comparison. A third commenter said they’d already moved on from MCP toward “Skills”-style tooling and questioned whether hosted MCP infrastructure would matter to their workflow at all. That last critique is worth sitting with: hosting solves a distribution problem, not a question of whether MCP is the right interface for a given agent in the first place.

On Reddit, a crowdsourced r/mcp thread cataloguing MCP infrastructure products independently lists Cloudflare Agents, Smithery, and Glama under “Infrastructure & Deployment” and “Directories & Marketplaces” — useful corroboration that these are the names practitioners actually reach for, not just vendors with good SEO. The same thread surfaces adjacent options worth knowing about if the platforms above don’t fit: Docker’s MCP Catalog for container-based deploys, and gateway-focused tools like MCP Context Forge for teams that need routing and access control across many servers at once.

The verdict

The bigger picture

Hosting is becoming its own layer in the MCP stack, distinct from both building (SDKs like FastMCP, FastAPI-MCP, and the official Python SDK — see our build-framework comparison for that decision) and discovery (registries like Smithery, Glama, and our own directory of remote MCP servers). A year ago, “host an MCP server” meant writing your own Dockerfile and hoping. Now there’s a YC-backed cloud built specifically for it, and a major workflow-orchestration vendor’s framework team shipping a competing managed tier.

Expect this list to keep consolidating: the platforms that survive will be the ones that also solve distribution — getting your server into ChatGPT’s or Claude’s app directories — not just the ones that solve compute. Compute alone is a commodity; a straight line from a repo to being inside the clients people already use is not.

Frequently Asked Questions

Glossary

Sources

• Primary — Manufact / mcp-use: manufact.com · Y Combinator company page · github.com/mcp-use/mcp-use
• Primary — Smithery docs: Publish · smithery.yaml reference · Container deployments
• Primary — Glama: glama.ai
• Primary — Cloudflare: Build a Remote MCP Server
• Primary — FastMCP / Prefect Horizon: Prefect Horizon deployment docs · HTTP deployment docs · horizon.prefect.io
• Primary — Fly.io: Deploy a Dockerfile
• Primary — Railway: Deploy MCP Servers · Railway MCP docs
• Community — Launch HN: Manufact (YC S25) – MCP Cloud (111 points, 70 comments)
• Community — r/mcp: “What product are you building for the MCP ecosystem?”
• Internal — Build MCP in Python: FastMCP vs FastAPI-MCP vs Python SDK · OAuth 2.1 for Remote MCP Servers · What is MCP? · Remote & hosted MCP servers directory · Smithery deployment skill guide