Connecting a domain to a deployment platform: the general workflow
Vercel's, Railway's, and Render's own domains each walked through their own specific steps for adding a custom domain. Pulled back one level, every single one of those walkthroughs is following the exact same four-step shape — and recognizing the shape is what lets you connect a domain to any platform you haven't specifically studied yet.
Intermediate
3 min read
The four-step shape, true across every platform
Register the domain with the platform: telling the platform "this domain should route to this specific project/service" — a step that exists entirely in the platform's own system, with no DNS involved yet at all.
Add the DNS record(s) the platform specifies: a CNAME for a subdomain, lesson 3's own apex-specific workaround for a bare domain.
Verification: the platform confirms the DNS record is actually detected pointing at its infrastructure — sometimes satisfied automatically by the same record from step 2, sometimes requiring a separate TXT record specifically for ownership proof (the next section covers exactly when each applies).
Automatic HTTPS: once verified, a TLS certificate is issued (via Let's Encrypt/ACME, Networking Fundamentals' own HTTPS lesson covers the underlying mechanism), and the domain starts actually serving the deployed app.
When TXT-based verification is needed, specifically, versus when the DNS record alone is enough
A domain genuinely new to a platform, with no prior conflicting configuration, usually has its ownership confirmed by the same CNAME/A record change alone — the platform sees the record pointing at its own infrastructure and reasonably infers you control the domain. A domain that's already configured elsewhere, or one the platform can't yet directly observe DNS for, often requires an explicit TXT record containing a platform-provided verification string — proving control of the domain's DNS configuration independently of the actual routing record, which is exactly why this step can complete even before the "real" A/CNAME record has fully propagated.
Why "I added the record, nothing's happening" is almost always step 2 or step 3, not step 4
Every platform's own domain in this subcategory named the same diagnostic order: check DNS propagation (Networking Fundamentals' own TTL lesson, and lesson 9's practical troubleshooting in this domain) before assuming HTTPS/certificate issuance itself is broken. HTTPS activation is downstream of verification, which is downstream of the DNS record actually resolving correctly — a problem that looks like "HTTPS won't turn on" is overwhelmingly more often "the DNS record hasn't actually propagated or was entered with a typo" than a genuine certificate-issuance failure.
Applying this shape to a platform you've never used before
The next hosting platform you encounter — one none of this curriculum's specific lessons happen to cover — will follow this same four-step shape, even if its specific dashboard labels and exact record values differ. Looking for "where do I register this domain with the platform," "what record does it want me to add," "how does it verify ownership," and "does it handle HTTPS automatically" is a transferable checklist, not something that needs to be relearned from scratch for every new platform.