DNS records and certificate, checked for you

The app tells you exactly which DNS records to add, re-checks them on demand, and says plainly when what's at your registrar doesn't match.

What it is

A thin server-side wrapper over the hosting provider's domains API with three operations: attach, detach, and verify. Verify returns either the provider's own challenge records or the canonical apex A record / subdomain CNAME pair, plus a human-readable misconfiguration reason surfaced verbatim so the owner can compare it against what they typed.

Also called: DNS setup · CNAME record · SSL certificate · domain verification

See it
DNS records and certificate, checked for you
Area
Platform & Admin
Group
White-label
System
Multi-Tenancy & Identity
Solves
3 named problems
01addDomain() attaches the hostname to the project and immediately calls verifyDomain() to fetch the record set.
02verifyDomain() reads both the domain config (misconfigured flag) and the domain record (verification challenges).
03If the provider has no outstanding challenge, the helper computes the right record by shape: two labels or fewer is an apex (A record), anything longer is a subdomain (CNAME).
The DNS record table with type/name/value columns and the provider's misconfiguration reason quoted underneath in a warning strip. src/components/settings/CustomDomainTab.tsx. Sample data — no customer information appears here.
How it works
  1. 1addDomain() attaches the hostname to the project and immediately calls verifyDomain() to fetch the record set.
  2. 2verifyDomain() reads both the domain config (misconfigured flag) and the domain record (verification challenges).
  3. 3If the provider has no outstanding challenge, the helper computes the right record by shape: two labels or fewer is an apex (A record), anything longer is a subdomain (CNAME).
  4. 4Provider error shapes are heterogeneous, so vercelError() normalises them into one readable message instead of a raw JSON blob.
  5. 5removeDomain() treats a 404 as success, because the desired end state is 'not attached'.
Why we built it

The module header lists the three operations 'the Settings UI needs' and notes exactly why verify exists as a button rather than a background job: the provider 'also auto-verifies on its own ~minute cadence; this just surfaces did it work yet? to the user without making them wait for the next poll.' The heterogeneous-error normalisation is called out in the same header — the provider 'sometimes { error: { code, message } }, sometimes { errors: [...] }' — because an unreadable API error is indistinguishable from a broken feature to the person who just pasted a DNS record.

The problem
  • Owners cannot diagnose DNS from a generic 'not verified' message.
  • Waiting on an automatic re-check cycle feels like the feature is broken.
  • Detaching a domain that was never attached should not be an error.
Sound familiar?
What you get
The exact record type, name and value are on screen, ready to copy.
One button answers 'did it work yet'.
Certificates are issued automatically once the record resolves.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →