Documentation
Custom domains
Every app already answers on its own hostname. A custom domain adds one you own — it does not replace what the app was given.
This is work, not a switch
Adding a domain involves your registrar, and registrars propagate changes on their own schedule. So it is a task you start, leave, and come back to — the app's networking settings keep the outstanding records visible until they are satisfied.
Add the domain to the app
Enter the hostname you want the app to answer on. Nothing changes for visitors yet.
Create the two DNS records
The app gives you exactly what to create at your registrar: a TXT record that proves you control the domain, and a record that routes traffic to the app. Create both. They are shown verbatim so you can copy rather than assemble them.
Wait for the check to pass
We look for the TXT record. This can take minutes or hours depending on your registrar, and there is a recheck if you would rather not wait for the next automatic attempt.
A certificate is issued
Once ownership is proven, HTTPS is set up for the hostname automatically. There is no certificate to buy, upload or renew.
The app keeps its original hostname
A custom domain is added alongside the clundra.com hostname the app was allocated, not swapped in for it. Both continue to work, which means links you have already shared do not break when you attach a domain — and if the domain has a problem, the app is still reachable.
Access rules are a property of the app, not of an address. A private app stays private on a custom domain — see Access.
One label deep
Hostnames on clundra.com are flat — an app is {app}.clundra.com and a service with its own subdomain is {app}-{service}.clundra.com, never nested. The reason is certificates: a wildcard covers exactly one label, so a nested hostname would need a certificate of its own per app.
Your own domain is yours to structure as you like — that constraint is about the hostnames we allocate, not the ones you bring.