Answer first, your address on BYOB hosting #
A custom domain means visitors reach your BYOB site through your own address instead of a platform URL. You add the hostname inside BYOB, copy the exact DNS records it returns into your registrar, wait for propagation, and recheck status until both domain routing and SSL are active.
Two rules prevent most pain. Deploy at least once before adding a domain, so there is a live origin to point at. And treat setup as complete only when domain and SSL are both active, not when the address merely resolves.
Think of DNS as the postal system for the internet. Your domain is the street address you print on the letter. DNS records are the forwarding instructions at the post office telling every carrier where that address currently lives. Get one instruction wrong and mail circles the depot. Get them right and nobody thinks about the post office at all, which is exactly the point.
What is the deploy-first requirement? #
BYOB requires one deploy before a custom domain can be added. The reason is operational: the domain needs a valid publish target. Without a live origin, verification has nothing stable to resolve to, and every status check becomes guesswork.
That requirement shapes the wider build rhythm. Create the project, build core pages and logic in milestones, save checkpoints, publish early to a platform URL, validate live behavior, then attach the custom domain. Staying on the platform URL is explicitly fine in early phases. Many projects validate there first and add a custom address only when ready for public traffic. The guided setup flow (https://byob.studio/blog/byob-custom-domain-setup-guide) walks this order step by step, and the end-to-end publish flow (https://byob.studio/blog/byob-build-to-domain-publish-flow-2026) shows where domain work lands in the full journey from build to public URL.
Skipping ahead causes a specific failure. You wire DNS to a project with no deploy, checks flap, and you burn an afternoon debugging records that were never the problem. Deploy first. Everything after that gets easier.
| Record group | Type | Lifetime | Purpose |
|---|---|---|---|
| Routing | CNAME or ALIAS | Permanent | Points host to BYOB |
| Ownership proof | TXT | Until domain active | Proves you control the name |
| SSL validation | TXT or CNAME | Until SSL active | Allows certificate issue |
| Legacy records | Any | Remove promptly | Avoid conflicts and flapping |
How do DNS records work? #
DNS is a distributed lookup system with record types for distinct jobs. As defined in RFC 1035 (https://www.rfc-editor.org/rfc/rfc1035), the original domain name standard, names resolve through records stored at authoritative nameservers and cached by resolvers around the world. Cloudflare's DNS docs (https://developers.cloudflare.com/dns/) describe the modern operational side: record types, proxying, and TTL behavior.
Three record shapes matter for domain setup. A records point a name at an IPv4 address. CNAME records point one name at another name, which is how subdomains usually attach to hosting targets. TXT records hold arbitrary text and carry ownership proofs and mail authentication. For root domains, providers offer ALIAS or flattened CNAME behavior because a bare root cannot hold a plain CNAME alongside its other mandatory records.
TTL, or time to live, tells resolvers how long to cache an answer. Low TTL means changes spread fast and resolvers ask often. High TTL means calm traffic and slow change. Before editing records, note the current TTL. It predicts how long you will wait, and it explains why a fix that is correct can still look broken for one cache window.
What is the difference between routing and verification records? #
The BYOB domain flow separates records into two groups so permanent routing is never confused with temporary validation.
The routing record is permanent. It points traffic to BYOB and is typically a CNAME or ALIAS shape depending on whether you use a subdomain or root domain. This record stays forever. It is the forwarding instruction itself.
Verification records are temporary until validation finishes. They prove ownership and validate SSL issuance, usually as TXT records, with SSL validation sometimes using TXT or CNAME. These records answer a different question: not where traffic goes, but whether you control the name and whether a certificate may be issued for it.
The lifecycle is simple: keep routing forever, keep ownership until the domain is stable, and keep SSL validation until the certificate is fully active and stable. Removing validation too early is a classic way to strand SSL in pending while the domain itself looks fine.
Copy host and value exactly from BYOB. Do not manually normalize dots, prefixes, or quoting unless your registrar explicitly requires it. One wrong field creates half a day of debugging, and the error messages will blame propagation instead of your typo.
How does root compare to subdomain? #
Use the root domain in BYOB for the main brand site, www for the marketing site, and an app hostname for a product split from marketing. Root generally uses ALIAS or flattened-CNAME behavior while subdomains use CNAMEs to the BYOB target. Constraint: if a registrar lacks ALIAS at root, start with a subdomain flow, and have registrar login plus the root-versus-subdomain decision ready before opening the modal.
Choose the hostname deliberately rather than by habit. Try it: Domain Name Ideas
A root domain suits the main brand site and generally uses ALIAS or flattened CNAME behavior. A www hostname suits a marketing site under the primary domain and generally uses a CNAME to the BYOB target. An app hostname suits a product split from marketing and also generally uses a CNAME to the BYOB target.
Teams often start on www first because propagation and rollback are cleaner there. If a registrar does not support ALIAS at root, starting with a subdomain flow or using provider-supported root flattening is the practical fallback.
Registrar access and DNS permission must be ready before opening the modal, along with the root-versus-subdomain decision. Missing any of those slows setup immediately. The person with registrar login should be in the room, not three time zones away.
How do status values and propagation work? #
BYOB statuses are operational signals. Pending means the registrar accepted the record but propagation is incomplete. Active means routing is correct and BYOB can resolve the host. SSL pending means the domain is connected but certificate validation is still running. SSL active means the certificate is fully issued and serving. Error means one or more records are wrong or missing.
Certificate issuance deserves its own mental slot. As described in Cloudflare's SSL docs (https://developers.cloudflare.com/ssl/), a certificate authority must verify control of the name before issuing, which is why SSL lags routing. The domain can resolve while the certificate is still being minted. Patience here is not passivity. It is the protocol working.
Propagation depends on provider TTL and resolver caching. Best case is a few minutes. The common case is well under two hours. Worst case is several hours. Do not repeatedly delete and recreate records unless a concrete mismatch is confirmed. Waiting one TTL window and rechecking beats churn every single time.
The runbook order is: deploy once, enter the hostname in BYOB, add the routing record, add ownership and SSL verification records, save DNS, return to BYOB and check status, wait and repeat until active plus SSL active, then remove verification records only after SSL is stable.
How do you troubleshoot and run go-live checks? #
When status stalls, work the checklist in order. Confirm the record type matches BYOB instructions. Confirm host handling for root versus subdomain is correct. Confirm no conflicting old records remain. Confirm proxy mode is correct where DNS-only is required. Confirm the value has no extra protocol or path. Then wait one TTL window and recheck.
Common mistakes map cleanly to fixes. Wrong record type never verifies and must be replaced with the expected type. Wrong host field means BYOB cannot find ownership and must be recreated correctly. Early removal of SSL validation strands issuance and must be re-added. Legacy records left in place cause flapping and must be removed. Proxied records where DNS-only is required produce confusing half-states and must be switched.
Before public launch, verify the domain resolves in a browser, HTTPS is valid, canonical URLs point to the new domain, redirects behave, analytics and cookies still function, and forms plus auth callbacks work on the new host. Cookies deserve a special look because a session cookie scoped to the platform URL will not follow users to the custom host. Core testing should start before domain setup and repeat after activation for final confidence.
What are the milestones, checkpoints, and release rhythm? #
Land BYOB domain work inside milestone-based building in 4 stages: build structure and routes, add the visual system and responsive pass, integrate forms and data, then publish early, attach the domain, and retest. Prerequisites: one deploy to a platform URL plus saved checkpoints with clear labels. Constraint: test in two passes (feature-based, then full-site), and restore the last good snapshot and redeploy immediately if an incident follows publish.
Domain work lands best inside milestone-based building. Build structure and routes first, then the visual system and responsive pass, then forms, data integration, and edge flows, saving after each milestone rather than running one giant generation.
Save checkpoints before broad refactors, model switches, and final publish with clear labels. Good labels reduce rollback confusion under deadline pressure. Publishing early exposes production asset behavior, route and metadata behavior, and real-device rendering that local preview alone cannot prove.
Test in two passes: feature-based tests for the highest-risk flows, then a full-site test for release confidence. A practical cadence is build and checkpoint early in the week, publish and test midweek, then handle domain checks, polish, and distribution updates at the end. If an incident follows publish, restore the last good snapshot, redeploy immediately, and patch separately before the next promotion.
Your domain is the one address users memorize, so treat its setup with the care it deserves. Deploy first, copy records exactly, wait out the TTL, confirm both signals green, and only then announce. The post office stays invisible, and your launch reads as effortless, which is the finest compliment infrastructure can earn.
What are the trade-offs? #
Deploy once plus exact DNS copy wins when the hostname must hold. One permanent routing record plus temporary ownership and SSL validation records move the domain from pending to active, with routing and certificate issuance tracked separately per Cloudflare DNS and SSL practice and RFC 1035.
| Attach the domain when | Stay on the platform URL when |
|---|---|
| Brand trust, sharing, or launch timing needs your address | The project is still a draft with placeholder content |
| Validation records can stay until SSL reads active | DNS access is locked and nobody can paste records |
| Critical paths can be retested on the new host | Publish then domain rhythm would interrupt demos |
Domains lose on propagation waits. Pick the alternative until ready: publish early for live validation, attach the address, then retest on the new host.
Who this is for (and who should skip it) #
Custom domains in BYOB fit projects that are live on a platform URL and ready to present on their own address with proper SSL and brand trust, where you control the registrar and can edit DNS. Skip adding a domain while the app still changes shape hourly or before the first deploy; stay on the platform URL until live behavior is stable.
This fits if you have a project that is live on a platform URL and ready to present on your own address with proper SSL and brand trust. If you control the registrar and can edit DNS, the guided flow pays off quickly.
Skip adding a domain while the app still changes shape hourly or before the first deploy, and stay on the platform URL until live behavior is stable.
- Best for beginners pointing a first custom address at a live BYOB site after one deploy.
- Best for small business owners sorting routing versus verification records and SSL timing.
- Best for freelancers running publish-then-domain rhythm for client go-lives.
What we learned building this #
Custom domains in BYOB require a live deployment before a host can attach, with a deploy-first check in the domain settings. Setup builds DNS record groups for routing plus temporary ownership and SSL validation, and polls domain state until routing and certificate are both active. This flow is documented step by step in the custom domain setup guide, which matches the product behavior.
