Deploying Claude Connectors to Production: Host Your MCP Server on Cloudflare, Vercel, or Any Platform

TL;DR: Your Claude Connector needs HTTPS and a public URL. Cloudflare Workers, Vercel, Railway, and plain VPS all work. Use Streamable HTTP transport (not SSE). Allowlist both claude.ai and claude.com OAuth callback URLs. Test locally with sunpeak first, deploy to your platform, then add the URL in Claude Settings.

You built a Claude Connector. It runs on localhost, and you have tested it with sunpeak’s inspector or through ngrok. Now you want to put it somewhere permanent so Claude can reach it without a tunnel running on your laptop. This post covers the hosting options, requirements, and gotchas for deploying a Claude Connector MCP server to production.

What Claude Needs From Your Server

Claude connects to your MCP server over HTTPS using the Streamable HTTP transport. Your server must:

1. Accept POST requests at a /mcp endpoint. This is the standard MCP path. Claude sends JSON-RPC 2.0 messages to this endpoint.
2. Respond over HTTPS. No exceptions. Claude will not connect to HTTP endpoints.
3. Stay available. Claude makes tool calls during conversations. If your server is down or takes too long to respond, the tool call fails and Claude tells the user.
4. Handle concurrent requests. Multiple Claude users can trigger tool calls at the same time if your connector is shared or in the Connectors Directory.

If your connector uses OAuth, your server also needs to handle the authorization flow and token exchange. More on that below.

Choosing a Hosting Platform

Any platform that serves HTTPS traffic works. Here are the options developers use most, with trade-offs for each.

Cloudflare Workers

Cloudflare Workers run JavaScript/TypeScript at the edge across 300+ data centers. Cold starts are near zero because Workers use V8 isolates instead of containers.

Good for: Connectors that call external APIs, do light computation, or serve as a proxy to your backend. The free tier covers 100,000 requests per day, which handles most connectors easily.

Watch out for: Workers have a 10ms CPU time limit on the free plan (50ms on paid). If your tool handler does heavy computation, like parsing large files or running complex transformations, you will hit this. Offload heavy work to a separate service and have the Worker call it.

Deploy with:

npx wrangler deploy

Your connector URL will look like https://your-connector.your-account.workers.dev/mcp.

Vercel

Vercel’s edge and serverless functions work for MCP servers, especially if your connector is part of a Next.js project. Vercel handles HTTPS and domain configuration automatically.

Good for: Teams already using Vercel for their web app. You can colocate your connector with your frontend.

Watch out for: Serverless functions have cold starts that can add 200-500ms on the first request after idle. For connectors that users call frequently, this is fine. For rarely-used connectors, cold starts can feel slow. Vercel’s Fluid Compute mode helps with this on Pro plans.

Deploy with:

vercel deploy --prod

Railway

Railway gives you a persistent server that runs continuously. No cold starts, no CPU time limits, no edge function constraints. You push code and Railway runs it.

Good for: Connectors that need persistent connections, background jobs, or in-memory caching. Also good if your connector is written in Python, Go, or another language that does not run on edge platforms.

Watch out for: Railway’s free tier gives $5 of credit per month. A lightweight Node.js server uses about $2-3/month, so you might need a paid plan for higher traffic. Railway does not have edge distribution, so your server runs in one region.

Deploy with:

railway up

Render

Similar to Railway. Push code or a Dockerfile, get a running server with HTTPS. Render has a free tier for web services (with a spin-down after 15 minutes of inactivity).

Good for: Simple connectors where you want managed hosting without thinking about infrastructure.

Watch out for: Free-tier services spin down after inactivity, which means the first request after idle takes 30-50 seconds while the service restarts. This is too slow for a Claude Connector in practice. Use a paid instance ($7/month) to keep the service running.

VPS (Hetzner, DigitalOcean, Linode)

A virtual private server gives you full control. Run whatever runtime you want, keep state in memory, and manage the server yourself.

Good for: Connectors with special requirements. Database access, GPU workloads, or compliance constraints that rule out shared hosting.

Watch out for: You handle HTTPS yourself (use Caddy or nginx with Let’s Encrypt), uptime monitoring, and restarts. More operational work than managed platforms.

A basic setup with Caddy as a reverse proxy:

your-connector.example.com {
    reverse_proxy localhost:3000
}

Caddy provisions Let’s Encrypt certificates automatically. Your Claude Connector URL is then https://your-connector.example.com/mcp.

Setting Up OAuth for Production

If your connector accesses user data, you need OAuth. The development flow with ngrok and the production flow are mostly the same, but there are two things to get right.

Callback URLs

Claude uses two domains. Allowlist both as redirect URIs in your OAuth provider:

• https://claude.ai/api/mcp/auth_callback
• https://claude.com/api/mcp/auth_callback

