Serving an MCP Server on a Custom Domain: Self-Hosting vs Registry Hosting

Quick answer: Serving an MCP server on your own domain keeps the endpoint under your DNS, TLS, and branding, and removes a dependency on a registry's host. A registry-hosted server is faster to publish and handles the edge infrastructure for you, but the URL lives on the registry's domain. The choice depends on whether you value turnkey hosting and discovery, or ownership of the address, security posture, and long-term portability.

What a custom domain actually changes

An MCP endpoint over streamable HTTP is just an HTTPS URL. When you self-host, that URL is a subdomain you control, such as https://mcp.example.com. When a registry hosts it, the URL is on the registry's domain with a path or identifier for your server. The protocol behavior is the same; what changes is who owns the name in front of it.

Why the domain matters beyond aesthetics

A stable address you own is infrastructure, not vanity. Clients configure the endpoint once, and if you later change the underlying host or move from one gateway to another, the domain stays the same and clients do not need to be reconfigured. On a registry domain, the platform's naming and routing decisions are outside your control. The domain also anchors your security model: your own TLS, your own WAF and rate limits, and a certificate tied to your organization rather than a shared host.

Putting a self-hosted server behind a domain

The typical setup runs the MCP server behind a reverse proxy or managed gateway that terminates TLS on the subdomain and forwards to the service. Here is a representative nginx-style block.

DNS points the subdomain at the host or load balancer, and the certificate is issued for that name. The MCP server itself listens privately on localhost while the gateway owns the public address.

Branding and trust signals

For teams distributing an MCP server to customers, an endpoint on the organization's own domain is a stronger trust signal than a path on a third-party catalog. It makes clear who operates the service and where credentials are being sent, which matters when tools hold broad permissions. On a shared registry domain, users rely on the platform's vetting and the catalog entry. Both can be trustworthy, but the decision changes who appears responsible for the connection and its security.

Where registry hosting wins

A registry removes the operational work entirely: no server to patch, no certificate to renew, no uptime to monitor, and a built-in audience browsing the catalog. For an individual developer or a small team publishing a public tool, that speed is valuable, and the registry handles scaling when many clients connect. The tradeoff is that you accept the platform's domain, limits, and continued availability, and moving away later may require every client to update its endpoint.

A hybrid approach

You can get both benefits by publishing to a registry for discovery while also running the canonical endpoint on your own domain, then pointing clients at the domain you control. Treat the registry as a distribution channel rather than the authoritative address. This keeps the stable URL in your hands and lets you change the backend without disrupting clients, while still gaining catalog visibility. The cost is running two surfaces, so reserve it for servers that justify the extra operations.

DNS, certificate lifecycle, and operational ownership

Owning a domain means owning the operational chain that keeps it reachable. DNS records must resolve to the correct host or load balancer and be updated when infrastructure moves, and the TLS certificate has to be renewed before expiry or clients suddenly fail the handshake. A short time-to-live on the DNS record makes failover faster, while automated renewal removes the most common cause of a self-hosted outage. You also choose the observability stack: uptime probes from outside the network, request logs at the gateway, and alerts when the error rate or latency crosses a threshold. None of this is difficult, but it is ongoing work that a registry-hosted endpoint simply does not require, which is the real cost hidden behind the custom-domain benefit.

Frequently asked questions

Does a custom domain change how the MCP protocol works?

No. The wire protocol and tool calls are identical. The domain only changes the endpoint address and who manages the TLS, routing, and infrastructure in front of it.

Can I move a registry-hosted server to my own domain later?

Yes, but clients configured with the registry URL must be updated to the new address. Owning the domain from the start avoids that migration, which is why a stable endpoint matters for long-lived integrations.

Who is responsible for uptime on a self-hosted endpoint?

You are, including the host, proxy, certificate renewal, and scaling. If you do not want that operational burden, registry hosting or a managed gateway is the simpler path.

Is catalog discovery worth giving up my own domain?

For public tools that need an audience, the registry's built-in discovery is valuable. For internal or customer-facing servers where trust and a stable address dominate, the custom domain is usually worth the extra work.

This is part of the Powerduck vs Smithery: Generating and Hosting MCP Servers — start there for the full comparison of hosting, ownership, and registry versus local-first workflows.