Domains and TLS
The following same-site application hostname is rejected:
equipment.example-org.intrnl.cloud
Untrusted customer-generated applications must use a different registrable domain from the intrnl control plane.
Even with host-only cookies, sibling subdomains remain part of the same browser “site,” which complicates CSRF, cookie-shadowing, origin assumptions, and future browser security policies. Generated applications should not share a site boundary with:
console.intrnl.cloud
auth.intrnl.cloud
mcp.intrnl.cloud
The production arrangement should instead be:
Control plane:
console.intrnl.cloud
auth.intrnl.cloud
mcp.intrnl.cloud
code.intrnl.cloud
Application runtime:
{app}.{organization}.{separate-runtime-apex}
intrnl.run is illustrative; ownership and final domain selection are not established by this document:
equipment-requests.example-org.intrnl.run
The exact runtime apex is a branding/domain decision, but using a separate eTLD+1 is an architectural requirement.
A preview can remain under the same per-organization wildcard:
p-7gh3-equipment-requests.example-org.intrnl.run
This preserves the desired {app}.{organization} structure while isolating untrusted application origins from the management plane.
Cloudflare Universal SSL alone covers only the root and first-level subdomains in a full-setup zone, not names several labels deep. The v1 certificate design therefore needs per-organization wildcards, Total TLS/Advanced Certificate Manager, custom certificates, or an equivalent automated mechanism. Cloudflare Universal SSL limitations