Intermediate8 min
Remote MCP Servers and Production Deployment
Remote MCP servers are HTTP endpoints that your whole team connects to — deployed once, used everywhere. This article covers architecture, authentication, hosting options, and the operational concerns that separate a working prototype from a production-grade team tool.
Quick Reference
- →Remote config: {type: "remote", url: "https://...", token: "${MCP_AUTH_TOKEN}"}
- →Deploy to Railway, Render, or any HTTP server — any Express/FastAPI instance works
- →Authentication: Bearer token injected from the token field, never hardcoded
- →RFC 9728 OAuth works for remote servers that need user-level auth
- →Key advantage: one deploy, the entire team connects — no per-machine install
- →Monitor availability — Claude Code handles server unavailability gracefully but silently
- →TLS required for any remote server holding credentials or sensitive data
Remote vs stdio — When Remote Makes Sense
stdio MCP servers run on your local machine as child processes. Remote MCP servers are HTTP endpoints you connect to over the network. Remote servers make sense when:
- ▸The whole team needs the same tools without per-machine setup
- ▸The server needs access to resources that should not be on every developer's machine (production read-replicas, internal APIs behind a VPN)
- ▸The server requires server-side secrets that cannot be distributed to individual machines
- ▸You want to version and deploy the server independently of individual developer setups
Team distribution is the key benefit
A remote MCP server deployed once becomes available to every team member the moment they add the URL to their config. A stdio server requires each developer to install, configure, and maintain the server locally.