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

TL;DR: Deploy a Claude Connector as a public HTTPS MCP server, usually at /mcp, using Streamable HTTP. Make sure public DNS resolves to routable IPv4 addresses, avoid redirects across hosts, register https://claude.ai/api/mcp/auth_callback for OAuth, and test the deployed URL before users see it. Use sunpeak inspect against both localhost and production so you can catch transport, auth, UI, and tool errors without repeating manual Claude test loops.

You built a Claude Connector. It runs locally, your tools return useful data, and now Claude needs to reach it without a tunnel running on your machine.

This guide covers the production path: what Claude expects from a remote MCP server, how to choose a host, how to set up OAuth, what to test before launch, and what to monitor after launch. The examples focus on Claude Connectors, but most of the deployment work applies to any remote MCP server or cross-host MCP App.

What Claude Needs From Your Server

Claude Connectors are remote MCP servers. For a production deployment, your server needs:

1. A public HTTPS URL, such as https://connector.example.com/mcp.
2. A Streamable HTTP MCP endpoint that accepts JSON-RPC messages.
3. A correct MCP initialize response.
4. Stable tool, resource, and prompt metadata.
5. Auth that works from hosted Claude surfaces, not only from your laptop.
6. Logs that let you debug failed connection attempts.

The public URL detail matters. Claude reaches remote connectors from Anthropic infrastructure. If your hostname resolves to 10.x.x.x, 172.16.x.x, 192.168.x.x, loopback, link-local, carrier-grade NAT, or only IPv6 records, Claude can fail before your application sees a request. A connector can work in curl, Claude Code, or a local inspector and still fail in claude.ai if public DNS points somewhere Claude cannot reach.

Before blaming your MCP code, check the network path:

dig +short connector.example.com
curl -i https://connector.example.com/mcp

Every public DNS answer should be globally routable. Your /mcp endpoint should not redirect to another host. If you have a CDN, WAF, bot filter, or rate limiter in front of the server, make sure it allows Claude’s outbound traffic to hit your MCP and OAuth paths.

Use Streamable HTTP for New Deployments

Use Streamable HTTP for new remote connectors. The current MCP spec defines Streamable HTTP as one of the standard transports and says it replaces the older HTTP plus SSE transport from the 2024-11-05 protocol version.

For deployment, this means your server should expose one MCP endpoint path, usually /mcp, and handle HTTP POST requests containing JSON-RPC messages. Depending on the request, the server can return a JSON response or a text/event-stream response. If your server assigns a session ID during initialization, clients include it on later requests through the Mcp-Session-Id header.

A production Streamable HTTP server should also:

• Validate the Origin header when browser-originated requests can reach it.
• Bind local dev servers to 127.0.0.1, not every network interface.
• Require auth for private data and write actions.
• Handle missing or unsupported MCP-Protocol-Version headers cleanly.
• Return clear HTTP errors for invalid requests.

If you still support old SSE clients, keep that compatibility path separate and documented. Do not make the production connector depend on a long-lived SSE connection unless you have a host-specific reason, because serverless platforms and proxies often handle idle streams differently.

Choosing a Hosting Platform

Any platform that can expose a reliable HTTPS endpoint can host a Claude Connector. The right choice depends on your runtime, traffic, auth, and how much infrastructure you want to manage.

Cloudflare Workers

Cloudflare Workers are a good fit for lightweight TypeScript connectors that call external APIs, validate requests, transform data, and return tool results. They start fast, run near users, and pair well with Cloudflare’s OAuth and edge security tools.

Good for:

• API wrapper connectors
• Read-heavy tools
• Lightweight MCP Apps
• Connectors that benefit from edge routing

Watch out for:

• CPU limits for heavy parsing or data transformation
• Large dependency bundles
• Libraries that assume Node-only APIs
• Streaming behavior through any middleware you add

Use Workers when your connector is mostly glue code. If a tool needs expensive processing, push that work to a queue, database job, or backend service and let the Worker coordinate it.

Vercel

Vercel is a strong fit when the connector belongs next to an existing Next.js app or when your team already deploys there. Vercel has specific MCP guidance, handles HTTPS, and gives you preview deployments for testing changes before production.

