The right MCP server host is the one that matches the server transport and state model. Use an edge or function platform for short, stateless tools. Use an always-on container when sessions, in-memory state, background work, or predictable fixed capacity matter. Use a VPS only when you need operating-system control.
A local MCP server that uses stdio is not ready for hosting yet. A remote server needs an HTTP transport, a public HTTPS endpoint, and an authentication decision before anyone connects to it.
Start with the transport, not the provider
The MCP TypeScript SDK recommends Streamable HTTP for remote servers. It treats the older HTTP plus SSE transport as a compatibility path, while stdio remains the local, process-spawned option.
| TRANSPORT | WHERE IT BELONGS | HOSTING CONSEQUENCE |
|---|---|---|
| stdio | One machine with the MCP client | No public URL; the client starts the process |
| Streamable HTTP | Remote clients and shared servers | Needs HTTPS, an HTTP route, and request handling |
| Legacy HTTP plus SSE | Older remote integrations | Keep only when a client still requires it |
Four hosting shapes, four different tradeoffs
| HOSTING SHAPE | BEST FIT | WATCH FOR |
|---|---|---|
| Edge worker | Small stateless tools close to users | Runtime limits and state stored elsewhere |
| Request-driven container | HTTP tools with variable traffic | Cold starts, request deadlines, and scale-to-zero behavior |
| Always-on managed process | Stateful sessions, steady use, and background work | You pay while the process waits |
| VPS | Custom networking, binaries, or operating-system access | Patching, process supervision, TLS, and backups are yours |
Cloudflare documents both stateless and stateful remote MCP patterns. Cloud Run provides an HTTPS service and can scale to zero, or keep minimum instances active at a cost. Those are useful options when you already work in either platform. An always-on host is simpler when the server should behave like one durable Node or Python process.
State changes the answer
A stateless tool can reconstruct everything from the request and a database. It can run on many instances without caring which one receives the next call. A stateful server may keep an MCP session, connection state, or task progress in memory. Scaling that server across instances requires shared state or sticky routing.
Choose explicitly. If one process is enough, a fixed container removes a lot of coordination. If you expect many tenants or bursts, move state into a database or durable service before adding replicas.
The deployment checklist
- 01Switch to Streamable HTTPUse the current SDK transport and expose one route such as /mcp. Keep stdio as a separate local entry point if developers still use it.
- 02Bind the assigned portListen on 0.0.0.0 and read the port from the host environment. Hardcoding localhost makes a healthy process unreachable from outside its container.
- 03Protect every toolFor a private server, a bearer token can be enough. For multiple users, implement the authorization flow and check permissions at the tool boundary.
- 04Put durable data elsewhereTreat the container filesystem and process memory as replaceable. Store records, sessions that must survive, and job results in an external system.
- 05Test the remote URLUse the MCP Inspector and at least one real client. Test initialization, tool discovery, failed authorization, a restart, and the longest normal tool call.
- 06Set operational limitsAdd timeouts, input limits, useful logs, and a plan for tools that outlive one HTTP request. Long work should return a job identifier instead of holding a request forever.
Where Spocket fits
Spocket fits a small remote MCP server that runs in Node 22 or Python 3.11 and benefits from one always-on process. Bind process.env.PORT, deploy from an MCP-capable editor, and the app receives an HTTPS URL. Automatic restarts, version rollback, logs, write-only environment variables, and a custom domain are included.
There are boundaries. Spocket does not provide a managed database, root access, or horizontal autoscaling. Its public HTTP path has a 25-second upstream response deadline and is not intended for long-lived SSE notification streams. Keep calls short or use an asynchronous job pattern. A platform built around edge fan-out is a better choice for a large stateless public service.
For the fixed-container path, read /documentation/domains-and-webhooks, then deploy through /run/sites. The Solo plan is $3 per month for one 512MB app; current limits and every plan are listed on /pricing.