Migrate to RunxBuild and earn up to $50 in hosting credit on your first deposit.

Calculate your savings
unxBuild
Log in Get Started
Back to Blog Operations

link to domain: The Three Layers Every Custom Domain Has and the Order to Wire Them

Sean

Platform Writer

Jun 18, 2026
7 min read

The fastest answer to “link to domain” is “point an A record at the host.” That is the answer that works about 60% of the time. The other 40% of the time, it does not work because linking a custom domain to a deployed app is three layers, not one. There is the registrar layer (where the domain lives), the hosting layer (where the app runs and which hostname it expects), and the application layer (how the app handles requests for the new hostname). If you skip any layer, the result is a domain that loads the wrong thing, fails TLS, or 404s.

link to domain: The Three Layers Every Custom Domain Has and the Order to Wire Them

Table of contents

The honest short version: the registrar needs the right records, the hosting platform needs the domain mapped to the right service, and the application needs to handle the new hostname. Each layer has its own failure mode, each has its own diagnostic, and the order you wire them matters because each layer depends on the one below it.

link to domain: the three layers every custom domain has and the order to wire them

Table of contents

The direct answer

If you have a deployable app and a domain name you own, the three things you have to do, in order:

  1. At the registrar: add the DNS records your hosting platform tells you to add. Usually a CNAME for www.yourdomain.com pointing at the platform’s hostname, and either an A record or ALIAS/ANAME for the apex yourdomain.com.

  2. At the hosting platform: add the custom domain to the service. The platform will tell you the DNS records to add (step 1) and start issuing a TLS certificate for the new hostname.

  3. In your application code: handle the new hostname. For a static site, this might be a redirect from apex to www or vice versa. For a backend, this is trustProxy and the Host header check.

The order matters because each layer validates the previous one. If the DNS records are wrong, the hosting platform will refuse to issue a certificate. If the platform does not have the domain mapped, the application will never see the traffic even if DNS is right.

Layer 1: the registrar (where the DNS records live)

The registrar is the company you bought the domain from — Namecheap, Cloudflare Registrar, Google Domains, GoDaddy, Porkbun. The registrar holds the DNS records that tell the internet “where does this domain go.”

The records you need depend on what the hosting platform wants:

  • CNAME for subdomains. www.yourdomain.com → your-app.platform.com. This is the canonical “point a subdomain at a host” record. The downside is you cannot use a CNAME at the apex (the bare yourdomain.com without www).
  • A record for the apex. yourdomain.com → 192.0.2.1. This works at the apex, but the IP address can change when the hosting platform rotates infrastructure.
  • ALIAS/ANAME for the apex (the modern fix). yourdomain.com → your-app.platform.com. Some registrars (Cloudflare, DNSimple, Route 53) support this. It is functionally a CNAME at the apex with the TTL benefits of an A record.

The three common failure modes at this layer:

  1. The CNAME target is wrong. A typo, a stale hostname from a previous deploy, an extra dot at the end (platform.com. vs platform.com). The CNAME silently resolves to the wrong place.
  2. The A record IP is outdated. The hosting platform rotated IPs and you did not update. Your domain points at an IP that no longer serves your app.
  3. The TTL is too high. You added the right records but the TTL was 24 hours and your local DNS resolver still has the old cache. Wait it out, or set a short TTL before you make the change.

A diagnostic that catches all three: dig www.yourdomain.com +short (or nslookup on Windows). The answer should match what the hosting platform told you to add. If it does not, the registrar is your problem.

Layer 2: the hosting platform (where the domain is mapped)

The hosting platform (Render, Vercel, Netlify, Railway, RunxBuild, Fly.io) needs to know that your custom domain should serve traffic for your app. Every platform has a “custom domains” section on each service.

The platform will tell you three things:

  1. The DNS records to add. Usually a CNAME for www and either an A record with two IPs (one primary, one fallback) or an ALIAS for the apex. Copy these records exactly.
  2. A verification step. After DNS propagates, the platform checks that the records resolve correctly. This usually takes 5-30 minutes.
  3. A TLS certificate. Most modern platforms issue a Let’s Encrypt certificate automatically once DNS is verified. Some platforms require you to bring your own certificate (Render, for example, has both automatic and custom-cert flows).

