MCP Server Deployment: From Local Stdio to Production

MCP server deployment: picking a transport, a host and the right level of control

A Model Context Protocol server you run on your own laptop is one command away from a client. The moment you want a teammate, a customer, or an agent running somewhere else to call it, you need a deployment: a transport that works over a network, a host that keeps the process running, and usually some authentication in front of it. This guide walks through that path with the actual configuration each platform documents, not a generic checklist.

MCP server deployment is the process of moving a Model Context Protocol server from a local, stdio-based process into a remote, network-reachable service, using the Streamable HTTP transport, hosted on a platform such as Google Cloud Run, AWS, Cloudflare Workers or Vercel, usually with authentication added in front of it.

Prerequisites

You need a working MCP server already, built with an SDK such as the official Python or TypeScript SDK or FastMCP, and running locally over stdio. You will also need an account on whichever host you pick, and, for anything beyond a toy project, a plan for authentication before the server is reachable from the open internet.

Step 1: Decide if you need a remote server at all

MCP's original and still most common mode is stdio: the client launches your server as a local subprocess and talks to it over standard input and output. The official MCP documentation builds its weather-server tutorial entirely on stdio, run with mcp.run(transport="stdio") in Python or serveStdio() in TypeScript, and that is still the right choice for a server that only you, or only one machine, will ever call.

You need a remote deployment once more than one person or more than one client needs to reach the same server, or once the server needs to run somewhere that is not your laptop: a shared team tool, a server wrapping an internal API, or a server you want to offer to other people's agents.

Step 2: Switch to Streamable HTTP

Remote MCP servers use the Streamable HTTP transport. Google Cloud's own writeup on deploying to Cloud Run describes the requirement precisely: the server must expose a single HTTP endpoint path that supports both POST and GET methods, for example a URL like https://example.com/mcp. Server-Sent Events, the transport that preceded Streamable HTTP, still works for backward compatibility but is deprecated in the specification.

Logging rules change too. The MCP docs are explicit that a stdio server must never write to standard output, since that corrupts the JSON-RPC messages; print() in Python and console.log() in TypeScript are both banned for that reason, with logging.getLogger or console.error as the safe alternative. Once a server runs over HTTP instead, that restriction disappears: standard output logging is fine because it no longer shares a channel with protocol messages.

Step 3: Pick a host that matches the workload

The hosting options break down by how much control you want over the runtime, and by the shape of your traffic.

Google Cloud Run runs your server in a container and scales it automatically with demand. The Cloud Run deployment guide builds a two-tool math server with FastMCP 2.6.1, starting the server with mcp.run_async(transport="streamable-http", host="0.0.0.0", port=os.getenv("PORT", 8080)), and packages it in a python:3.13-slim image that installs dependencies with uv. Google calls out three concrete benefits of running this way: Cloud Run scales out automatically to handle incoming requests, a team can share one centralized server through IAM privileges instead of everyone running a local copy, and Cloud Run can force authenticated requests so the public internet cannot reach the server unchecked.

AWS splits the decision three ways, according to its ECS deployment post from Sudheer Manubolu, Piyush Mattoo and Stacey Hou: AWS Lambda suits lightweight, stateless tool endpoints with bursty traffic; Amazon Bedrock AgentCore is a fully managed agent orchestration suite with built-in identity, memory and tool discovery; and Amazon ECS on AWS Fargate is for workloads that need more control over the runtime, networking and connection lifecycle, running as a long-lived service with warm caches, persistent streaming connections, sidecars and any language or runtime. Their example deploys a three-tier application, a Gradio UI, a Bedrock-powered agent and a FastMCP server, all on ECS, using Service Connect for service-to-service communication and Express Mode for automated load balancing.

