Custom Domains and Branded Hosts

Where you see this in the app

The branded-host flow lives in Settings → Custom domains.

This is the page where a user requests a hostname, gets DNS instructions, and later binds the host so it becomes the branded public surface.

When custom domains are available

The page can be unavailable in environments where the feature flag is off.

From an end-user perspective, that means the feature is environment-dependent. If the page says custom domains are disabled in the current environment, there is nothing to configure yet on that host.

Hostname, referral, and DNS steps

The form exposes these main fields:

The DNS instructions then tell the user to add:

• a CNAME that points traffic to the gateway,
• a TXT record used for domain verification.

The app is explicit that root/apex domains are not supported and that the expected shape is a subdomain you control.

Status labels and Bind step

The domain cards show a status badge and a Bind action when the host is not fully live yet.

Bind is the step that checks DNS and issues the managed TLS certificate.

What changes once bound

Once a domain is bound successfully, the branded host becomes the public-facing home for supported pages on that creator or publisher brand.

The practical effect is:

• visitors see the branded hostname instead of only the default platform host,
• traffic can inherit the default referral code attached to that host,
• the experience feels like a branded hub rather than a generic marketplace page.

This is not just a cosmetic alias. It is the branding layer for the user's public presence on the platform.