The failure mode at this layer is usually one of:

  • You forgot to add the domain to the service. The DNS records resolve to the platform, but the platform has no idea what to do with the traffic because no service is bound to the hostname.
  • The platform is still waiting for DNS propagation. It will tell you “DNS not yet verified” for up to 24 hours. Be patient.
  • The TLS certificate failed to issue. Usually because the platform cannot reach the domain to validate it. Check that the DNS is right and that you do not have a CAA record blocking Let’s Encrypt.

If the platform’s “custom domain” page says “verified” but you still get a 404 in the browser, the problem is layer 3.

Layer 3: the application (where the hostname is served)

Even after DNS and the platform agree, the application itself needs to handle the new hostname. For most apps, this is implicit — the platform routes requests to the service based on hostname, and the service serves the same content for every hostname.

The cases where layer 3 matters:

Static sites with canonical redirects. If you want yourdomain.com to redirect to www.yourdomain.com (or vice versa), the static-site configuration needs to know that. Most static hosts let you set this in the _redirects file or in the platform’s redirect config.

Backends with trustProxy. Express, FastAPI, Flask, and Django all need trustProxy enabled when behind a load balancer that terminates TLS. The proxy adds X-Forwarded-Proto: https; without trustProxy, the app thinks the request was HTTP and redirects to HTTPS, causing a redirect loop.

Apps with Host header validation. Some apps refuse requests for unknown hostnames. After you wire a custom domain, the app sees a new Host header and 404s. Add the hostname to the allowlist.

Cookies and CSRF with the new origin. If your app sets cookies, the cookie domain needs to match the new hostname. CSRF protections that are domain-scoped also need updating.

In practice, layer 3 is the one most teams skip, and the failure shows up as “the domain resolves but the app throws a confusing error.” The diagnostic is to look at the app’s logs for the request that just came in and see what hostname it carried.

The order you wire them (and why order matters)

The right order is layer 2 → layer 1 → layer 3.

  1. Start at the hosting platform. Tell the platform what hostname you want. The platform gives you the DNS records to add.
  2. Add the DNS records. Copy the records the platform gave you, exactly. Wait for propagation (5-30 minutes usually, up to 24 hours for high TTLs).
  3. Verify the platform sees the records. The platform’s custom-domain page should switch from “pending” to “verified.” The TLS certificate gets issued.
  4. Update the application code. Add the hostname to redirects, set trustProxy, update cookie domains.
  5. Test end-to-end. curl -v https://yourdomain.com should return the right content with a valid TLS chain.

If you do step 1 last, the platform has no idea what hostname to issue a certificate for. If you do step 2 without step 1, the records point at nothing. If you skip step 4, you get the “DNS works but the app is confused” failure mode.

The five failure modes that actually happen

  1. DNS points at the wrong IP. dig shows a stale or incorrect IP. Fix: update the A record at the registrar. Wait for TTL.

  2. The hosting platform never got the domain mapped. The DNS is right, but the platform does not know to route traffic to your service. Fix: add the domain in the platform’s custom-domain UI.

  3. The TLS certificate failed. The platform could not issue a Let’s Encrypt cert, usually because the domain did not resolve when LE tried to validate. Fix: wait for DNS propagation, check CAA records, retry.

  4. The app returns 404 on the new hostname. The platform routed traffic correctly, the TLS is valid, but the app does not recognize the hostname. Fix: add the hostname to the app’s allowed-hosts or Host header validation.

  5. The redirect loop. The user hits https://yourdomain.com, gets redirected to http://yourdomain.com (because trustProxy is off), which redirects back to https://. Fix: enable trustProxy in the app framework.

Five failure modes, five fixes, each at a different layer. Diagnose by working from the network up — DNS first, then platform, then app.

TLS, CNAMEs, and the apex domain trap

