MCP server hosting: self-hosted or managed
Hosting an MCP server means running an HTTPS endpoint that speaks the protocol: a service that answers server/discover, tools/list and tools/call over Streamable HTTP. Most of that is ordinary web service work. Four parts are not, and they are the ones a platform choice locks in: which transport you serve, how a client discovers where to get a token, whether the protocol revision you implement still carries sessions, and how much of your security posture belongs to the domain you run on rather than to your code.
The first decision is whether you need hosting at all. A packaged server, distributed through npm, PyPI, NuGet, a container registry or an MCP bundle, runs as a child process on the user’s own machine over stdio. There is nothing to host. As of 18 August 2026, 12,442 of the registry’s 25,124 components were packaged and 12,682 were remote endpoints, so both are well-populated choices rather than one being the default.
Host a remote server when the server needs credentials the user should not hold, when it must reach private infrastructure, when you need to ship changes without asking anyone to upgrade, or when your users are on clients that cannot spawn local processes.
Self-hosted or managed: what actually differs?
The difference is concentrated in a few places.
| Self-hosted | Managed platform | |
|---|---|---|
| TLS and certificate renewal | Yours to configure, renew and monitor | Handled by the platform |
| Custom domain and DNSSEC | Fully under your control | Depends on what the platform offers |
| Credential storage | Your secret manager | Their secret store, with its own access model |
| Scale to zero | You build it | Usually included |
| Trust score ceiling | Nothing structural in the way | Can be capped by platform defaults |
The last row is the one that matters most, so it is worth being concrete about.
What do you actually have to get right?
These are the deployment details that decide whether a remote MCP server is usable and trustworthy, roughly in the order they go wrong.
Serve the exact path you declare. The single most common transport failure is a listing pointing at a URL that redirects, or at a landing page returning HTTP 200 that is not MCP. We follow at most one same-origin redirect; anything else fails the check. Whatever path you serve on, /mcp conventionally, is the path your registry entry must name.
Serve Streamable HTTP. HTTP+SSE is deprecated and scores lower. If you already serve SSE, add Streamable HTTP alongside it rather than cutting existing clients off. See transports.
Get TLS right, then keep it right. Valid chain, current protocol versions, and HSTS. Certificate expiry is the classic cause of a server that was healthy for six months and is now unreachable, and it is invisible to a monitor that only checks the process.
Authenticate properly, or deliberately not at all. If your server touches anything private it needs OAuth with RFC 9728 protected-resource metadata, so a client meeting a 401 can discover where to get a token. A bare 401 is not enough. See authentication and MCP authorization.
Design for statelessness. The 2026-07-28 revision removed protocol sessions and the Mcp-Session-Id header. Every request carries its own protocol version and capabilities. That simplifies hosting: no sticky sessions, no session affinity, no shared session store, so any stateless autoscaler or serverless platform works.
Consider DNSSEC. It protects against someone hijacking resolution of your domain, and it is one of the few signals that is purely a registrar and DNS-provider decision. See DNSSEC.
Does serverless work for MCP servers?
Yes, and better than it used to. Statelessness in the current revision removes the reason it used to be awkward. There is no handshake to keep alive and no session to pin, so a request can land on any instance.
Two caveats worth planning around. Cold starts show up directly in the tool-call latency a user feels, since an agent may fire several calls in sequence. And long-running tools sit badly with per-request execution limits: if a tool takes minutes, look at the Tasks extension for asynchronous execution with durable handles, rather than holding a request open.
Tasks is an opt-in extension negotiated per request, not something you can simply switch on. The client declares io.modelcontextprotocol/tasks in the extensions field of its per-request capabilities, and the server advertises the same extension in its server/discover capabilities. A server must check that the client declared support before returning a task handle, and never return one to a client that did not. So a task-capable server still needs a synchronous path for clients that have not opted in.
What about running one behind a gateway?
Common at organisational scale, and it changes what anyone outside can see. A gateway presents many servers as one endpoint, so we score the gateway rather than the servers behind it. If you operate both, list the individual servers in the registry in their own right, or the provenance work you did on each becomes invisible.
Do you need to be in the registry?
Only if you want anyone to find the server, but it is also how the trust signals attach to you rather than to nobody. Listing declares the endpoint, the transports and any required headers. Claiming it with an owners.json ties the entry to the people who actually maintain it, which is the difference between a scored endpoint and a scored endpoint with a known owner.
A reasonable default
For most teams shipping a first remote MCP server: a container on whatever platform you already run services on, behind a custom domain you control, TLS and HSTS from your existing edge, Streamable HTTP on /mcp, OAuth with protected-resource metadata if it touches anything private, stateless so it scales horizontally, and OpenTelemetry spans per tool call.
A managed MCP platform handles the protocol details for you, and in exchange you inherit its domain posture. Whether it supports a custom domain decides which of the two that is: with one, the domain-level signals are yours; without one, they stay the platform’s.
Where to go next
- Building it: the remote server guides cover Go, Python, TypeScript, Rust, Java, Kotlin and .NET.
- Getting it right before you ship: MCP security best practices has the remote endpoint checklist with commands and pass conditions.
- Checking what you deployed: point the MCP Inspector at the live URL, not at localhost. Most deployment bugs only exist in the difference.