MCP Server Hosting: How to Run MCP Servers in Production

When an MCP server goes down, every agent that depended on it loses its tools at the same moment. That is the part most hosting guides bury. A Model Context Protocol (MCP) server is not a side service you spin up and forget. It is a running gateway that agents reach through to touch real tools, real data, and real credentials, so where and how you host it decides how reliable, and how safe, all of that access becomes.

MCP server hosting is the practice of running an MCP server as a durable, reachable service so that agents and clients can connect to it in production. The instinct is to treat that as a compute question: pick a box, expose a port, done. That instinct is wrong. Hosting an MCP server in production is an identity and policy problem before it is a compute problem, because the server sits in front of privileged capability. This guide covers the basics of what hosting involves, the transports and hosting models you choose between, the identity and policy layer every model needs, and an honest framework for deciding whether to self-host or go managed.

It is written for the platform, DevOps, and AI-infrastructure engineers standing up MCP servers for internal or customer-facing agents. You already know what an MCP server is. What you need is the hosting architecture, and a clear-eyed view of what production actually demands.

What is MCP server hosting?

MCP server hosting means running an MCP server as a persistent, network-reachable service that agents connect to over a defined transport, with the availability, security, and access controls a production dependency requires. In plain terms: it is the difference between an MCP server that runs on your laptop for a demo and one that a fleet of agents can rely on around the clock.

The MCP server basics matter here because they set the stakes. An MCP server exposes tools, resources, and prompts that a client (typically an AI agent) invokes to get work done. If you want the full grounding on what an MCP server is and how to build one, the complete MCP server guide covers construction and internals, and the Model Context Protocol overview explains the protocol itself. This page starts one step later, at the point where you have a server and now have to run it somewhere real.

Why hosting an MCP server is not like hosting an ordinary API

A normal API returns data. An MCP server hands an agent the ability to act: query a database, call an internal service, read a file store, spend against a budget. That makes it a privileged gateway, not a passive endpoint. The blast radius of a compromised or misbehaving MCP server is the union of every tool it fronts.

So the hosting bar is higher than "keep it up." A hosted MCP server inherits every concern of an internet-facing service, plus the specific danger that the thing on the other side is an autonomous agent acting on instructions it may have been manipulated into following. The more capable the tools behind the server, the more the hosting decision becomes a security decision. That reframing drives everything below.

Why host an MCP server

If a server can run locally, why host it at all? Because local execution does not survive contact with real usage. Hosting an MCP server centrally is what turns a single-developer convenience into shared infrastructure. These are the core MCP server benefits that hosting delivers:

Benefit	What hosting gives you
Reliability	A managed, monitored service with uptime guarantees, so dependent agents do not all fail when one laptop sleeps.
Central updates	Ship a tool fix or a new capability once, and every connected agent gets it immediately, with no client redistribution.
Shared access	Many agents, teams, and applications reach the same server over the network instead of each running a private copy.
Controllable security surface	One hosted ingress is one place to enforce authentication, authorization, rate limits, and logging, instead of scattering trust across every client.
Observability	Centralized logs and metrics show what agents called, when, and with what result, which is impossible to reconstruct from ephemeral local processes.

Notice that the last two benefits are not really about uptime. They are about control. That is the theme this guide keeps returning to: the value of hosting an MCP server well is mostly the value of putting a single governed control point in front of privileged access.

How hosted MCP servers work: transports and the single ingress

Before you can choose a hosting model, you have to understand how a client reaches the server. MCP defines two transports, and the choice between them is the first fork in any hosting decision.

stdio: the local subprocess

stdio runs the MCP server as a local subprocess of the client, communicating over standard input and output. There is no network, no port, and no inbound exposure. That makes it ideal for development and for tools that live on the same machine as the agent. It also means it does not scale: one subprocess per client, no shared state, and no way for a remote fleet of agents to reach it. stdio is where you start, not where you host.

Streamable HTTP: the remote standard

Streamable HTTP is the transport for hosted, remote MCP servers. It carries JSON-RPC 2.0 messages over a single HTTP endpoint that accepts POST requests and optionally streams responses back over Server-Sent Events, all through one URL. It replaced the older HTTP+SSE transport, which is now deprecated. If you are hosting an MCP server for anything beyond a single local user, Streamable HTTP is the transport you are hosting.

Here is the detail that shapes the entire security argument: Streamable HTTP funnels every interaction through one HTTP ingress carrying an Authorization header. That single chokepoint is exactly where identity can be checked and policy can be enforced. When a transport bridges stdio-only servers to remote clients, an MCP proxy sits at that same boundary. Hold onto the single-ingress idea. It is what makes governed hosting structurally possible rather than aspirational.

Dimension	stdio	Streamable HTTP
Where it runs	Local subprocess of the client	Remote, network-reachable service
Network exposure	None	Internet-facing (or private network)
Concurrency	One client per process	Many concurrent clients over one endpoint
Authentication	Not applicable (local trust)	Required: bearer token in the Authorization header
Best for	Development, local-only tools	Production hosting, shared and remote agents

