Deploying remote MCP servers and publishing to registries

0:00 Remote deployment and registries

A server on your laptop helps you. A remote server helps your whole company, or your customers. In this lesson you'll learn how to deploy remote MCP servers properly, serve both old and new protocol clients, and publish to registries so people can find you.

0:20 Why remote changes things

Why does remote deployment change everything? Because the moment your server has a URL, it stops being your tool and becomes a service. Other people depend on it, attackers can find it, and it needs to stay up while you sleep. Think of the difference between cooking dinner at home and running a food stall at a festival. Same recipes, but now you need hygiene certificates, a queue, enough stock, and a plan for when it rains. That's the production checklist in this lesson.

0:57 Deployment targets

Where should it run? Container platforms like Cloud Run, AWS Fargate, Azure Container Apps or Kubernetes are the standard choice. Serverless functions suit stateless servers well, but watch cold starts and timeouts, and use the tasks extension for long work. Edge runtimes work nicely with the TypeScript handler, which is a standard fetch function. And many enterprises put an MCP gateway in front of all their servers for central auth, rate limits and logging.

1:29 Production checklist

Here's the production checklist. TLS everywhere. OAuth with metadata, audience checks and scopes per tool. No in memory session state, with explicit handles for multi step flows and shared state in a database. Idempotent writes, because broken streams get re issued, not resumed. Timeouts, payload limits, result caps and pagination. Rate limiting per user and per tool at the gateway, using the method and name headers. Cache hints and deterministic tool order. Tracing with OpenTelemetry and clean logs. And versioning with a changelog.

2:05 Serve both protocol eras

During the protocol transition, serve both eras. The TypeScript version two handler serves older clients statelessly from the same factory by default, and the Python version two SDK supports every revision. Before announcing an upgrade, test with at least one older client and one current host. Your users won't all upgrade on the same day.

2:29 Simple example: the vanishing draft

A simple example of why statelessness matters. You deploy one copy of your server, and a multi step flow stores a draft in memory between two tool calls. It works perfectly. Then traffic grows and you scale to three copies. Now the second call often lands on a different copy that has never seen the draft, and users get, draft not found. The fix: store the draft in a database and return a draft id that the model passes to the next tool. Any copy can then continue the flow.

3:08 The MCP Registry

Now discovery. The official MCP Registry, currently in preview, is a metadata catalog for publicly accessible servers. You publish a server dot json file describing where to get or reach your server, like an npm or PyPI package or a remote URL, how to run it, and a description. Namespaces are verified through GitHub or your own domain. The registry is mainly consumed by marketplaces and aggregators, not directly by hosts, and it doesn't list private servers. For internal servers, run a private catalog or use your platform's admin managed connector list.

3:48 Example: Dubai SaaS integration

A worked example. A social media scheduling company in Dubai wants customers to use it from Claude, ChatGPT and IDE agents. It builds a TypeScript server with eight workflow tools, deploys it behind an API gateway with OAuth through its existing identity service and three scopes, requires step up for publishing posts, publishes a server dot json under its own domain, and writes a public connection guide, a changelog and a security page. Then it monitors adoption by client and errors by tool.

4:24 Hands-on: containerize

The hands on section containerizes a Python server. Inside a container behind a load balancer, binding to all interfaces is appropriate. For local development, keep it on the loopback address. Put authentication in front, either the SDK's auth settings or your gateway, and never expose an unauthenticated server that can write data. For TypeScript, the Express helper still validates host headers when you bind publicly, as long as you list your allowed hosts.

4:56 Pitfalls and metrics

Avoid four pitfalls: in memory state that breaks with more than one replica, publishing to a public registry without auth, rate limits or a security page, breaking tool changes without versioning or notice, and forgetting older clients during the transition. Measure availability and latency per tool, error rates by client type and protocol version, active users per host, and how fast you can roll back.

5:24 Public listing and security

A common worry: will publishing to the public registry expose my server to attackers? The registry lists metadata, but a public server is discoverable anyway once people use it. What protects you is the same as for any public API: strong authentication, least privilege scopes, rate limits, input validation, monitoring and a security contact. Publishing responsibly means having those in place first, plus clear documentation of what data your server touches.

5:55 Deeper: the SaaS launch (illustrative)

Let's deepen the Dubai SaaS vendor's launch. In the first quarter after listing its server, illustrative figures, a large share of new connections came from Claude and ChatGPT users, with a smaller share from IDE agents. Errors clustered on one tool, best time suggestions, which timed out for customers with years of history; the team added pagination and a task based path for large accounts. Their security page answered the most common procurement questions, so enterprise deals stopped stalling on questionnaires. And because the server was stateless, a traffic spike after a product announcement just meant the platform added replicas automatically.

6:39 Watch me do it: container + server.json

Watch me do it. Let's walk through the Dockerfile and a server dot json. The image starts from Python three twelve slim, copies the project and lock file, installs uv and syncs dependencies without dev packages, then copies the server. The command imports the server module and runs Streamable HTTP on all interfaces inside the container, using the port from the environment. I build it, run two containers behind a local load balancer, and send the same multi step flow twice: it succeeds regardless of which container answers, because state lives in the database. Now the registry metadata: server dot json has the schema link, a reverse domain name, a title, a description, a version and a remotes entry of type streamable http with the public URL. With mcp publisher, I log in with GitHub or my domain and publish. For an internal server, I'd put the same metadata in our private catalog instead.

7:46 Try this now

Try this now. Containerize your server with the Dockerfile pattern from the lesson and deploy it to a staging environment with authentication in front. Run two replicas. Test with a current host and, if you can, an older client that speaks an earlier protocol version. Then draft a server dot json file with your server's name, description, version and remote URL, and decide whether it belongs in the public registry or your organization's private catalog.

8:19 Recap

To recap: deploy remote servers statelessly with TLS, OAuth, limits and observability; serve both protocol eras; version your tools; and publish to the right catalog, public or private. Your next step: containerize your server, deploy it to staging with auth in front, test with an older and a current client, and draft its server dot json.