Cloudflare Workers deploys a server to the edge. Cloudflare's remote MCP server guide, last updated 27 July 2026, lays out four approaches in a comparison table and is explicit that the quick-deploy templates still use the deprecated McpAgent path and should not be used for a new server: a new stateless server should use createMcpHandler() instead, a stateless function with legacy-compatible protocol handling, while McpAgent, built on Durable Objects with RPC, is now marked deprecated for new work. You can start with a public server with no authentication and add Cloudflare Access, OAuth, or a third-party OAuth provider like Stytch, Auth0 or WorkOS once you need to restrict access.

Vercel turns an MCP server into a route inside an existing Next.js application. The Vercel MCP docs have you install [email protected] together with @modelcontextprotocol/server@2 and zod@4 on Node.js 20 or later, then register tools inside app/api/mcp/route.ts and export the handler as both GET and POST. Vercel's pitch is Fluid Compute: optimized concurrency, dynamic scaling and instance sharing built for MCP's irregular usage pattern of long idle stretches followed by sudden bursts, billed only for the compute actually used. Version 2 of mcp-handler dropped the legacy HTTP-plus-SSE transport and its Redis configuration requirement, so an existing v1 server needs the published migration guide before it moves to v2.

// app/api/mcp/route.ts, from the Vercel docs
import { createMcpHandler } from 'mcp-handler';
import { z } from 'zod';

const handler = createMcpHandler((server) => {
  server.registerTool(
    'roll_dice',
    {
      description: 'Roll an N-sided die',
      inputSchema: z.object({ sides: z.number().int().min(2) }),
    },
    async ({ sides }) => {
      const value = 1 + Math.floor(Math.random() * sides);
      return { content: [{ type: 'text', text: `You rolled a ${value}!` }] };
    },
  );
});

export { handler as GET, handler as POST };

Step 4: Add authentication before you share the URL

An unauthenticated remote server is reachable by anyone who finds the URL. Cloud Run's documentation calls enforcing authenticated requests a critical security step, not an optional one. On Vercel, mcp-handler ships a withMcpAuth wrapper: you provide the authorization server and the logic that validates its bearer tokens, and the package itself issues no tokens and runs no authorization server of its own. On Cloudflare, the path runs through Cloudflare Access, a first-party OAuth app, or a third-party OAuth provider such as Auth0 or WorkOS, layered on top of the same createMcpHandler or McpAgent server you already deployed.

Step 5: Test with the MCP Inspector before connecting a real client

Every platform in this guide points at the same tool to verify a deployment before pointing a client at it. Vercel's own instructions run npx @modelcontextprotocol/inspector@latest, open the inspector UI at http://127.0.0.1:6274, select Streamable HTTP, and point it at the deployed /api/mcp path with the proxy session token printed in the terminal. The same inspector works against a Cloud Run, Cloudflare or AWS deployment: once a tool shows up under List Tools and returns the result you expect, the server is ready for a real client such as Claude Code or Cursor to connect to it.

Common mistakes

• Writing to stdout on a stdio server. A single stray print() or console.log() call corrupts every JSON-RPC message that follows it, and the failure looks like a broken client rather than a logging bug.
• Shipping a public Streamable HTTP endpoint with no authentication. Cloud Run's documentation treats this as the one step you cannot skip; the same applies on every other host in this guide.
• Starting a new Cloudflare server on the deprecated McpAgent path. Cloudflare's own guide names createMcpHandler() as the one to use for new, stateless servers and flags the quick-deploy templates as using the old path.
• Picking a host for the wrong traffic shape. A sessionful, streaming-heavy server dropped onto a stateless, bursty-traffic host, or the reverse, will cost more and perform worse than matching the host to the workload AWS describes for Lambda, Bedrock AgentCore and ECS.

When one host is not enough: the gateway layer

