MCP Server Deployment: Railway vs Cloudflare Workers vs VPS

Your MCP server works locally. It handles tool calls, returns clean results, and your agent talks to it without issues. Now you need to put it somewhere other people — or other agents — can reach it.

The three most common deployment targets for MCP servers in 2026 are Railway, Cloudflare Workers, and a traditional VPS. Each one handles MCP differently, and the wrong choice can cost you hours of debugging transport issues or unexpected bills.

The key differences at a glance

	Railway	Cloudflare Workers	VPS (Hetzner, DigitalOcean, etc.)
Transport	SSE, WebSocket, stdio (via long-running process)	SSE only (no stdio, no persistent WebSocket)	All (stdio, SSE, WebSocket)
Cold start	None (always running)	Yes (sub-50ms typical)	None
Pricing model	Usage-based (CPU + memory + egress)	Request-based (free tier: 100K req/day)	Fixed monthly ($4-20/mo for small servers)
Persistent state	Yes (filesystem, attached databases)	No (use KV, D1, or R2)	Yes
Scaling	Automatic	Automatic, global edge	Manual (or scripted)
Setup complexity	Low	Medium	Medium-high

Railway: the fastest path to production

Railway is the simplest option for most MCP servers. Push your code, Railway runs it. No Dockerfile required for Node.js or Python projects — it detects the runtime and builds automatically.

Why it works for MCP:

Railway runs your server as a long-lived process. That means stdio-based MCP servers work if your agent connects through a proxy, and SSE servers work out of the box. You get a persistent filesystem and can attach a Postgres or Redis database with one click.

Deploying a Node.js MCP server:

# Install Railway CLI
npm install -g @railway/cli

# Login and initialize
railway login
railway init

# Deploy
railway up

Add a PORT environment variable in the Railway dashboard. Your SSE endpoint will be available at the generated Railway URL.

When Railway fits:

• You want the lowest friction path from local to deployed
• Your server needs persistent connections or background processing
• You are prototyping or running a server with moderate traffic
• You need attached databases without managing them yourself

Watch out for:

• Costs scale with uptime, not requests. A server that idles still uses memory
• No built-in edge distribution — your server runs in one region
• Egress charges add up if your server returns large payloads

Cloudflare Workers: edge-first, request-based

Workers run your code at the network edge, close to wherever the request originates. For MCP servers that handle short, stateless tool calls, this can mean lower latency than a single-region server.

Why it works for MCP:

Workers support SSE responses, which is the transport most remote MCP clients expect. The request-based pricing model means you pay nothing when nobody is calling your server. For bursty workloads — an agent that calls your server ten times during a task and then goes quiet — this is much cheaper than an always-on process.

Deploying an MCP server to Workers:

# Install Wrangler
npm install -g wrangler

# Create a new Workers project
wrangler init my-mcp-server
cd my-mcp-server

Your wrangler.toml should define the entry point and any bindings (KV, D1, R2) your server needs:

name = "my-mcp-server"
main = "src/index.ts"
compatibility_date = "2026-07-01"

[[kv_namespaces]]
binding = "CACHE"
id = "your-kv-namespace-id"

Deploy with:

wrangler deploy

When Workers fits:

• Your MCP server handles stateless tool calls (search, transform, lookup)
• Traffic is bursty or unpredictable
• You want global edge distribution without managing infrastructure
• Cost sensitivity matters — the free tier covers many use cases

Watch out for:

• No stdio transport. Workers respond to HTTP requests only
• No persistent WebSocket connections (Durable Objects can bridge this, but adds complexity)
• CPU time limits (50ms on free, 30s on paid) restrict heavy computation
• No filesystem access — all state goes through KV, D1, or R2

VPS: full control, full responsibility

A VPS gives you a Linux machine where you install what you want and run what you want. For MCP servers, this means every transport works, every runtime is available, and you control the entire stack.

Why it works for MCP:

Some MCP servers need things that managed platforms restrict. Spawning child processes, running CLI tools as part of tool execution, maintaining long-lived WebSocket connections, or accessing GPU resources. A VPS has no opinions about what your server does.

Basic deployment (Ubuntu, Node.js):

# SSH into your server
ssh root@your-server-ip

# Install Node.js
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt-get install -y nodejs

# Clone and run
git clone https://github.com/your-org/your-mcp-server.git
cd your-mcp-server
npm install

# Run with systemd for persistence
cat > /etc/systemd/system/mcp-server.service << 'EOF'
[Unit]
Description=MCP Server
After=network.target

[Service]
Type=simple
User=mcp
WorkingDirectory=/opt/your-mcp-server
ExecStart=/usr/bin/node server.js
Restart=always
Environment=PORT=3000

[Install]
WantedBy=multi-user.target
EOF

systemctl enable mcp-server
systemctl start mcp-server

Put nginx or Caddy in front for TLS termination. Caddy is simpler — it handles certificates automatically:

your-mcp-server.example.com {
    reverse_proxy localhost:3000
}

When a VPS fits:

• Your server runs CLI tools, spawns processes, or needs GPU access
• You want predictable monthly costs regardless of traffic
• You need full control over the runtime environment
• You are deploying multiple MCP servers on one machine

Watch out for:

• You handle updates, security patches, and monitoring yourself
• No automatic scaling — if traffic spikes, your server slows down
• Initial setup takes longer than managed platforms
• Backups and disaster recovery are your problem

How to choose

Start with what your MCP server actually does:

Stateless tool calls (search, fetch, transform)? Cloudflare Workers. You get global edge distribution and pay-per-request pricing. Most MCP servers that wrap an external API fall into this category.

Stateful server with database access? Railway. Attached databases, persistent filesystem, and zero-config deploys. Good for MCP servers that maintain conversation context, cache results, or write to storage.

Heavy computation, CLI tools, or custom runtimes? VPS. Nothing restricts what you can run. Good for MCP servers that wrap local tools like ffmpeg, pandoc, or machine learning models.

Multiple MCP servers? VPS or Railway. A single VPS can host several lightweight MCP servers behind one reverse proxy. Railway lets you deploy each as a separate service with independent scaling.

FAQ

Q: Can I use stdio transport with a remote MCP server? A: Not directly. Stdio requires a local process that reads from stdin and writes to stdout. For remote deployments, use SSE or WebSocket transport. If your agent only supports stdio, run a local proxy that converts stdio to HTTP calls against your remote server.

Q: Which option is cheapest for a low-traffic MCP server? A: Cloudflare Workers. The free tier handles 100,000 requests per day, which covers most MCP servers that are not serving heavy production traffic. A Hetzner VPS starts at around $4/month if you prefer a fixed cost. Railway’s usage-based pricing means you pay for idle time even when nobody is calling your server.

Q: Do I need TLS for MCP servers? A: Yes, for any remote deployment. MCP clients expect HTTPS for SSE endpoints. Railway provides TLS automatically. Cloudflare Workers run on Cloudflare’s edge, so TLS is built in. For a VPS, use Caddy (automatic certificates) or certbot with nginx.