Domains
Every application is reachable at an address the platform assigns it —
<app>-<org>.someones.computer. If your organization and application names are
long enough to push that first part past 63 characters — the most a name can be —
the platform shortens it, ending it with a few characters that keep it unique.
That shortened address is the real one: it never changes, two applications never
share one, and it is what you hand out. Custom domains are an extra way in,
never a replacement: the assigned address keeps working whatever you do here, which is
what makes a mistake in a zone file recoverable.
Domains belong to the organization, not to an application. You bring
acme.com once; which application answers on www is a separate decision you
can change later. Open them from the Domains pill on an organization's page.
Adding a domain
Enter the zone apex — acme.com, not www.acme.com and not a URL.

A name can only be claimed once across the whole platform. If someone else already holds it you'll be told so rather than ending up with two organizations whose traffic the edge can't tell apart.
Pointing a name at an application
Each entry under a domain is a record: a subdomain, an application, and — only when the application serves HTTP from more than one service — which service.
| Field | Meaning |
|---|---|
| Subdomain | www, api.eu, or blank for the apex (acme.com itself) |
| Application | Any application in this organization |
| Service | Optional. Blank means "the only HTTP service"; required when there are several |

Setting a subdomain that already exists repoints it — the record is the statement
"www is the shop", not a stack of them.
DNS is yours to set
The platform never touches your nameservers. Point each name at the application's assigned address with a CNAME (the page shows the exact target, with a copy button), or at the platform's edge with an A record if you need the apex.
Certificates are issued automatically once a name resolves here. Until it does, the name simply won't answer — nothing is broken and there's nothing to retry.
Nothing checks your DNS yet. A record starts routing as soon as you add it, whether or not the name points here. A typo'd hostname is inert rather than harmful, but it will sit in the routing table looking like it should work.
Where a domain shows up
The application's own page lists every address it answers on, assigned first:

A record the platform can't attach to a service is called out there in amber rather than left silently dead. That happens in two cases:
- the record names a service that has since been renamed in your compose file; or
- it names no service for an application that serves HTTP from several.
Both are fixed by editing the record on the organization's domains page.
When a change takes effect
Adding, repointing, or removing a record re-labels the running services in the background — usually within a second or two, without a redeploy. If nothing is deployed yet, the record is stored and starts working with the first deploy.