# Domains Serve your project on your own domain: the DNS records or nameservers to set, HTTPS, and pinning an address to one release. Every project has an address on `nesly.net` from its first deployment. A custom domain is a name you own pointed at the same project; the`nesly.net` address keeps working beside it. ## Adding a domain ``` nesly domain add app.example.com nesly domain verify app.example.com --wait ``` In the console: the project's **Domains** tab, **Add domain**. Either way you then choose one of two ways to point the name here. ## Option 1 — create the DNS records `domain add` prints the records to create at your DNS provider: one that sends visitors here and a `TXT` record that proves the name is yours. Copy them as shown. - A **subdomain** (`app.example.com`) gets a`CNAME`. - A **root domain** (`example.com`) gets`A` records instead, because DNS does not allow a`CNAME` at the root of a zone. Add`www.example.com` as a second domain if you want both. You do not have to come back and verify. nesly checks a domain that is not serving yet every couple of minutes and activates it as soon as the records are visible.`domain verify` (or **Check now** in the console) only skips the wait; `--wait` keeps checking until the domain is live. DNS changes take from a few minutes to a few hours to propagate. ## Option 2 — use our nameservers Rather not manage records? Let nesly hold the domain's DNS: ``` nesly domain delegate example.com # prints the nameservers to set nesly domain verify example.com ``` Set the printed nameservers where you bought the domain, replacing the ones there. Once they point here, every record the site needs is written for you. Run`domain delegate` again at any time to see whether the change has been published. Nameservers belong to a whole domain, not one name inside it, so this option is for a root domain. For a subdomain, create its records, or add the root domain first and delegate that. With the zone held here you manage its other records here too — mail, verification records for other services, extra names: ``` nesly dns ls example.com nesly dns add example.com --type MX --name @ --value mail.example.net --priority 10 nesly dns rm example.com --type TXT --name _old ``` The records that keep the site and its ownership proof online cannot be removed this way. ## What the status means

Waiting for DNS	The domain is added; the records (or nameservers) are not visible yet.
Active	DNS is right and the address is serving your project. HTTPS follows on its own.
Invalid configuration	The records were checked and are not what the domain needs. The reason is shown next to it; fix the record and it is checked again.

## HTTPS A certificate is issued for an active domain and renewed before it expires, with nothing to configure. `nesly certs` shows the certificate each address actually serves — measured by opening a connection, not read from our records, so a renewal that failed quietly shows up there before your visitors see a warning. ## Pinning an address to a release ``` nesly domain pin staging.example.com dep_3k2m… nesly domain unpin staging.example.com ``` A pinned address keeps showing that release while every other address follows new deployments — a staging address on the build you are reviewing, or one version for a client. The pinned release is kept reachable for as long as the pin lasts. Unpin to put the address back on whatever is live. ## Removing a domain ``` nesly domain rm app.example.com ``` The project stops answering on that name. Delete the DNS records at your provider too, so the name does not keep pointing at an address that no longer serves it. How many domains a project may have depends on the plan: [limits](/docs/limits/). --- Canonical: https://nesly.net/docs/domains/ Markdown: Accept: text/markdown on the HTML URL, or replace the trailing slash with .md