By now, this whole subcategory's pattern should feel familiar — a CNAME for subdomains, a workaround for the apex, automatic HTTPS once DNS resolves correctly. This lesson is Render's specific variation on that same pattern, worth walking through precisely rather than assuming it's identical to Vercel's or Railway's.
Intermediate
2 min read
The records Render actually asks for
Subdomain (www.example.com): CNAME → your-service.onrender.com
Apex domain (example.com): A record → Render's documented apex IPs
(or ALIAS/ANAME, if your DNS provider supports it)
Render's subdomain path is the same CNAME mechanism every platform in this subcategory uses. For the apex domain, Render publishes specific A records to use directly (a different mechanism than Vercel's single shared anycast IP, and different again from Route 53's AWS-specific Alias record) — Domain Names & DNS's own lesson on this exact problem names this pattern explicitly: every platform solves the same DNS-specification limitation with its own variation, and Render's variation is "use these specific A records we publish," rather than a shared IP with Host-header routing or a registrar-level Alias extension.
Domain verification: confirming ownership before serving traffic
Render requires the domain to be added in its own dashboard and the corresponding DNS record to actually be detected, the same two-sided confirmation every platform in this subcategory requires — adding the DNS record alone, without also registering the domain in Render's dashboard for the specific service it should route to, leaves Render with no way to know which of its customers' services that domain is actually meant to reach.
Automatic HTTPS, and the one real difference worth knowing: certificate provisioning timing
Like Vercel and Railway, Render provisions a TLS certificate automatically via Let's Encrypt once DNS is confirmed pointing correctly — the practical difference worth knowing is that this can take up to a few minutes longer on Render specifically than on Vercel's more tightly-integrated pipeline, which is a real, documented platform characteristic rather than a sign something's broken. The same general troubleshooting order applies regardless: confirm DNS propagation first (Domain Names & DNS's own TTL lesson), and only suspect an actual certificate-issuance problem if DNS has been correctly resolving for a genuinely extended period with no certificate appearing.
Connecting this to the multi-platform architecture this whole subcategory builds toward
A real small product's domain might route example.com and www to a Vercel-hosted frontend, api.example.com to a Render-hosted backend, and status.example.com to a separate status-page service — each subdomain configured through its own platform's specific flow, all coexisting under one domain's overall DNS configuration, exactly the realistic multi-platform setup Domain Names & DNS's own closing capstone lesson walks through end to end.