The best MCP server hosting in 2026 depends less on raw compute and more on how the platform handles remote transport, identity, session state and isolation between users. Cloudflare is the strongest overall choice for a TypeScript remote MCP server; Railway is the easiest route for a conventional Python or Node.js repository; and Render offers a familiar managed web service model with clearer instance boundaries.

This comparison examines the operational work that provider-led deployment tutorials usually skip: stdio versus Streamable HTTP, OAuth, API key handling, long-lived responses, secrets, per-user authorisation, tool permissions, cold starts, logging, rate limits, and multi-tenant design. It is aimed at developers looking to turn a local MCP prototype into a shared team service, a SaaS integration, or a private internal gateway. For a broader infrastructure comparison covering application hosts, databases, workers and model-serving options, start with the DIY AI guide to the best AI hosting platforms.

Quick verdict: Choose Cloudflare Workers for a remote TypeScript MCP server with strong state and OAuth building blocks. Choose Railway for the quickest Python or Node.js deployment from a repository. Choose Render when a conventional always-on web service and predictable service sizing are more useful than edge execution. Use Google Cloud Run for a containerised enterprise deployment, Fly.io for isolated regional machines, and Vercel for a mostly stateless TypeScript endpoint already attached to a Next.js product.

Best MCP server hosting compared

Provider	Best for	Deployment model	Transport fit	Main limitation
Cloudflare Workers	Remote TypeScript MCP servers with per-session state	Edge functions plus Durable Objects	Excellent for Streamable HTTP and streaming responses	Less natural for a conventional Python repository unless containerised
Railway	Fast deployment of Python, TypeScript and Docker MCP servers	Managed container service	Strong for remote HTTP endpoints and background components	OAuth, tenant policy and tool permissions remain application work
Render	Teams wanting a conventional managed web service	Fixed-size web service or private service	Good for Streamable HTTP with an always-on paid instance	Free instances and scale-down behaviour are unsuitable for dependable production access
Google Cloud Run	Containerised MCP servers using Google Cloud identity and networking	Serverless containers	Strong Streamable HTTP support with response streaming	Request timeouts and scale-to-zero behaviour need deliberate configuration
Fly.io	Per-user isolation, regional placement and stateful workloads	Lightweight virtual machines	Flexible for HTTP servers and adapted stdio workloads	High availability is more complex when session state lives on one machine
Vercel	TypeScript MCP endpoints inside an existing Next.js application	Serverless functions with fluid compute	Good for Streamable HTTP and OAuth wrappers	Persistent session state and heavy background work need external services

---

---

How we evaluated MCP hosting platforms

There is no useful single performance score for MCP hosting. A server exposing three read-only tools has a different risk and runtime profile from a multi-tenant server that can deploy infrastructure, read private documents and call third-party APIs on behalf of users. We therefore compared each platform using production-readiness criteria rather than invented latency tests.

• Transport fit: support for Streamable HTTP, response streaming and workloads that may retain session state.
• Identity: OAuth integration, bearer-token validation, API-key handling and compatibility with an external identity provider.
• Isolation: separation of users, tenants, credentials and tool permissions.
• Operations: secrets, logs, metrics, health checks, rate limits, rollbacks and private networking.
• Deployment: support for TypeScript, Python, containers and repository-based builds.
• Cost behaviour: cold starts, idle compute, minimum instances and the cost of stateful supporting services.

Repository deployment is only one part of the review. The code still needs tests, dependency checks and an approval path before a tool with destructive permissions reaches users. The DIY AI guide to code review automation covers that release layer in more detail.

Choose the transport before choosing the host

A local MCP server normally uses stdio. The host application launches it as a child process and communicates through standard input and output. This is efficient for local files, desktop applications, command-line tools and developer-only integrations. It does not become a shared service merely because the process runs on a remote virtual machine.

A shared remote MCP server should normally use Streamable HTTP. The current MCP specification defines stdio and Streamable HTTP as the standard transports. Older tutorials may still centre on HTTP plus SSE or expose an /sse endpoint. SSE can remain useful for compatibility, but it should not be the default architecture for a new deployment.

The transport decision changes the security model. A local stdio server can receive credentials through environment variables or the local credential store. A remote HTTP server needs network authentication, user identity, scoped access and an audit trail. Moving from stdio to HTTP is therefore an application redesign, not a hosting toggle.

1. Cloudflare Workers: best overall for remote TypeScript MCP servers

Cloudflare Workers is the strongest overall MCP host because its MCP tooling directly addresses two difficult parts of remote deployment: session state and OAuth. Cloudflare’s Agents tooling supports Streamable HTTP, while Durable Objects can provide each session or tenant with a uniquely addressable, stateful component with attached storage.

