Domains

A domain is a hostname you connect to MicroApps and prove you own. Once verified, you can map it to any pod and turn on SSL. You bring the name; we handle the certificate and the routing.

Types

You do not pick a type when you add a domain. We classify the name you enter against the public suffix list:

• fqdn - a root domain like example.com.
• subdomain - a subdomain like app.example.com.
• local - a name that sits under no public suffix (myapp.internal). We skip DNS verification for these; there is no public DNS to check them against.

Classification runs just after you add the name, so a brand-new domain reads unknown for a moment. The type decides which pointing record we ask you for, and nothing else.

Lifecycle

1. Add - enter the domain name. That is the only input.
2. Verify ownership - publish the microapps-verify TXT record shown on the domain's DNS tab. We generate it the moment the domain is created, so it is there waiting for you. (Domains verified under the older verify-domain record name stay verified.) A subdomain of a domain you have already verified inherits that proof and skips this step.
3. Publish the pointing record - a CNAME for a subdomain, an ALIAS for a root domain. This is what sends visitors to us.
4. Map to a pod - point the domain at a pod, choosing http or https and the internal port your app listens on.
5. Enable SSL - publish the _acme-challenge CNAME from the DNS tab, then one click. We issue the certificate through that record and renew it before it expires, forever. SSL does not need a mapping first; an unmapped domain can hold a valid certificate and have it installed when you map it.

If a record never verifies and you are sure you published it, the usual cause is a broken DNSSEC chain at your registrar.

Why a name and not an IP

We never hand you an IP address to point at. The pointing record targets a hostname we control, because the node your pod sits on is ours to move - for capacity, for maintenance, or because you restored the pod somewhere else. When that happens we change what the name resolves to and your domain keeps working. An IP you hard-coded into your zone would not.

That is also why a root domain gets an ALIAS rather than a CNAME: a plain CNAME cannot sit at the apex of a zone next to the SOA, NS, MX and TXT records that live there. Providers that accept one at the root are flattening it, which is ALIAS under another name. If yours offers neither, the guide has the fallbacks.

Globally unique names

A domain name can only be owned by one account at a time. When you add a name someone else already registered:

• If they added it but never verified it, you can claim it by publishing the microapps-verify TXT record within 48 hours. First to verify wins.
• If they have already verified it, it is locked to their account and cannot be claimed. You would need them to remove it first.

This is how a domain transfers between accounts: the old owner removes it (or lets an unverified claim lapse), and the new owner verifies. A transfer resets the domain for its new owner - fresh ownership secret, fresh certificate, no mapping, and no trace of the old owner's email setup.

Notes

• A domain maps to one pod at a time, but a single pod can serve many domains.
• You cannot map a domain to a database pod.
• A certificate covers the domain and its subdomains, so subdomains under a domain you have already secured reuse it rather than issuing their own.
• Unmapping keeps the certificate, so re-mapping does not trigger a fresh issue. It does drop the pointing record from the DNS tab, because the next mapping may land on a different target; mapping again re-adds it.
• The DNS tab lists every record we expect, marks each verified or not, and flags which are required rather than recommended.

See also

• Custom domains & SSL guide
• Domains API