MCP server hosting models: self-host, managed, and gateway-fronted

Once you commit to a remote server, you choose how to run it. There are three models, and they are not mutually exclusive: most production setups combine a compute choice with a gateway in front. Treat these as layers, not as a single either/or pick.

Self-hosting the server process

Self-hosted MCP means you run the server on infrastructure you control: a virtual machine, a container, or a hardened microVM. You own the compute, the patching, the scaling, and the network. The trade is maximum control for maximum operational load. Self-hosting also forces an isolation decision, because a hosted MCP server may run tool code you do not fully trust. The isolation ladder runs from process, to container (which shares the host kernel), to microVM sandboxes such as Firecracker, the open-source AWS microVM project, for genuinely untrusted code. If you are self-hosting at organizational scale, the broader platform concerns (private networking, multi-server orchestration, infrastructure standards) are covered in the MCP platform guide, which owns the run-at-scale story this hosting page links up to.

Managed and serverless hosting

Managed hosting means a platform runs the MCP server for you, often on serverless compute that scales to zero and back. You trade some control for far less operational overhead: no VMs to patch, autoscaling handled, and a deployment story measured in minutes. The cost is cold-start latency on the first request and less control over the runtime environment. For teams that want an MCP deployment platform rather than a pile of infrastructure to maintain, this is the pragmatic default.

Gateway-fronted hosting: the governed model

The third model is the one competitors treat as optional and this guide treats as the point. You put a gateway in front of the server (self-hosted or managed, it does not matter) and route every client through it. An MCP gateway is the single control plane that authenticates callers, enforces policy, and records what happened, before any request reaches a tool. For fleets, egress control, and Kubernetes deployments, the enterprise MCP gateway requirements go deeper on the control-plane architecture. The gateway is what converts "we host some MCP servers" into "we govern every call to every MCP server."

Factor	Self-hosted	Managed / serverless	Gateway-fronted
Operational overhead	High (you own everything)	Low (platform runs it)	Adds a control layer over either compute choice
Control over runtime	Maximum	Limited	Unchanged compute, plus centralized policy
Scaling	Your responsibility	Automatic (with cold starts)	Inherits the compute model beneath it
Identity and policy	You build it per server	Basic, often just OAuth	Centralized: authN, authZ, audit for every server
Best fit	Strict data residency, deep customization	Speed to production, small teams	Multiple servers, multiple teams, real governance

The layer every hosting model needs: identity, policy, and audit

Here is where the SERP goes quiet and this page does not. Whichever compute model you pick, a hosted MCP server is only production-ready when three things sit in front of it: identity, policy, and audit. This is the layer that "deploy to a platform and add OAuth" walkthroughs either skip or hand off to a separate product. It is the actual hosting decision.

Identity answers who is calling. A remote MCP server should act as an OAuth 2.1 protected resource, validating tokens whose audience is bound to that specific server so a token minted for one service cannot be replayed against another. Passing an incoming token straight through to a downstream API (token passthrough) is explicitly forbidden, because it collapses the audit trail and widens the blast radius. Getting this right means real OAuth 2.1 and PKCE, not a shared secret. The full identity story (SSO, dynamic client registration, provider federation) lives in the MCP identity guide.

Policy answers what the caller is allowed to do once authenticated. Identity without authorization is a locked door with no walls. Fine-grained, role-based access control decides which tools a given agent or team can invoke, and under what conditions. Enforcing that at the ingress, rather than trusting each tool to check for itself, is the difference between a policy and a hope. Request-level enforcement, such as MCP call filtering, is how a gateway blocks a disallowed tool call before it ever executes.

Audit answers what actually happened. Every hosted MCP server should produce a tamper-evident record of who called which tool, when, with what arguments, and what came back. That record is your incident response, your compliance evidence, and your debugging tool all at once. The regulatory framing (retention, evidence, controls) is covered in the MCP compliance guide. When identity, policy, and audit all converge at one ingress, you have a governed hosting setup. When they are scattered or absent, you have a liability with good uptime.

Production hosting requirements: a checklist

Beyond the governance layer, a hosted MCP server has to survive real traffic. Before you call a deployment production-grade, work through this checklist:

• Concurrency and scaling - the server must handle many simultaneous agent sessions without degrading. stdio cannot; a properly hosted Streamable HTTP server can, given the compute behind it.
• Cold-start budget - if you host on serverless, measure first-request latency and decide whether it fits your agents' tolerance, or keep a warm instance.
• Session and state handling - decide how session identity is carried across a stream and whether the server holds state between calls or stays stateless behind a load balancer.
• Egress control - constrain what the server itself can reach outbound, so a compromised tool cannot exfiltrate freely. This is a core gateway responsibility.
• Secrets management - tool credentials never belong in the server image or in client tokens; they belong in a secrets store the server reads at runtime.
• Observability - structured logs, metrics, and traces per call, wired to alerting, not just printed to a console.
• Rate limiting and abuse controls - an internet-facing MCP server is an internet-facing API and needs the same throttles.

The risks hosting has to mitigate

An honest hosting guide names what can go wrong. Hosting an MCP server introduces real exposure, and the governance layer above exists precisely to contain it.

