Domains and HTTPS
Use your own domain, get a certificate automatically, and put your own CDN in front if you want one.
Every app gets a working web address the moment it deploys — your-app-a1b2.roarai.app — with HTTPS already on. Nothing to set up, and it is yours to use for as long as the app exists.
When you want the app on your own domain, you add it in the app's Domains tab and create one DNS record. We do the certificate.
The record you create
The console shows you the exact record — type, name and value — with a copy button on each field, because a trailing space in the value box fails silently and looks exactly like having done nothing.
What it says depends on the kind of address:
| You want | Record | Why |
|---|---|---|
app.yourcompany.com | CNAME pointing at your app's Roar address | Follows the app anywhere it moves. You edit your DNS exactly once, ever. |
yourcompany.com (the root) | A holding an address we give you | DNS forbids a CNAME at the root of a zone. Not our limitation. |
A root domain brings its www with it. Attach yourcompany.com and we also show a second, optional record for www.yourcompany.com and serve that name too — because "my domain works" means both to almost everybody.
It is marked optional and it genuinely is: plenty of companies deliberately send www to a marketing site. Skip the record and nothing breaks — the name is simply never asked for.
The certificate
There is nothing to buy, upload or renew. The first time a browser asks for your domain, we get a certificate for it and serve it from then on, renewing it before it expires for as long as the domain points at us.
That is why the order matters: create the DNS record, then wait for the domain to go live before you send anyone to it. The certificate is fetched on the first real request, so the very first one may take a moment longer.
What the status means
| Status | What is true |
|---|---|
| Needs your DNS record | We have not seen a request arrive for this name. Usually the record is not created yet, or has not propagated. |
| Securing | A request arrived, so your DNS is right. The certificate is being issued. |
| Live | Serving, with a valid certificate. |
The setup panel checks your DNS as you read it and tells you what it found — including the common case of the name pointing somewhere else entirely, where it names where it is pointing so you can see what to change.
Putting your own CDN or proxy in front
You can, it costs you nothing extra from us, and we are not involved. This is a normal thing to do and a good reason to use your own domain: a proxy in front of your app gives you caching at the edge, a firewall, and traffic analytics that are yours.
The common choice is Cloudflare, and the sequence that works is:
- Create the DNS record as shown, unproxied. Grey cloud, DNS only.
- Wait for the domain to read Live in the console, so the certificate has been issued.
- Turn the proxy on. Your provider serves your visitors from their edge and fetches from us behind it.
Doing it in that order is what we have tested. Turning the proxy on before the domain is live can leave your provider unable to complete a connection to a name that has no certificate yet, and their error for that says nothing about which half is missing.
Once it is on you keep our security headers — HSTS, nosniff and a referrer policy are set on every response and pass through untouched — and you gain whatever your provider adds.
Your proxy is a front door, not a lock. Your app stays reachable at its address underneath, so anyone who learns it can go around the proxy — and around the firewall, caching and analytics with it. That is true of nearly every setup like this, and for most internal tools it does not matter.
If it matters for yours — a public app where the firewall is doing real work — tell us. Closing the direct path is something we do per app, and it changes how certificates are issued, so it is a conversation rather than a switch.
Moving an app
An app on a subdomain can move regions without you touching anything: the CNAME points at a name we control, and we repoint it. That is the whole reason the record is a CNAME rather than an address.
An app on a root domain is pinned by its A record, and a move is refused rather than performed silently — because it would break the record you created and we cannot edit your zone.
Removing a domain
Remove it in the Domains tab and we stop serving it immediately. Delete the DNS record on your side too, or your domain keeps pointing at an address that no longer answers for it.