shadcn.io is not affiliated with official shadcn/ui
Custom Domain Settings Block for React
A custom domain settings panel that leads with what visitors get at each step and walks four stages on a vertical rail: add a domain, add a CNAME and a TXT record with copy buttons, a simulated two-try DNS check and a sample certificate.
Installation
Overview
Connect a site to an address of your own and show what that does to visitors at every step, with this custom domain settings panel for React with Base UI. A hairline frame with a plus mark on each corner leads with one sentence worked out from where the setup stands: visitors still reach the site's own address until DNS passes, then the new address, over HTTPS once the certificate is in. A vertical Steps rail marks the four stages (add the domain, add two DNS records, check DNS, certificate), each with where it stands in words, and the stage itself shows beside it. The first stage takes the host name and refuses what can't be a custom domain. The second shows a native table of a CNAME and a TXT record, each name and value with its own Copy Button. The third runs a simulated check against two sample answers typed into the page: the first finds the CNAME and says the TXT record isn't there yet, the second finds both. The fourth shows a certificate as pending, then issued with a start and an end day. One Shine Button moves forward and its label follows the step, with an outline Back beside it. It's built from Steps, Copy Button, Field, Input, Shine Button, Button and Guides, with a CSS entrance only. For a site builder, a docs host or any product that serves a customer's pages from their own domain.
FAQ
How do I change the hostnames, the target and the check?
Edit the constants at the top. SITE is the address the site keeps while no domain is connected, TARGET is where the CNAME points, TOKEN is the verification value for the TXT record and START_HOST is what the field holds on load. ANSWERS lists what the sample resolver finds on each check, one entry per press, so a third entry or a different order changes the story. AS_OF and LIFETIME_DAYS fix the certificate's dates. The sentences, the rail's notes and the record names (the TXT name is built from the host's first label) are all worked out from these, so nothing is typed twice.
Is anything looked up? How does the two-try check work?
Nothing is looked up. The panel says so under the results: the check is made against sample records in this demo, not the real DNS. The first press shows the CNAME as found and the TXT record as not found yet, and the status line says so; the second shows both found and the main button becomes Continue. Pressing it again after a pass does not recheck. To make it real, resolve the CNAME and the TXT name on your server, return what you found for each record, and show the same three words (not checked, not found yet, found).
What does the domain field accept?
A subdomain: at least three dot-separated parts, each made of letters, digits and hyphens and at most 63 characters, with no scheme, port or path. It is lower-cased and a trailing dot is dropped. An address under the product's own domain is refused, and so is anything that looks like a link, each with a message in a reserved line under the field and focus kept on it. A bare domain would need a different kind of record, which this panel doesn't draw. Changing the host after a pass starts the check again.
What stays local, and how do I make it real?
Everything. No domain is added, no record is published, no certificate is requested and the certificate's dates are a fixed sample: Issue certificate only turns the stage to issued in this page. To make it real, create the domain on your server when the first stage is submitted, show the records your server expects, check them for real, request a certificate from your certificate authority once DNS passes, and read its real dates back to the last stage.
How does it look on a phone, and by keyboard?
Below the medium breakpoint the rail becomes a bar of four markers with the stage's name in its heading, and the records become one card each with labelled name and value, from the same markup as the table. The foot is pinned to the bottom of the screen. Enter in the field submits the stage. When you move forward or back, focus goes to the new stage's heading, and the status line is a polite live region that says what happened. Stages you aren't on are inert and hidden from assistive technology, and the panel keeps one height whichever stage shows.
Related
- Pro
DNS Settings
Domains and deliveryA DNS settings panel that leads with a resolver you can ask, then holds the same zone as a filterable records table with TTL and conflict checks and as a zone file parsed as you type, kept in step while it is valid.
- Pro
Email Domain Settings
Domains and deliveryA sending domain settings panel that leads with what SPF, DKIM and DMARC amount to for your mail, shows the three records as cells with status, host and value to copy, and a DMARC policy select that rewrites its record.
- Pro
Domain Verification Records Success
Domains and networkA confirmation page for a verified custom domain: the three records the product asked for (A, CNAME, TXT) beside what DNS returned, with a Match word between them, a switch between comparing like DNS and as written that underlines the differing characters, and a certificate row.
- Pro
Cache Policy Settings
Domains and deliveryAn ordered table of cache rules where first match wins: each path pattern has a freshness bar, how long a copy stays fresh and how long a stale one may be served, a count of the cached paths it really claims, and a purge that counts what it would clear.
- Pro
Environment Variables Settings
Domains and deliveryAn environment variables settings panel that shows where each variable is set across Production, Preview and Development, counts what is missing, fills a missing value with Copy from, and previews a pasted .env file before it imports.
- Pro
SMTP Settings
Domains and deliveryAn outgoing mail settings panel that leads with how mail will leave, a server form with presets, an encryption choice and a masked password, beside a dark terminal that plays a simulated SMTP session or stops at the mismatch a real server would give.