MCP Server Hosting: A Practical Guide (2026)

Where an MCP server runs determines who can use it, what it costs, what auth shape you need, and how often you get paged at 3am. The defaults differ wildly: a stdio server that ships as npx your-package has zero ops surface; an HTTP server on a managed platform has billing and SLO surface from day one.

This guide covers the six realistic shapes, what each one trades, and the decision tree that picks one for a given server. Chapter 9 of MCP in Production goes deeper, including a comparison of the managed MCP platforms in the field and the hidden-cost line items most users miss.

Option 1: stdio binary, distributed as npm

The server runs as a subprocess of the client. The user installs your package; their client config spawns it. No network, no hosting, no auth surface.

Cost: $0 to run. npm fees for publishing only.
Latency: local subprocess. ~10ms IPC.
Operational burden: npm publish + update notifications. That's it.
Right for: personal tools, dev workflows, anything where "user installs and runs" is the use case.
Wrong for: shared state, billing, anything needing a long-running connection to upstream.

Option 2: stdio binary, distributed standalone

Same as Option 1 but shipped as a Go/Rust/whatever binary, not via npm. Useful when the runtime overhead of Node startup matters or you don't want to require Node.

Costs and burden mirror Option 1, plus the build-and-distribute pipeline for the binary. Use only when Option 1 doesn't fit the install story.

Option 3: HTTP server in a container, self-hosted

The server runs as a long-lived HTTP service in your infra. You handle auth, deployment, scaling, monitoring.

Cost: infra cost (usually low for a single small service) + your time.
Latency: network roundtrip from client to server. Tens to hundreds of ms.
Operational burden: real. Deploys, monitoring, on-call, certs, dependency updates.
Right for: internal MCP servers serving multiple users where you already run other services.
Wrong for: if you don't already have a deploy pipeline, the burden swallows the benefit.

Option 4: serverless (Lambda, Cloudflare Workers, etc.)

HTTP server in functions-as-a-service. Cold starts, no persistent state, but no ops burden either.

Cost: usage-based; cheap at low usage, can spike unpredictably.
Latency: cold starts hurt -- 200ms-2s on a first call.
Operational burden: near zero.
Right for: low-traffic servers where cold start is acceptable. Edge integrations where geographic distribution matters.
Wrong for: servers with per-tenant state, persistent connections to upstream, or long-running tool execution (most workflow tools blow the function timeout).

Option 5: managed MCP platform

A platform that hosts MCP servers for you. mcp.hosting (the Yaw Labs platform) is one option; others have entered the field. You upload a container or wire to a GitHub repo, the platform handles transport, scaling, auth bridging.

Cost: per-server flat fee or usage-based depending on the platform.
Latency: network + platform overhead. Comparable to self-hosted HTTP.
Operational burden: low. Mostly "ship a new version" workflow.
Right for: a public or semi-public MCP server you want users to be able to add without running infra. The path from "wrote a server" to "users have access" is the shortest of any option.
Wrong for: servers that need direct access to your internal infra (the platform is the hop you'd want to avoid).

Option 6: bundled inside another product

Your MCP server is a feature of a product you're already shipping -- a SaaS that adds an MCP endpoint to its existing service. No standalone hosting question; the server is just another endpoint in your app.

This is the right answer for vendors who already host an API: the MCP surface is one more route, served from the same infra, on the same auth.

The decision tree

Is this a personal/dev tool? -> Option 1 (npm stdio).
Are you shipping it as a feature of an existing SaaS? -> Option 6 (bundle).
Do you want users to add it without running infra? -> Option 5 (managed platform).
Do you have an existing deploy pipeline and need direct infra access? -> Option 3 (container, self-hosted).
Is the traffic low and bursty? -> Option 4 (serverless).
Do you need Node-free distribution? -> Option 2 (standalone binary).

Reproducible builds, regardless of option

Whichever shape you pick, the build should be reproducible off your laptop. Pinned base image, recorded image digest, no implicit deps on what your build host has installed. The version your users run today should be reproducible by anyone next year, including you.

Want the full chapter?

MCP in Production Chapter 9 covers all six options with cost arithmetic at three traffic tiers, an honest comparison of the managed MCP platforms in the field, container packaging patterns, the reproducible-build discipline, and the migration story when traffic outgrows your initial pick.

MCP in Production

The MCP server book. Twelve chapters from shipping fourteen @yawlabs/* servers. PDF + EPUB. Free updates as the spec moves. $39 one-time, secure checkout.