Custom domains

By default a published gateway answers on a platform-assigned endpoint. To serve it on your own hostname — mcp.acme.com instead of a generated URL — attach a custom domain. Ownership is proven with a DNS record so no one can claim a name they don't control.

1. Add the domain and prove ownership

mcpg cloud domains add mcp.acme.com

This returns a DNS-TXT challenge. Create that TXT record at your DNS provider, then verify:

mcpg cloud domains verify mcp.acme.com
mcpg cloud domains list             # see status of every domain

2. Attach it to an instance

Point a published gateway at the verified hostname with --custom-hostname on publish (re-publishing the same name updates in place):

mcpg cloud publish edge --config gw.yaml --custom-hostname mcp.acme.com

Add a CNAME (or the address record the platform gives you) from mcp.acme.com to the instance's endpoint so client traffic routes to it.

Your domain becomes the instance's identity

Once a verified domain is attached, it is not merely another way in — it is what the instance IS. The platform advertises it and nothing else:

• governance.access.resource_metadata.resource becomes https://mcp.acme.com/mcp, so an OAuth-capable client reading /.well-known/oauth-protected-resource sees your domain and asks its authorization server for a token bound to it. One resource, one audience.
• The endpoint mcpg cloud instances reports, and the browser hand-off link, name your domain.
• The platform hostname keeps resolving, keeps its certificate and stays the address the platform routes and migrates on — but the gateway no longer serves MCP there. A request on it is answered 308 to the same path on your domain, so a client that arrives at the old address ends up at the right one and can never obtain a token for a hostname the gateway would refuse.

These keys are written by the platform at publish time and overwrite anything the config carries — a tenant cannot claim another instance's audience.

Two things stay yours:

• Which authorization server: resource_metadata.authorization_servers, or nothing when governance.access.oidc_oauth names the provider — the document derives it from the issuer then.
• Which audiences the verifier accepts: clients get a token bound to https://mcp.acme.com/mcp, so the verifier must accept that audience:

governance:
  access:
    jwks:
      url: https://idp.acme.com/.well-known/jwks.json
      issuer: https://idp.acme.com
      audience: https://mcp.acme.com/mcp

With oidc_oauth, set the same value in the provider's audiences. Keep the platform endpoint in audiences as well while you migrate, if tokens minted for it are still in circulation — a token bound to any accepted audience verifies, and the hostname the request arrived on does not narrow the check.

Remove a domain

mcpg cloud domains remove mcp.acme.com

Where to go next

• Publish a config — where --custom-hostname is set.
• mcpg cloud reference — the full domains command surface.