• Internet-facing exposure - the moment a server is remote, it inherits every web-facing risk: credential attacks, broken authorization, injection. Treat it like the public API it now is.
• Token passthrough - forwarding a caller's token to downstream services is forbidden by the spec for good reason; it destroys auditability and lets one stolen token roam. Bind tokens to the server's audience instead.
• Multi-tenant blast radius - when one hosted server serves multiple teams, weak isolation means one tenant's bad tool call can reach another's data. This is where the isolation ladder and per-tenant policy earn their cost.
• Malicious and fake servers - agents can be pointed at a hostile server, or a legitimate server's tools can be poisoned to smuggle instructions into the model.

These are not hypotheticals. The threat model is well documented: see the MCP security guide for the full risk landscape, MCP data exfiltration for how privileged access becomes a leak, and MCP tool poisoning for how a trusted server turns hostile. Hosting decisions are the controls that answer these threats.

How to decide: a self-host vs managed decision framework

Put the pieces together and the decision is less about compute than teams expect. Work through it in order:

1. Start with the data and residency constraints. If regulation or policy requires the server and its data to stay on infrastructure you control, self-hosting is the floor. Otherwise, managed hosting is a legitimate default.
2. Weigh operational capacity honestly. Self-hosting means you own patching, scaling, and isolation. If you do not have the platform team to run that well, managed hosting is safer than a self-host you cannot maintain.
3. Count the servers and the teams. One server for one team can get by with basic auth. The moment you have multiple servers or multiple teams, per-server identity and policy stop being optional.
4. Then, regardless of the compute choice, put a gateway in front. Self-hosted or managed, the identity, policy, and audit layer belongs at a single ingress. This is the recommendation the SERP avoids and the one that holds up in production.

The honest conclusion: choosing where the process runs is the easy half. The half that determines whether your hosting is production-grade is whether every call passes through one governed control point. Self-host or go managed based on control and capacity, but front both with a gateway.

Frequently asked questions

What is MCP server hosting?

MCP server hosting is running an MCP server as a persistent, network-reachable service that agents connect to in production, with the uptime, authentication, and access controls a shared dependency requires. It is the step past local development: turning a server that works on one machine into one a fleet of agents can rely on continuously.

Should I self-host or use a managed MCP hosting platform?

Self-host when data residency or deep runtime control is mandatory and you have a platform team to operate it. Choose managed hosting for speed and lower overhead. Either way, front the server with a governed gateway. The compute choice is about control and capacity; the governance layer is non-negotiable in both.

What is the difference between stdio and Streamable HTTP for hosting an MCP server?

stdio runs the server as a local subprocess over standard input and output, with no network exposure, which suits development. Streamable HTTP carries JSON-RPC 2.0 over a single HTTP endpoint for remote, concurrent clients, and is the transport you actually host. Production hosting means Streamable HTTP; stdio does not scale beyond one local client.

Does a remote MCP server need OAuth or authentication?

Yes. A remote MCP server is internet-facing and must authenticate every caller, acting as an OAuth 2.1 protected resource with tokens whose audience is bound to that specific server. Passing tokens straight through to downstream services is forbidden. Without real authentication, you have published privileged tool access to anyone who finds the URL.

How do you secure a hosted MCP server in production?

Layer identity, policy, and audit at a single ingress: authenticate callers with OAuth 2.1, enforce role-based authorization on which tools each agent may invoke, and log every call. Add rate limiting, egress control, secrets management, and tenant isolation. Securing a hosted server is less about the compute and more about the governed control point in front of it.

Can MCP servers handle concurrent load, and how do they scale?

A remote MCP server on Streamable HTTP can serve many concurrent sessions, bounded by the compute behind it. stdio cannot, since it is one subprocess per client. Scaling means horizontal instances behind a load balancer or serverless autoscaling, with attention to session handling and cold-start latency on the first request.

How do you host multiple MCP servers for multiple teams (multi-tenancy)?

Give each tenant strong isolation and scoped policy. Use the isolation ladder (process, container, or microVM) to contain untrusted tool code, bind each tenant's tokens to their own server audience, and enforce per-team access control at a shared gateway. The gateway lets you run many servers while governing every call through one consistent control plane.

What does a governed MCP hosting setup add over a raw deployment?

A raw deployment answers only "is the server up." A governed setup adds the layer that makes hosting safe: centralized identity, fine-grained authorization, request filtering, egress control, and a complete audit trail at one ingress. It converts privileged tool access from an unmonitored liability into a controlled, observable, and compliant capability.

Host MCP servers behind a governed control plane

Hosting an MCP server well is not about finding the cheapest place to run a process. It is about deciding where privileged access gets checked. Self-host or go managed based on your control and capacity needs, but the durable pattern is the same either way: route every call through one control plane that handles identity, policy, and audit. That is exactly what agen.co's MCP gateway is built to do, sitting in front of the MCP servers you host so every agent request is authenticated, authorized, filtered, and logged. If you are moving an MCP server from a demo to production, start by deciding what stands in front of it.