This model is a good fit for an MCP server that needs to remember a negotiated session, store temporary authorisation state or coordinate a stream without pinning every user to a manually managed server. Workers can keep a response stream active while the caller remains connected, and Durable Objects are built for workloads that need coordination rather than purely stateless request handling.

The main trade-off is runtime fit. A TypeScript server using the official SDK maps naturally to Workers. An existing FastAPI or Python MCP repository is usually quicker to deploy on Railway, Render or Cloud Run. Cloudflare Containers can run other runtimes, but that introduces a different deployment path and removes some of the simplicity that makes Workers attractive.

2. Railway: best for deploying an existing Python or Node.js repository

Railway is the easiest choice for a conventional MCP repository. Connect GitHub, define the start command, expose the HTTP port and add secrets as environment variables. It supports automatic source builds, Dockerfiles, persistent services, private networking, databases and background workers without forcing the application into a narrow function runtime.

This flexibility is useful for MCP servers that call several internal services or need a Redis instance, a database, a queue, or a worker in the same project. It also makes Railway a sensible migration target for a local Python server that already works and only needs a proper Streamable HTTP adapter and authentication layer.

Do not confuse deployment convenience with a complete MCP security solution. Railway stores secrets and provides networking, but the application still has to validate tokens, map identities to tenants, enforce scopes and decide which tools each user may call. Serverless sleeping can reduce idle compute, but a cold start on the first request is a poor fit for an integration expected to feel permanently connected. The full Railway hosting review explains its cost controls, private networking and operational limits.

3. Render: best for a conventional managed web-service model

Render is a strong choice for teams that want the MCP server to behave like a normal web application. It can deploy Python or Node.js from a repository, expose a port, enable HTTPS, manage environment variables, and run health checks. Paid web services remain easier to reason about than a highly elastic function platform when the server maintains in-memory session state.

Render also supports private services that are reachable only from other services on the same private network. That is useful for an internal MCP component behind an API gateway, but a remote desktop client cannot connect directly to a private service. Public access, authentication and gateway design must be planned together.

The free service tier should be treated as a development environment, not production MCP hosting. An integration that sleeps, wakes slowly, or loses in-memory state can cause confusing client failures. Use an always-on paid instance for shared access, or move session state to an external store before scaling horizontally.

4. Google Cloud Run: best for containerised enterprise deployment

Google Cloud Run is the strongest hyperscale option for teams already using Google Cloud. It provides official guidance for hosting MCP servers over Streamable HTTP, supports response streaming, and can run a standard container built with Python, TypeScript, Go, or another supported runtime.

Its main advantage is integration with the wider Google Cloud security model. Teams can combine service identity, IAM, Secret Manager, private ingress, VPC connectivity, Cloud Logging and minimum-instance controls. That makes Cloud Run a better fit than a lightweight PaaS when the MCP server must sit inside an existing enterprise boundary.

The limitation is connection lifetime. Cloud Run requests have a configurable timeout, and long-running connections must reconnect when that limit is reached. Scale-to-zero can also produce a cold start. Keep the protocol session resumable, store important state outside the container and set a minimum instance count when first-request latency is unacceptable.

5. Fly.io: best for per-user isolation and regional machines

Fly.io is unusually well suited to single-tenant MCP deployments. A team can run one isolated machine per customer, workspace, or sensitive integration, rather than serving every user from a single shared application process. This reduces the blast radius of a credential leak and makes resource limits easier to enforce.

Fly Machines also give developers more control over region placement, volumes, and process lifetime than a typical function platform does. Fly’s MCP tooling can help package and launch existing servers, including workloads that began as stdio processes.

The trade-off is operational complexity. A stateful MCP session tied to one machine complicates high availability and horizontal scaling. Either route a session consistently to the same machine or move session state to shared storage. Simply placing several replicas behind a load balancer can create intermittent failures when a follow-up request reaches a replica that has never seen the session.

6. Vercel: best for an MCP endpoint inside a TypeScript product

Vercel is a practical option when the product already runs on Next.js, and the MCP server is an extension of the same application. Its MCP handler supports Streamable HTTP and can be wrapped with OAuth verification, allowing the endpoint to share deployment, preview and routing workflows with the existing codebase.

This is strongest for stateless tools that call databases or APIs and return quickly. It is less attractive for servers that depend on local process state, persistent filesystem access or heavy background jobs. Store sessions and tokens in an external database or key-value service, and keep long-running work behind a queue rather than holding the MCP request open unnecessarily.

