← Back to blog
·By MCPCore Teammcphostingguideproduction

MCP Server Hosting: The Complete Guide

Everything that goes into hosting an MCP server for real use: what production hosting actually requires, the four main ways to do it, and how to pick between them.

An MCP server that only runs on localhost works fine for one developer testing on one machine. The moment you want to share a tool with a teammate, connect it to a client that isn't sitting next to the server process, or use it from more than one AI assistant, you need to host it somewhere. This guide covers what MCP server hosting actually requires and the realistic options for doing it.

What "Hosting" an MCP Server Actually Means

Hosting an MCP server means running it as a persistent, reachable service instead of a local subprocess. Under the current MCP specification, that almost always means the Streamable HTTP transport rather than stdio, since stdio requires the client to spawn the server as a child process on the same machine. A hosted server needs:

  • A public HTTPS endpoint. AI clients will not connect to plain HTTP in production, and most Streamable HTTP implementations expect TLS.
  • A way to stay running. The process has to survive terminal closures, deploys, and machine restarts.
  • Authentication. Anyone with the URL can call a public server, so you need to decide who should be allowed to.
  • Rate limiting. Without it, a misbehaving AI loop can exhaust a downstream API quota or hammer a database.
  • Observability. When a tool call fails at an inconvenient hour, you need logs that show what was called, with what parameters, and what happened.

None of this is specific to MCP. It is the same list any production HTTP service needs. What makes MCP hosting distinct is that the caller is an AI model deciding autonomously when to invoke your tools, which makes authentication and rate limiting less optional than they might feel for an internal-only service.

The Four Realistic Ways to Host an MCP Server

1. Self-hosted on a VPS

Rent a server, run your Node.js or Python process behind Nginx, and manage TLS with Certbot. This gives you full control over the network path and runtime, at the cost of setting up and maintaining all five requirements above yourself. It is the right call when you already run infrastructure you trust or have specific compliance requirements about where the process runs.

2. Serverless or edge functions

Deploy stateless tools as functions on a platform like Cloudflare Workers, Vercel, or AWS Lambda. You get TLS and scaling for free, but cold starts and function timeout limits can be a problem for long-running tools, and you are still responsible for building your own auth, rate limiting, and observability layer on top.

3. Docker on your own infrastructure

Containerize the server so the same image runs identically on a laptop, a VPS, or Kubernetes. This solves reproducibility but not the operational burden: you still need a reverse proxy, certificate management, and monitoring around the container.

4. A managed MCP hosting platform

Platforms built specifically for MCP, like MCPCore, provision the HTTPS endpoint, subdomain, authentication, secrets, rate limiting, and analytics automatically. You write tool code and it is live immediately, without touching a reverse proxy, a certificate, or a process manager. The tradeoff is less control over the underlying infrastructure, which matters for some compliance situations and does not matter for most teams shipping tools quickly.

How to Choose

If your priority is...Consider...
Getting a working, secure endpoint todayA managed platform
Full control over the network and runtimeSelf-hosted VPS
Reproducible deployments across environmentsDocker
Minimal infrastructure for simple, stateless toolsServerless functions
Compliance requirements that mandate your own infrastructure, without losing built-in toolingA managed platform with a self-hosted Enterprise option

Most teams underestimate how much of the list above (auth, secrets, rate limiting, observability) has to be built regardless of which hosting method they pick. Self-hosting and Docker solve "where does the process run," not "how do I secure and monitor it." That second half of the problem is what a managed platform removes entirely.

Getting Started

If you want to see what a managed hosting setup looks like in practice, our MCP server hosting page walks through exactly what MCPCore provisions for every server. For the self-hosted side of the comparison, including when it actually makes sense, see Self-Hosted MCP vs Managed MCP Hosting. And if you are ready to deploy something today, How to Host an MCP Server is a shorter, step-by-step version of this guide.


Hosting requirements are based on the current MCP specification's Streamable HTTP transport. Check modelcontextprotocol.io for the latest transport and security guidance before deploying to production.