Custom domains
Bind a custom domain to a resource.
A domain binding means the user wants a hostname to point at a resource. It is not deployment input or an implicit certificate side effect.
Make the generated access URL work before binding a custom domain. That keeps app/proxy troubleshooting separate from DNS and TLS troubleshooting.
Use custom domains when:
- A production hostname should point at a resource.
- Staging, preview, or customer environments need separate hostnames.
- External access should be added after deployment is stable.
Choose:
- Resource: which resource the hostname should reach.
- Environment: where the binding applies.
- Hostname: the full domain, such as
app.example.com. - Access policy: proxy/default entrypoint and HTTPS expectations.
- Certificate policy: automatic issue, imported certificate, or TLS later.
A domain name should not replace resource, server, or environment identifiers.
The Web console should allow binding from a resource or access page and immediately show ownership, route readiness, proxy readiness, diagnostics, and TLS next steps.
The CLI fits automation and release scripts. Use appaloft domain-binding show <domainBindingId> to read one binding, configure-route to switch between serving traffic and redirecting to a canonical binding, delete-check before deletion, and delete --confirm <domainBindingId> only after blockers are clear.
The HTTP API uses the same operation contracts. DNS/TLS semantics should not be hidden inside deployment status.
Typical states:
pending_ownership: waiting for DNS or ownership verification.pending_certificate: ownership is verified but TLS is not ready.ready: domain and certificate are usable.failed: DNS, certificate material, or proxy entrypoint needs action.
If binding fails, do not redeploy first. Check:
- Whether generated access works.
- Whether DNS points to the current server or proxy entrypoint.
- Whether ownership verification records exist.
- Whether certificate issue or import failed.
Deleting a binding removes managed custom-domain route intent only. It does not revoke certificates, erase certificate history, delete generated access, rewrite deployment snapshots, or remove server-applied route audit. If active certificate state is attached, delete is blocked until certificate lifecycle operations exist.
Related pages: Domain ownership, TLS certificates, and Access troubleshooting.