Custom domains

Every service gets a managed HTTPS URL, but production usually needs your own domain. Adding one takes two steps: claim it on the service, then prove you control it with DNS records.

4 min read

Adding a domain

Open the service, go to its Domains tab, and add the domain you want it to answer on.

The domains tab of a service, showing its managed URL and a field to add a custom domain — A service can answer on its managed URL and on your own domains at the same time.

You are then shown the DNS records to create. Until they resolve, the domain stays pending. We will not serve a domain we cannot prove you control.

Creating the DNS records

A new domain needs two records:

Record	What it does
`TXT _naijacloud-verify.<domain>`	Proves your workspace owns the domain. The value is shown on the domain and is unique to your workspace.
`A` or `CNAME` on the domain	Sends its traffic to your service.

Add them at whatever manages your domain's DNS. The domain serves nothing until the TXT record is in place, even if the routing record already points at us. That stops anyone else serving on a domain whose DNS was left pointing here.

One TXT record covers the subdomains. A TXT record on example.com also proves www.example.com and app.example.com.
DNS hosted on Naijacloud needs no TXT record. If the domain sits in a DNS zone your workspace holds here, ownership is already proven. Add the routing record under Domains. See DNS records.
The domain is "already in use". Another workspace has added it. If the domain is yours, add the TXT record the message gives you, then add the domain again. It moves to your workspace.

Records propagate on their own schedule. Most resolve within minutes, though a stale cached record can take longer, up to the previous record's TTL.

Lower the record's TTL before you change it, if you can. A record cached for 24 hours keeps serving the old value for 24 hours after you fix it, and there is nothing to do in the meantime but wait.

HTTPS

Once the domain verifies, a certificate is issued and renewed for you. There is no certificate to upload, and nothing to remember to renew.

Verification has to complete first: certificate issuance depends on the same DNS proving the domain points at us.

If a domain sits at issuing for a long time, the cause is nearly always DNS: a record on the wrong name, a typo, or a second conflicting record left over from a previous host. Check what the name actually resolves to before assuming the certificate is at fault.

Root domains and subdomains

Both are supported: example.com and app.example.com can each point at a service. The record type differs between them, so use the value shown for the domain you added rather than copying between them.

A common arrangement:

Domain	Points at
`example.com`	The marketing static site
`app.example.com`	The web service
`api.example.com`	The API service

Removing a domain

Removing a domain stops the service answering on it. Traffic to it fails until you point it elsewhere, so remove it after you have moved it, not before.

Domains that were live before the ownership record existed keep working. You don't need to add the TXT record for them.

Related: Registering a domain.