DNS and subdomains
How Atrium claims app subdomains — the first-wins lock, the open namespace anyone may claim in, and why records it does not manage can never be overwritten.
A DNS connector makes Atrium the registry for app subdomains in your org's zone. Connect one from the connector marketplace — AWS Route 53 and Cloudflare ship in the catalog today. Several zones can be connected at once, one per domain, each with its own credentials and policy.
Nothing below depends on which provider you connected. The rules are the platform's, and a connector supplies the zone.
The rules
- First claim wins. A subdomain is locked to the app that claimed it — no other app (or person) can take, edit, or point it elsewhere. Owners release their own names; that's the only way a name frees up.
- Open namespace for everyone. Any signed-in user may claim
<name>.<open-namespace>(defaultatrium, renameable in the connector config) — that's the democratised lane, e.g.myapp.atrium.<zone>. The bare namespace record itself (atrium.<zone>, which serves Atrium) stays hard-reserved, so the open lane can never take out the platform. - Apex-level names are not available today. A claim like
myapp.<zone>is refused with a 400 naming the namespace you can use instead. Atrium's zone credential is scoped to*.<open-namespace>.<zone>on purpose, so a record at the apex is rejected by the DNS provider whatever your role is. Getting one needs an explicit IAM grant for that name from whoever owns the AWS account — ask them, rather than retrying or looking for a wider role. - Existing zone records are protected. Atrium only ever creates records —
a claim that collides with a record already in the zone fails instead of
overwriting it,
atriumitself is hard-reserved, and deletes only remove records whose value still matches what Atrium wrote. - Deleting an app releases its addresses. Its records are removed from the zone as part of the deletion, so a deleted app never leaves a live name pointing at an IP someone else can take over. Records the zone no longer serves for us (zone disconnected, value changed by hand) are reported in the deletion notices instead of being force-deleted.
- Registration auto-claims. Registering an app claims
<slug>.<open-namespace>pointing at the default ingress IP when the name is free. Owners manage more subdomains from the app's settings page.
Over MCP, get_dns_targets tells an agent the zone + ingress IP,
claim_dns_subdomain claims for an app you own, and register_app is the
self-serve door — the loop a coding agent runs to ship an app end-to-end.
Claiming from an agent
Over MCP a coding agent runs the whole loop itself:
| Tool | Does |
|---|---|
get_dns_targets | Reads every connected zone, its provider, the default ingress IP and the open namespace |
claim_dns_subdomain | Claims a name for an app you own |
list_dns_records | Lists an app's claimed names and their zone status |
release_dns_subdomain | Releases a name the app holds, deleting its zone record |
With several zones connected, a claim that does not name one is refused rather than guessed — putting a record in the wrong domain silently is worse than an error.
Statuses
| Status | Means |
|---|---|
pending | Claimed in Atrium (the name is locked) but not yet written to the zone — usually no connector is connected yet |
applied | The record exists in the zone |
error | The write failed; the reason is on the record. A collision with a record Atrium does not manage reports as protected, not overwritten |
A claim always locks the name inside Atrium even when the zone write fails, so two apps can never end up believing they own the same subdomain.