Get started
Back to blog
Deployment overview • 11 min read

Where to Deploy Your MCP Server

Seven options, three deployment models, and a direct link to a step-by-step guide for each. Pick the category that matches your runtime and how much control you want over the container.

Quick picks

Least setup for Node or Python

Render or Railway. Both build from the repository and handle the domain.

Any language, scale to zero

Google Cloud Run. It covers TypeScript, Python, Java, and PHP from a container or buildpack.

TypeScript at the edge

Cloudflare Workers for global edge, or Vercel for the simplest Hono deployment.

At a glance

Platform Model Runtime fit Idle behavior Setup
Render PaaS Node, Python native; Docker for PHP/Java Free spins down after 15 min Git + render.yaml
Railway PaaS Node, Python native; Docker for PHP/Java Optional serverless sleep CLI or Git + Railpack
Fly.io Container platform Any language via Docker Auto-stop Machines Dockerfile + fly.toml
Google Cloud Run Serverless containers Any language via buildpacks or Docker Scale to zero gcloud source deploy
AWS App Runner Serverless containers Any language via ECR image Minimum one instance ECR image + IAM
Vercel Serverless platform TypeScript bundle Scale to zero Git + src/index.ts
Cloudflare Workers Edge platform TypeScript bundle Scale to zero Worker entry + Wrangler

Idle behavior and pricing change over time; each linked guide documents the current setup and caveats for that platform.

Option 1

PaaS and container app platforms

The fastest path from a generated bundle to a public URL. You connect a repository or run a CLI command, the platform detects or builds the image, and it handles TLS, routing, and restarts.

Render

Native Node and Python

Git-based deploys with a render.yaml blueprint. The Free plan spins down after 15 minutes and wakes on the next request; PHP and Java use a Dockerfile.

Read the guide

Railway

CLI or Git deploys

Railpack detects Node and Python, while PHP and Java use Docker. Usage-based pricing, optional idle sleeping, and a public HTTPS domain generated on demand.

Read the guide

Fly.io

Docker-level control

Deploy a container image to Fly Machines with fly.toml. Per-second billing and auto-stop give you control over idle cost, but there is no free tier.

Read the guide
Option 2

Serverless containers

Container platforms that hide the cluster and scale down when nobody is calling. They cover every generated runtime, including PHP and Java, at the cost of a Dockerfile or buildpack adjustment.

Google Cloud Run

Any language, scale to zero

Deploy from source with buildpacks or from a Dockerfile. Handles all four runtimes, scales to zero, and has the most complete language coverage of the options here.

Read the guide

AWS App Runner

Existing AWS customers

Pull an ECR image into a managed App Runner service. App Runner stopped accepting new customers on April 30, 2026; new AWS workloads should use ECS Express Mode instead.

Read the guide
Option 3

Serverless and edge platforms

Request-scoped runtimes with little or no server management. They are the lightest option for the TypeScript bundle, but the runtime constraints are tighter and the other language bundles are not covered.

Vercel

Zero-config Hono

The TypeScript bundle already uses Hono, which Vercel detects automatically. Add one entry file, connect the repository, and deploy as a Vercel Function on the Node runtime.

Read the guide

Cloudflare Workers

Global edge, TypeScript

A Worker entry, the nodejs_compat flag, and the axios fetch adapter turn the TypeScript bundle into a global endpoint. Watch CPU, duration, and streaming limits.

Read the guide

The setup work is the same everywhere

Whichever platform you choose, a generated MCP server needs the same handful of changes before it can serve remote clients.

  1. 1

    Use HTTP, not stdio

    Generated TypeScript needs --http; Python uses --transport streamable-http. Stdio is for local desktop clients only.

  2. 2

    Bind to the platform's address and port

    Listen on 0.0.0.0 and use the port the platform routes to, whether that is $PORT, 8080, or an internal_port setting.

  3. 3

    Keep credentials in the platform's secret store

    Add the MCP_AUTH_* variables from the bundle README. Never commit tokens to the repository or a config file.

  4. 4

    Point health checks at a real health route

    A plain GET to /mcp is not a health check. Add a /health route that returns 200, or use TCP checks where available.

  5. 5

    Plan for ephemeral state

    Local files and in-memory sessions disappear on restart or scale-down. Pin one instance for testing, or move session state to an external store.

  6. 6

    Authenticate the public endpoint

    Protecting upstream credentials does not protect the MCP URL. Put an authorizer, gateway, or platform access control in front of it before sharing it.

Once the endpoint is live, point your client at the platform URL plus /mcp. The client-side setup is covered in Connecting Generated MCP Servers to Claude Desktop and Cursor.

A note on AWS App Runner

App Runner is included here because existing customers still run it, and those services remain operational. AWS stopped accepting new App Runner customers on April 30, 2026 and recommends ECS Express Mode for new containerized workloads. The App Runner guide explains the image-based setup and the migration path.

Start with a deployable bundle

Generate an MCP server from an OpenAPI specification, then follow the guide for the platform that matches your runtime.

Upload Spec Read the generation guide