Vercel's own domain covered its specific shared-IP-plus-Host-header trick for custom domains. Railway solves the exact same apex-domain problem differently — and recognizing these as two different solutions to one well-known, recurring problem is the actual point of this lesson, not memorizing either one in isolation.
Intermediate
2 min read
The record Railway asks for: a CNAME, for subdomains
Adding a custom domain to a Railway service produces a CNAME record pointing at a Railway-generated hostname specific to that service — straightforward for any subdomain, since CNAME records are explicitly designed for exactly this "point this name at that name" use case (Networking Fundamentals' own DNS lesson covered the mechanism directly).
The apex problem, again, and Railway's own answer
Domain Names & DNS's own lesson on this exact problem explained why a plain CNAME can't be used at a domain's bare apex (example.com, with no subdomain) — the DNS specification doesn't allow it to coexist with the other record types (like MX, for email) a root domain typically also needs. Railway's answer, like most modern platforms, is its own ALIAS-equivalent record type some DNS providers support, or a documented recommendation to use a DNS provider that offers CNAME flattening specifically for the apex case — functionally the same trick as Vercel's shared-anycast-IP approach or AWS Route 53's own Alias record, just implemented through a different provider-specific mechanism.
Every platform this deployment-platforms subcategory covers runs into this exact same DNS-specification limitation and solves it with its own variation of the same underlying trick — recognizing the pattern (apex domains need a workaround, subdomains don't) transfers directly across all of them, rather than needing to memorize each platform's specific mechanism as an unrelated fact.
Verification and automatic HTTPS, the same shape as every other platform covered in this subcategory
Once the CNAME is detected pointing correctly at Railway's infrastructure, Railway automatically provisions a TLS certificate for the domain (again, via Let's Encrypt/ACME, the same mechanism Networking Fundamentals' own TLS lesson and Vercel's own domain both already covered) — no manual certificate request or renewal to manage, and the same propagation-delay caveat applies: if HTTPS doesn't activate promptly, check DNS propagation (Domain Names & DNS's own lesson) before assuming certificate issuance itself failed.
Multiple services, multiple subdomains, one domain
example.com → (apex — needs the ALIAS workaround above)
www.example.com → CNAME → web service
api.example.com → CNAME → api service
Because each Railway service gets its own custom-domain configuration independently, a single project with several services naturally maps to several subdomains of the same root domain — exactly the multi-platform (or, here, multi-service) domain architecture Domain Names & DNS's own capstone lesson walks through as a realistic, complete example.