AI coding assistants can quickly generate the handler and client configuration, but the generated auth code warrants more scrutiny than a normal endpoint. The DIY AI comparison of the best AI coding tools explains which assistants are strongest for repository-aware implementation, testing and review.

MCP hosting pros and cons

Provider	Pros	Cons
Cloudflare Workers	Strong Streamable HTTP and OAuth tooling. Durable Objects suit per-session or per-tenant state. Fast global request handling	Best fit is TypeScript. Platform-specific state model. Complex Python applications may need containers
Railway	Fast GitHub and Docker deployment. Good Python and Node.js support. Databases, workers and private networking in one project	Variable usage costs. Cold starts if sleeping is enabled. Auth and tool policy remain application responsibilities
Render	Conventional web-service model. Clear service sizing. Private services for internal components	Free services are unsuitable for production access. Horizontal scaling needs external session state. Private services require a public gateway for remote clients
Cloud Run	Strong container and language support; Google Cloud identity and networking integration; good enterprise observability	Request timeout needs planning. Cloud configuration is heavier. Scale-to-zero can add cold-start delay
Fly.io	Strong workload isolation. Flexible region placement. Useful for per-user machines and persistent volumes	More infrastructure knowledge required. Stateful high availability is difficult. Multi-tenant routing needs careful design
Vercel	Excellent fit for Next.js and TypeScript teams. Simple repository and preview workflow. MCP handler includes OAuth integration patterns	External state is usually required. Less suitable for heavy background work. Not a natural host for adapted stdio processes

The recurring real-world problem: credentials belong to users, not the deployment

Community discussions about remote MCP servers repeatedly reach the same obstacle. A local prototype works because a single developer sets an API key in an environment variable. The design breaks when ten users connect, and each person must access Jira, GitHub, Notion or an internal database with their own permissions.

One global credential turns the MCP server into a shared super-user. Passing raw user keys through every client creates onboarding, rotation and leakage problems. The production route is usually OAuth with per-user tokens stored server-side, or an enterprise identity layer that issues scoped tokens to the MCP resource server.

This is also why hosting price is rarely the decisive cost. A cheap container can run the protocol endpoint. The expensive work is building consent, token storage, revocation, audit logs, tenant mapping and tool-level authorisation correctly.

Public, private or behind a gateway?

Deployment pattern	Use it when	Required controls
Public remote MCP server	External users connect directly from supported clients	OAuth, scoped tokens, rate limits, audit logs, tenant isolation and abuse controls
Private MCP server	Only internal agents or services inside one network need access	Private networking, workload identity, service-to-service policy and restricted ingress
MCP server behind a gateway	Several servers need one authentication and policy layer	Central identity, tool allowlists, request logging, quotas, routing and credential injection
One MCP instance per tenant	Customer credentials, data or resource limits must be strongly isolated	Automated provisioning, per-instance secrets, lifecycle controls, cost limits and update management

A gateway becomes increasingly attractive as the number of servers grows. It can centralise authentication, rate limiting and logs while keeping the individual MCP servers private. The gateway should not blindly pass upstream tokens through to downstream APIs. Validate the token’s audience, enforce scopes, and preserve an audit trail showing which user called which tool.

Cold starts, long-lived connections and session state

Cold starts are not automatically fatal to MCP. A stateless tool call can tolerate a brief startup delay. The problem appears when the client assumes a session is still live, the container has been recycled and the server stored negotiation or authorisation state only in memory.

Use one of three patterns:

• Stateless HTTP: validate every request and keep no essential server memory between calls.
• External session store: store session, token and tenant state in a database, Redis-compatible service or durable key-value store.
• Sticky stateful instance: route a session to the same Durable Object, machine or service replica until it expires.

The first pattern scales most cleanly. The third can be simpler for interactive behaviour, but it requires explicit handling of failure and reconnection. A platform that claims to automatically scale does not resolve this protocol-level decision.

Tool-level permissions are not the same as server authentication

Authenticating a user proves who is calling. It does not prove they should be allowed to call every tool. An MCP server that exposes list_projects, read_logs, deploy_service and delete_database should not treat them as one permission.

Map OAuth scopes or internal roles to tool groups. Mark destructive tools clearly, require confirmation where the client supports it, and enforce permission checks on the server rather than relying solely on the client interface. Client-side tool toggles improve usability, but they are not a security boundary.

Common MCP hosting mistakes

Deploying a stdio server and calling it remote

Running a local process on a VPS does not give remote clients a standard MCP endpoint. Add a proper Streamable HTTP transport or a controlled gateway that adapts the process safely.

Following an old SSE tutorial without checking the client

Some starter projects still use legacy HTTP plus SSE conventions. Confirm which transport the target clients support and prefer Streamable HTTP for new work.

