Configure 5 min read

Custom Domains

Attach a domain to a public NexHost service and complete the dashboard-guided DNS verification.

Updated 2026-08-30 · 5 min readView as Markdown

Custom Domains#

Add a custom domain from the project’s domain settings after a public service has a successful release. The dashboard then shows the exact DNS records required for the selected domain and a live verification status — ownership, routing, and certificate — so you know which step is blocking.

A custom domain is a property of the hostname, not the source code. You can attach or detach it without redeploying the service; verification is about DNS proof, not about what the application does at runtime.

When to use this#

Use this flow when the generated workspace hostname (for example …nexthost.example) is no longer the public address you want to share — when launching, when a customer-facing domain must read as www.example.com, or when email senders need to authenticate against your own domain. Do not start here if the public service has never succeeded; verify that the release is healthy first and then attach the domain.

Before you begin#

At least one public service (Static Site, Frontend App, or Web Service) with a successful release — the domain flow attaches to a deployed service.
Access to the DNS provider for the domain so you can create TXT/CNAME/A/AAAA records as shown by the dashboard. Read-only access is not enough.
A few minutes of patience. DNS edits can take time to propagate, and verification retries on its own schedule.

Add the domain#

Open Dashboard → Domains or the project’s domain settings.
Enter the hostname you want to use, such as www.example.com or api.example.com. Use the full hostname you plan to serve — do not add an apex without reading the dashboard note about apex handling first.
Choose the available DNS management option shown for that domain.
Copy the ownership and routing records shown by the dashboard into your DNS provider exactly as displayed for the domain you are adding.
Run verification after the records have propagated. The domain detail screen reports each check independently.

Do not guess record names or targets from another project — even one inside the same workspace. The values displayed for the domain you are adding are authoritative and can differ between domains and between attachment attempts. Copying a stale record from history or from a different domain is the most common reason for "it looks correct but stays pending."

Warning

Create records only for the integer domain row you just added. Deleting or editing unrelated records in a zone is out of scope for this flow and can break other services.

How ownership, routing, and TLS relate#

The three verifications are sequential: ownership and routing must both succeed before the certificate step can complete.

Step	What the dashboard checks	What to do when it is pending
Ownership	A TXT or equivalent record that proves you control the domain	Compare the displayed host, value, and quoting against the provider. Watch for trailing dots, quoting, or whitespace added by the DNS UI.
Routing	The host record that points traffic at the NexHost target shown for this domain	Confirm the host matches the target shown for this domain, not a nearby project or a previous record.
Certificate (TLS)	Certificate issuance for that hostname	Complete ownership and routing verification first, then check the domain screen for its current status. Leave ownership/routing records in place after verification — they are not throw-away tokens.

NexHost manages certificate issuance for verified hostnames. Leave the verification records in place unless the domain screen tells you otherwise — removing them too early causes verification to drop and the certificate not to renew.

Common issues#

Status	What to check	Common false fix
Ownership pending	The ownership record exactly matches the dashboard value at the authoritative DNS, has propagated, and has not been truncated or reformatted by the provider’s UI.	Changing unrelated records or adding the same value twice in a different label.
Routing pending	The host record matches the target shown for this domain right now — not for another domain, project, or previous attempt.	Reusing a routing value from screenshot history rather than from the current domain row.
Certificate pending	Complete ownership and routing verification first, then check the domain screen for its current status. Certificates cannot be issued for hostnames that are still unverified.	Repeatedly clicking verification without addressing the earlier failing check.

If a record looks correct but verification remains pending, give propagation a few minutes and retry verification. Use the dashboard’s support path and include the domain and displayed status — never post DNS credentials, API tokens, or service secrets. Including a screenshot of the domain row with secrets redacted is more useful than a TXT of raw zone dumps.

Propagation and operational tips#

Use the DNS provider’s preview or dig-equivalent view to confirm the authoritative answer before you conclude that "the provider says it is done." Many UIs show queued edits as if they were live.
TTL matters. A long TTL on a previous conflicting record can delay the appearance of the new value at resolvers the verifier queries.
If you manage multiple hostnames (www.example.com + example.com or app.example.com + api.example.com), attach and verify each independently — they have distinct record sets and statuses.
Do not share DNS provider credentials outside a private, access-controlled credential store.

Domains and Networking — public vs private access models and how PORT and health paths interact with hostnames.
Logs — reading stage output when a release never became reachable enough for domain attachment.
Workspaces and Access — who can add domains and how workspace access is scoped.