Good for:

• Next.js teams
• Product apps that already use Vercel
• Serverless tool handlers
• Preview deployments for connector changes

Watch out for:

• Cold starts on rarely used functions
• Function duration limits
• Preview deployment protection blocking host tests
• Auth configuration drift between preview and production

If you use previews, test both the preview MCP URL and the production MCP URL. Preview protection is useful for humans, but AI hosts cannot connect through every protection flow.

Railway, Render, Fly.io, and Similar App Hosts

Traditional app hosts are often the least surprising option. You deploy a Node, Python, Go, or containerized MCP server, keep a process running, and expose /mcp over HTTPS.

Good for:

• Long-running servers
• Python or Go connectors
• Background jobs
• In-memory caches
• Connectors that need custom native dependencies

Watch out for:

• Free-tier sleep behavior
• Single-region latency
• Health check paths
• Memory leaks in long-running handlers

If a free service sleeps after inactivity, the first tool call can be too slow. Use a paid always-on instance for customer-facing connectors, or choose an edge/serverless platform that starts quickly.

VPS With Caddy or nginx

A VPS gives you the most control. It is a good choice when you need private networking, custom binaries, special compliance controls, or predictable long-running processes.

Good for:

• Custom runtime requirements
• Databases on the same private network
• Strict operational control
• High-memory or CPU-heavy tools

Watch out for:

• TLS setup
• Process restarts
• OS updates
• Firewall rules
• Backups and monitoring

A minimal Caddy config looks like this:

connector.example.com {
  reverse_proxy localhost:3000
}

Caddy provisions and renews TLS certificates automatically. Your Claude Connector URL is https://connector.example.com/mcp if your app listens on localhost:3000 and serves MCP at /mcp.

Production OAuth Setup

If your connector accesses user data, implement OAuth. Authless public tools can work, but most useful connectors need user consent, scoped access, token refresh, and revocation.

For hosted Claude surfaces, register this redirect URI:

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

If you also support Claude Code, support native loopback redirects on localhost or 127.0.0.1 with a variable port. That means your authorization server should match the loopback redirect origin and path while allowing the port to change.

Use authorization code with PKCE. Do not rely on client credentials as the user-facing connector flow because each user still needs consent for their own data. If your authorization server supports Dynamic Client Registration, test that discovery and registration work from a clean Claude connection. If it does not, check Claude’s current alternatives before submitting to the directory.

Store secrets through your host’s secret manager:

# Cloudflare Workers
wrangler secret put OAUTH_CLIENT_SECRET

# Vercel
vercel env add OAUTH_CLIENT_SECRET

# Railway
railway variables set OAUTH_CLIENT_SECRET=your-secret

Also test token refresh. A connector that works for the first hour and then fails every tool call has an auth bug, not a deployment bug.

Environment Variables and Config

Production failures often come from config that exists locally but not on the host. Before launch, make a short config inventory:

• API keys and OAuth client secrets
• Public base URL, such as https://connector.example.com
• OAuth issuer, authorization, token, and JWKS URLs
• Database connection strings
• Webhook signing secrets
• Feature flags
• Allowed origins
• Log level

Do not derive your public URL from request headers unless you fully trust every proxy in front of the app. A bad Host or X-Forwarded-Host value can break OAuth discovery, redirect URIs, and generated resource links.

Deployment Checklist

Run this before pointing real users at the server.

Network and Transport

• /mcp is public over HTTPS.
• Public DNS returns globally routable IPv4 addresses.
• The server does not redirect /mcp to a different host.
• POST /mcp handles MCP initialize.
• Streamable HTTP responses use correct Content-Type values.
• Unsupported methods and malformed JSON return clear errors.
• Reverse proxies do not buffer or break streaming responses.

Auth

• OAuth discovery documents are public if your flow needs them.
• https://claude.ai/api/mcp/auth_callback is registered.
• PKCE with S256 works.
• Token refresh works after access token expiry.
• Secrets are stored in the host’s secret manager.
• Write scopes are narrow and explained in the consent screen.

Tools and Data

