By the Octri team · Updated
How to host a remote MCP server: deploy, secure and scale it
A local MCP server is forgiving. One process knows its own memory, your terminal starts it, and a failed experiment can be fixed by restarting it. A remote server has to survive retries, different clients, several instances and an authorization boundary. Most of the important engineering begins after the first successful tool call.
Hosting a remote MCP server means turning a working implementation into a service with one stable HTTPS address and predictable security behavior. The public URL is the easy part. Deciding who can call it and what happens after deployment changes is the real work.
How do you host a remote MCP server?
Use the Streamable HTTP transport supported by your target protocol revision and SDK. Put a TLS-terminating proxy or managed edge service in front, restrict accepted hostnames and origins, and require appropriate authorization for private data. Make the server stateless across requests when possible, with authoritative data in your API or a shared store.
A health check should test the service without exposing its tool catalog to unauthenticated callers. Separately, run an authenticated integration check that actually lists and calls a safe tool. A healthy container is not the same thing as a healthy MCP connection.
Where to run it
Containers suit teams that already deploy APIs this way. Edge or serverless runtimes can suit lightweight, bursty tools, provided the platform supports your transport and execution duration. Managed MCP hosting reduces infrastructure work but should still let you inspect authentication, upstream credentials, limits and logs.
There is a useful firsthand engineering account from Cloudflare. In their March 2025 post on remote MCP hosting, Brendan Irvine-Broque, Dina Kozlov and Glen Maddern described building support around the problems local servers did not have: OAuth, remote transport and deployment. They introduced reusable components rather than asking each developer to invent the same plumbing. That story is a good reminder that moving from “works on my laptop” to “any authorized client can connect” is mainly about infrastructure and identity.
Those components and the protocol have evolved since that post. The durable lesson is the separation of concerns: application tools should not contain ad hoc implementations of TLS termination, authorization discovery and deployment lifecycle.
The check a container turns off
When you bind a local server to loopback, some SDKs enable conservative origin and host checks by default. When you change the bind address to 0.0.0.0 inside a container, those checks may need explicit configuration. Never assume the SDK's development defaults remain in force.
The MCP transport specification requires attention to Origin validation to mitigate DNS-rebinding scenarios. An incoming foreign browser origin should not be able to call a sensitive local or remote tool just because the endpoint is reachable. Validate Host against the public domain and Origin when one is present, and verify how your reverse proxy forwards them.
# Configuration sketch: use the exact API for your installed SDK revision.
from mcp.server.transport_security import TransportSecuritySettings
security = TransportSecuritySettings(
enable_dns_rebinding_protection=True,
allowed_hosts=["mcp.example.test"],
allowed_origins=["https://app.example.test"],
)Requests from non-browser clients may have no Origin header. Treat absence and a deliberately wrong origin according to your server's protocol rules; do not build a blanket rule that blocks every tool client without a browser origin.
A container image
A good image pins dependencies, runs without root privileges and prints operational logs to the expected stream. Credentials should enter through your secret manager, not through the image or repository.
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY inventory_server.py .
ENV PORT=8000
USER nobody
CMD ["python", "inventory_server.py"]This is packaging, not a complete deployment. Make sure the server binds to the port and interface your platform assigns, that the expected MCP path is exposed, and that the instance gets its authorization configuration at runtime. Roll out a new image alongside the previous one and validate client behavior before sending all traffic to it.
Scaling across instances
If two requests land on different instances, in-memory counters, approval records and unfinished jobs cannot be assumed to exist on both. Put durable state in a shared database or the upstream API and make rate limits atomic across workers.
A tool that creates an invoice must be safe to retry when a connection drops after the API accepts the request. Carry an idempotency key from a trusted workflow boundary through to the API. Treat long-running tasks as distinct jobs with identifiers rather than depending on one process staying alive indefinitely.
The protocol's session behavior differs between revisions. Confirm the behavior of the exact MCP revision and client mix you deploy before implementing stateful session affinity as a default.
Sign-in, limits and the rest
Remote private tools need a user identity and an access decision. With MCP OAuth, the client discovers an authorization server from Protected Resource Metadata and gets a token issued for the MCP resource. The server checks its signature or introspection, audience, expiration and scopes. The incoming token must not simply be forwarded to a different upstream API.
Add rate limits by authenticated user and tool, record writes with correlation IDs, and keep sensitive arguments out of logs. If the host platform scales automatically, confirm its outgoing connections to your API obey network restrictions and its cold starts meet your client timeouts.
Checklist before you share the URL
Verify HTTPS, the correct endpoint path, proxy headers, Host and Origin validation, token audience checks, appropriate scopes, non-root execution, secrets storage, multi-instance behavior, retry/idempotency handling, logging, rate limits and a real-client smoke test. Test both denial and success before sharing the URL with customers.
A remote MCP server is a production API-facing service. Treat its release process and incident response accordingly.
Hosted MCP servers with Octri
Octri MCP Studio can host or package MCP tools generated from an OpenAPI spec. Choose the deployment mode that fits your network and authorization requirements, then verify the resulting endpoint with the same checks you would apply to a hand-written server.
A managed surface removes infrastructure chores but does not remove ownership of API permissions, tool descriptions or the impact of an agent's write. Those remain product decisions.