Storing one upstream API key for every user

This collapses user permissions into the deployment identity. Use per-user OAuth tokens, workload identity or deliberately isolated single-tenant instances.

Scaling replicas without moving session state

Round-robin traffic can split one MCP session across processes. Use stateless requests, shared storage or session-aware routing.

Logging tool arguments without redaction

MCP calls can contain document text, database queries, file paths and credentials. Log tool name, user, tenant, result status, duration and request ID, but redact sensitive arguments and results.

Letting generated code define the permission model

AI-generated server scaffolding is useful, but auth, token validation and destructive tools need manual threat modelling. Large generated changes should be staged and reviewed using the same discipline described in DIY AI’s guide to reviewing repository-wide refactors.

Practical MCP deployment checklist

• Use stdio only for local or tightly controlled process execution.
• Use Streamable HTTP for a shared remote server.
• Decide whether the server is public, private, gateway-protected or single-tenant.
• Separate authentication from tool-level authorisation.
• Use per-user or per-workload credentials rather than one global upstream key.
• Store secrets in the platform secret system, not the repository or client configuration.
• Choose stateless requests, shared session storage or sticky session routing deliberately.
• Add health checks that verify the MCP endpoint without calling destructive upstream tools.
• Log user, tenant, tool, status, latency and request ID with sensitive data redacted.
• Apply per-user and per-tool rate limits before opening the server publicly.
• Test OAuth login, token expiry, revocation and re-authentication across each supported MCP client.
• Test a deploy, a rollback, a cold start, and a lost-session recovery before the production launch.

Which MCP server host should you choose?

Cloudflare Workers is the best default for a new TypeScript remote MCP server because it combines Streamable HTTP support, OAuth tooling and a credible state model. Railway is the best route for an existing Python or Node.js repository that needs a database, worker or queue nearby. Render is the better fit for teams that prefer an understandable always-on web service with fixed service sizes.

Choose Google Cloud Run when the server belongs inside Google Cloud identity and networking. Choose Fly.io when per-user machines or regional isolation justify more infrastructure control. Choose Vercel when the MCP endpoint is a lightweight extension of a Next.js product.

For a self-managed gateway or a server requiring operating-system access, a Droplet or App Platform deployment remains viable. The DIY AI DigitalOcean review explains the difference between managed application deployment and owning a virtual server. In every case, treat hosting as the easy layer. Identity, permissions and state determine whether the MCP server is ready for real users.

Best MCP server hosting FAQs

What is the best hosting for an MCP server?

Cloudflare Workers is the best overall host for a new remote TypeScript MCP server. Railway is easier for existing Python and Node.js repositories, while Render is a strong choice for a conventional, always-on web service.

Can I host an MCP server on Railway?

Yes. Railway can deploy a Python, TypeScript or Docker MCP server from GitHub and expose it over HTTPS. Use Streamable HTTP for remote access, store secrets in Railway variables and implement authentication and per-user permissions in the application.

Can I host an MCP server on Render?

Yes. Deploy it as a web service for public remote access or as a private service behind another gateway. Use a paid always-on instance for production workloads and externalise session state before adding multiple replicas.

Should an MCP server use stdio or HTTP?

Use stdio when the MCP host launches the server locally as a child process. Use Streamable HTTP when the server needs to be shared remotely by several clients or users. Converting from stdio to HTTP also requires a proper remote authentication model.

Does a remote MCP server need OAuth?

OAuth is the preferred approach for a remote server acting on behalf of users, especially when each person needs separate credentials, scopes and revocation. A private service-to-service deployment may use workload identity or controlled bearer tokens instead, but a public unauthenticated MCP endpoint is unsafe.

Can an MCP server be stateless?

Yes. Stateless request handling is often the easiest model to scale. Validate each request and keep durable session, token and tenant data in external storage. Stateful sessions are also possible, but they need sticky routing or a platform component such as Durable Objects.

How should MCP servers store API keys?

Deployment-level secrets should use the host’s secret store. User-specific credentials should be encrypted at rest, associated with the correct user and tenant, scoped narrowly and revocable. Do not return upstream credentials to the MCP client or include them in logs.

Is serverless hosting suitable for MCP?

Yes, provided the server can tolerate cold starts and does not rely on disposable in-memory state. Keep sessions in durable storage, configure minimum instances when necessary, and test client reconnection after a timeout or platform restart.

Should I put several MCP servers behind one gateway?

A gateway is useful when several servers need shared authentication, quotas, logging and tool policy. It reduces duplicated security work, but the gateway must validate token audiences, preserve tenant boundaries and avoid blindly forwarding credentials.