Missing one of these is the second most common reason Directory submissions get rejected.

Token Storage and Refresh

Claude sends the user’s access token with each tool call. Your server needs to handle token expiry gracefully. If the token is expired, use the refresh token to get a new one. If the refresh token is also expired, Claude will prompt the user to re-authenticate.

Store OAuth client secrets in environment variables, not in code. Every hosting platform has a way to set secrets:

# Cloudflare Workers
wrangler secret put OAUTH_CLIENT_SECRET

# Vercel
vercel env add OAUTH_CLIENT_SECRET

# Railway
railway variables set OAUTH_CLIENT_SECRET=your-secret

For a deeper walkthrough of the OAuth flow and grant types, see the dedicated auth post.

Streamable HTTP vs SSE

Claude supports two MCP transports: Streamable HTTP and SSE (Server-Sent Events). Use Streamable HTTP.

Streamable HTTP works with standard POST requests to your /mcp endpoint. Every hosting platform supports this, including serverless platforms where persistent connections are unreliable. Your server receives a POST, processes the tool call, and returns the response.

SSE requires a persistent connection between Claude and your server. This works on traditional servers but can cause problems on serverless platforms that terminate idle connections. Anthropic has indicated that SSE support may be deprecated in favor of Streamable HTTP.

If you are using the MCP TypeScript SDK, Streamable HTTP is the default transport for remote servers.

Production Checklist

Before you point Claude at your deployed server, run through this list:

Server basics:

• Server responds to POST requests at /mcp
• HTTPS is working (test with curl https://your-url/mcp)
• Server handles the MCP initialize handshake
• All tools return responses within 5 minutes (Claude’s timeout)
• Server handles concurrent requests

Auth (if applicable):

• Both claude.ai and claude.com callback URLs are allowlisted
• OAuth client secret is in environment variables, not hardcoded
• Token refresh works when access tokens expire
• Authorization code grant with PKCE is configured (Claude does not support client credentials flow)

For Directory submission:

• Every tool has readOnlyHint or destructiveHint annotations
• Privacy policy is published and linked
• Documentation includes at least three usage examples
• Test account with sample data is ready for reviewers

Monitoring:

• Error logging is enabled so you can see failed tool calls
• You have a way to check uptime (even a simple health check endpoint)
• You know how to check server logs on your hosting platform

Testing Before and After Deployment

Test locally first. Run sunpeak dev to start your connector in the sunpeak inspector, which replicates the Claude runtime at localhost:3000. You can test every tool, verify UI rendering, and use simulation files for deterministic test cases, all without a Claude account.

After deploying, add your production URL as a custom connector in Claude Settings > Connectors. Make sure to include the /mcp path. Then open a new Claude conversation, enable the connector, and test each tool. Compare the behavior against what you saw locally.

If something works locally but fails in production, check:

1. The URL is correct. The most common mistake is forgetting /mcp at the end.
2. Environment variables are set. API keys and secrets that work locally might not be configured on the hosting platform.
3. Cold starts are within limits. If your first tool call after deploy takes 30+ seconds, your hosting platform might need a keep-alive or a paid tier.
4. Tool result size is under 25,000 tokens. Claude truncates results that exceed this limit. See the debugging guide for details.

Example: Deploying to Cloudflare Workers

Here is a minimal example of deploying a Claude Connector to Cloudflare Workers using the MCP TypeScript SDK.

Your wrangler.toml:

name = "my-connector"
main = "src/index.ts"
compatibility_date = "2026-03-01"

Your src/index.ts:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { createMcpHandler } from '@anthropic-ai/mcp-cloudflare';
import { z } from 'zod';

const server = new McpServer({
  name: 'my-connector',
  version: '1.0.0',
});

server.tool(
  'get-status',
  'Get the current status of the service',
  { service: z.string().describe('Service name to check') },
  async ({ service }) => ({
    content: [{ type: 'text', text: `${service} is operational` }],
  })
);

export default createMcpHandler(server);

Deploy:

npx wrangler deploy

Add https://my-connector.your-account.workers.dev/mcp in Claude Settings > Connectors. That is it. Your connector is live.

What Comes After Deployment

Once your connector is deployed and working:

• Share with your team. On Team and Enterprise plans, an org admin can add the connector URL in Organization Settings > Connectors so everyone on the team can use it.
• Submit to the Directory. If your connector is useful to the broader Claude community, submit it to the Connectors Directory. Review takes about two weeks.
• Monitor usage. Most hosting platforms have built-in request logging and metrics. Watch for error rates, slow tool calls, and token limit issues.
• Update without downtime. Cloudflare Workers, Vercel, and Railway all support zero-downtime deployments. Push new code and the platform rolls it out automatically.