A single deployed server is a different problem from a dozen servers spread across teams, each needing its own authentication, access control and audit log. Prefect's roundup of enterprise MCP deployment platforms, published 6 April 2026, surveys the platforms built for that stage. Kong added MCP support in Gateway 3.12 through its AI MCP Proxy plugin, translating the protocol into HTTP so existing REST APIs become MCP services without a rewrite. Prefect Horizon, built by the team behind FastMCP, which the post says powers roughly 70% of MCP servers across languages, covers deployment, a server registry, a gateway and agent access in one product with CI/CD from GitHub. Composio offers more than 500 pre-built, managed MCP integrations for tools like Slack, GitHub and Salesforce, priced from a free 20,000-call tier up to $229 a month for 2 million calls. MintMCP leads with SOC 2 Type II certification and one-click OAuth wrapping for an existing stdio server. TrueFoundry's MCP Gateway reports sub-3ms latency and 350 requests per second on a single vCPU, with a $499-a-month Pro tier adding role-based access and VPC deployment. Lunar MCPX adds data loss prevention at the gateway, blocking leaks before a response leaves the server. Bifrost, an open-source gateway written in Go, publishes a benchmark of 11 microseconds of overhead at 5,000 requests per second.

What's new (as of 14 October 2026)

• Cloudflare's remote MCP server guide, last updated 27 July 2026, now actively discourages the McpAgent path for new servers in favor of the stateless createMcpHandler(), reversing what its own quick-deploy templates still use.
• Vercel's mcp-handler is on major version 2 (2.1.1), requiring the @modelcontextprotocol/server package rather than the older SDK and dropping the legacy HTTP-plus-SSE transport along with its Redis dependency.
• AWS published its three-tier ECS deployment pattern, Gradio UI, Bedrock agent, FastMCP server, on Service Connect and Express Mode, on 14 April 2026, as its reference architecture for sessionful, streaming-heavy MCP workloads.
• Prefect's enterprise platform comparison, published 6 April 2026, documents Kong Gateway 3.12's new AI MCP Proxy plugin and names current pricing for Composio, TrueFoundry and MintMCP at the gateway layer most single-platform deployment guides skip entirely.

Key takeaways

• Stdio is for one client on one machine; anything shared needs the Streamable HTTP transport and a network-reachable host.
• A stdio server must never write to standard output; an HTTP server has no such restriction.
• Google Cloud Run, AWS (Lambda, Bedrock AgentCore or ECS), Cloudflare Workers and Vercel each fit a different traffic shape, from bursty and stateless to long-lived and streaming-heavy.
• An unauthenticated remote MCP server is reachable by anyone who has the URL; every platform in this guide treats adding auth as a required step, not an optional one.
• Running more than a handful of servers across teams is a gateway and governance problem, which is what platforms like Prefect Horizon, Kong AI Gateway and MintMCP exist to solve.

FAQ

What transport should a remote MCP server use?

Streamable HTTP. It is the transport the current MCP specification recommends for remote servers, replacing Server-Sent Events, which still works for backward compatibility but is deprecated. A Streamable HTTP server exposes one HTTP endpoint path that supports both POST and GET requests.

Can I deploy an MCP server without rewriting it as HTTP?

No. A server built only for stdio has to add a Streamable HTTP transport before it can run remotely; the protocol logic and your tool definitions stay the same, but the transport layer and the logging rules around it change, and most SDKs, including FastMCP and the official Python and TypeScript SDKs, support switching the transport with a single argument.

Which host is cheapest for a low-traffic MCP server?

Serverless options built for bursty, idle-heavy traffic, such as AWS Lambda or Vercel's Fluid Compute, bill for compute actually used rather than for an always-on instance, which tends to suit a server that sits idle most of the day and then handles a short burst of tool calls. A long-lived, high-throughput server with persistent connections is usually a better fit for a container platform like Amazon ECS or Google Cloud Run instead.

Do I need a gateway product to deploy an MCP server?

Not for a single server with a known set of clients; a direct deployment to Cloud Run, Cloudflare, AWS or Vercel with authentication in front of it is enough. A gateway or registry product earns its cost once an organization runs enough MCP servers across enough teams that nobody can list them all, or once compliance needs audit logs for which agent called which tool.

Browse the current MCP servers on AI Agents Listing to see how other teams are shipping theirs.