Application domains and routing
Documentation version: 858adedd187db2e94614b1dfd389e4bf98e6e202:ac5d527caaa1f97eee9d71262e7c843ae7b24000e01ba5b44931108b2b489c0d
An installation configures its operator domain, consumer frontend and default application zone independently. Your product can use one domain while hosted apps use another. No SDK import or frontend URL implicitly selects an app zone.
Register the exact environment
The management owner registers and verifies a tenant domain, then binds an exact hostname to the authorized project/environment and a registered healthy target. One hostname has at most one active binding. DNS proves part of domain control; it never authenticates an application user or grants database/file access.
The hosting guide and generated management API reference document domain, verification, hostname and retirement operations. Read the current environment revision before a mutation. Preserve your idempotency key across an uncertain response and observe the operation instead of registering another target.
Preview and Production
Production, optional Staging and individual Previews have separate explicit hostname bindings. The interface may call Preview "Development" without adding another permission model. A registered parent suffix, a branch name or a shared cookie domain cannot select Production or authorize another environment.
Application identity callbacks, cookie scope, storage origins and database HTTP/ WebSocket endpoints must match the actual binding. An alias is explicitly registered and does not silently change the environment's canonical identity. Do not add wildcard routing to work around missing per-environment authority.
DNS, certificates and readiness
Point DNS only at the installation-approved ingress. Keep native database, secret-manager and orchestration ports private. A successful DNS lookup or an allocated certificate is not proof that the application and its dependencies are ready. Normal traffic is admitted only after the registered target passes its functional checks. Preserve TLS verification on every upstream connection.
The controlled application-hosting rehearsal used exact private DNS and native internal certificate authorities. Public ACME support and provider/registrar automation are accepted only for the deployment paths with their own recorded evidence; do not infer a universal custom-domain service from a successful operator-site certificate. Follow the installation's published domain profile.
Changes and retirement
Inspect the binding lifecycle and primary/alias flags. A retired hostname remains visible for audit but is not a serving route. Controlled relocation moves the whole environment through its existing owner and verifies destination writes, permissions and routes before admission. DNS changes alone cannot fence an old database, worker or scheduler. See placement and operational recovery.