• Tool names, descriptions, schemas, and annotations match real behavior.
• Read tools and write tools are separate.
• Tool results stay within host limits.
• Empty, partial, and error states return useful messages.
• External API timeouts are shorter than Claude’s tool-call timeout.

Directory Readiness

• Public docs include setup, example prompts, and troubleshooting.
• Privacy policy is live.
• Support contact is live.
• Test account has realistic data.
• MCP Apps have 3 to 5 PNG screenshots at least 1000px wide.
• ui/open-link destinations are declared as allowed link URIs when needed.

Test Locally, Then Test the Deployed URL

Start with local tests. In a sunpeak project, run:

pnpm test
pnpm dev

Use the local inspector to test tool results, UI resources, display modes, themes, loading states, error states, and simulation fixtures. This catches most issues before you spend time in a real host.

Then inspect the deployed server directly:

npx sunpeak inspect --server https://connector.example.com/mcp

This step is useful because it exercises the production URL, production secrets, production network path, and production build. If local tests pass but sunpeak inspect fails against the deployed URL, check environment variables, auth discovery, DNS, WAF rules, and whether the host is serving the right path.

Finally, add the same production URL as a custom connector in Claude and test it with realistic prompts. For Team and Enterprise plans, an owner adds custom connectors in organization settings, then users connect and enable them. For individual plans that support custom connectors, add the connector from Claude’s connector settings.

What to Log and Monitor

Do not wait for user reports to find production failures. Track enough data to answer what happened without storing more user data than you need.

Log:

• Request ID
• Timestamp
• MCP method, such as initialize or tools/call
• Tool name for tool calls
• Auth subject or tenant ID, if safe to store
• HTTP status
• Latency
• Upstream API status
• Error code

Monitor:

• Connection failures
• OAuth failures
• Initialize failures
• Tool-call latency
• Timeout rate
• Non-2xx responses
• Upstream API errors
• Result sizes
• Cold-start latency

When Claude shows a connector failure, also check whether the UI includes a reference ID. Pair that with your server logs from the same time window. If your logs show no request at all, the issue is probably DNS, WAF, private network routing, or a host-level redirect.

Example Cloudflare Workers Shape

The exact code depends on your MCP SDK and framework, but the deployment shape is simple: export a Worker handler, serve MCP at /mcp, and keep secrets in Workers secrets.

name = "my-connector"
main = "src/index.ts"
compatibility_date = "2026-05-25"

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';

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

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

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const url = new URL(request.url);

    if (url.pathname !== '/mcp') {
      return new Response('Not found', { status: 404 });
    }

    return handleMcpRequest(server, request, env, ctx);
  },
};

Deploy:

pnpm exec wrangler deploy

Then test the live endpoint:

npx sunpeak inspect --server https://my-connector.your-account.workers.dev/mcp

Replace handleMcpRequest with the handler from the MCP framework you use. The important production checks are the same no matter which helper wraps the protocol: one public /mcp endpoint, correct Streamable HTTP behavior, working auth, and logs for failures.

Cross-Host Notes for MCP Apps

If your Claude Connector also renders UI, you are deploying an MCP App. That changes what you need to test:

• Host capability detection, because some hosts can call tools but not render UI.
• Content Security Policy, because app iframes need explicit permissions for external APIs and assets.
• Resource URLs, because hosts cache resources aggressively.
• Display modes and screen widths, because the same app may appear inline, expanded, or picture-in-picture depending on host support.
• External links, because hosts may ask users to confirm links unless the destination is declared.

This is where sunpeak helps beyond a basic protocol smoke test. The inspector can render tools and resources in local host replicas, run simulations for deterministic states, and drive E2E tests in CI. Use that before you submit a directory connector or connect a production app to users.

What Comes After Deployment

Once the connector is live:

• Add it as a custom connector and test every tool with real account data.
• Share it with your organization if it is internal.
• Submit it to the Connectors Directory if it is public.
• Add uptime checks and error alerts.
• Keep a rollback path for server and OAuth changes.
• Re-run local, inspector, and real-host tests before changing tool schemas or auth behavior.

A production-ready Claude Connector gives Claude a stable public MCP endpoint, gives users a clean consent flow, and gives you enough visibility to fix failures quickly.