The apex domain (yourdomain.com without www) cannot use a CNAME. RFC 1034 says apex records must be A or AAAA. Most hosting platforms work around this with:

  • Two A records pointing at platform-owned IPs (the platform rotates these for you). Works everywhere.
  • ALIAS/ANAME records (Cloudflare, DNSimple, Route 53). Functionally a CNAME at the apex. Works on supporting registrars only.
  • CNAME flattening (Cloudflare-specific). Cloudflare resolves the CNAME themselves and serves A records. Works only on Cloudflare DNS.

If you cannot use ALIAS or CNAME flattening, you are stuck with A records. The hosting platform will give you two IPs to use as a fallback when the primary is down. Update those IPs when the platform tells you to (about once a year).

If you are linking a custom domain to a backend service, the same pattern applies — but you also need to think about whether the backend redirects the apex to www or vice versa. Most teams pick one and stick with it for SEO; redirecting the other to the canonical is the standard pattern.

If you are running this on a platform like RunxBuild’s backend services, the custom domain is one toggle in the dashboard, the platform handles the TLS certificate automatically, and the trustProxy and Host header validation are the only app-side concerns. For the cost of running that backend behind a custom domain at production scale, the RunxBuild hosting calculator gives you the per-month number against your current setup.

FAQ

How long does it take for a custom domain to start working?

DNS propagation is usually 5-30 minutes but can take up to 24 hours depending on TTL. The hosting platform’s TLS certificate issuance adds another 1-5 minutes after DNS resolves. Total: usually under an hour, occasionally a full day.

Do I need a CNAME or an A record for www?

CNAME. The hosting platform will tell you the CNAME target. CNAMEs at subdomains are always allowed and easy to change.

Can I use the same domain for two different services?

Yes, but with different subdomains. app.yourdomain.com and api.yourdomain.com can point at two different services. The apex yourdomain.com should point at one canonical service that handles the redirect.

What is the difference between an A record and an ALIAS?

An A record points at an IP. An ALIAS points at a hostname (like a CNAME) but is allowed at the apex. The hosting platform rotates A record IPs; ALIAS records follow the hostname automatically.

How do I redirect yourdomain.com to www.yourdomain.com?

At the hosting platform, set up a static-site redirect. At the registrar, point both A and CNAME at the platform. The platform handles the redirect with a 301 or 302.

What is a CAA record and why is my TLS failing?

A CAA record restricts which certificate authorities can issue certificates for your domain. If you have CAA 0 issue "letsencrypt.org" and your platform uses a different CA, the issuance fails. Remove the CAA record or add the platform’s CA.

How do I check DNS propagation?

dig yourdomain.com +short shows what your local resolver returns. For global propagation checks, use dnschecker.org or similar tools — but the authoritative answer is your own resolver, not a remote probe.

Can I use my own TLS certificate?

Most platforms allow it. You upload the cert and private key in the custom-domain settings. The cert needs to be valid for the hostname, signed by a trusted CA, and not expired. Renewal is on you.

FAQ

How long does it take for a custom domain to start working?

DNS propagation is 5-30 minutes usually, up to 24 hours depending on TTL. The TLS certificate adds 1-5 minutes after DNS resolves.

Do I need a CNAME or an A record for www?

CNAME. The hosting platform will tell you the CNAME target. CNAMEs at subdomains are always allowed.

Can I use the same domain for two different services?

Yes, but with different subdomains. app.yourdomain.com and api.yourdomain.com can point at two different services.

What is the difference between an A record and an ALIAS?

An A record points at an IP. An ALIAS points at a hostname but is allowed at the apex. ALIAS records follow the hostname automatically.

How do I redirect yourdomain.com to www.yourdomain.com?

At the hosting platform, set up a static-site redirect. At the registrar, point both A and CNAME at the platform.

What is a CAA record and why is my TLS failing?

A CAA record restricts which CAs can issue certificates for your domain. If your CAA blocks the platform’s CA, issuance fails. Remove the CAA or add the platform’s CA.

How do I check DNS propagation?

dig yourdomain.com +short shows what your local resolver returns. For global checks, dnschecker.org or similar tools.

Can I use my own TLS certificate?

Most platforms allow it. You upload the cert and private key in the custom-domain settings. Renewal is on you.

#Custom Domain#DNS#Domain Setup#Deployment#TLS