Custom domains, DNS, and HTTPS for a new app
How DNS records, TLS certificates and verification steps make a deploy reachable by name, and how to find which of four layers is failing from the symptom.
Four separate systems make a domain work
A custom domain involves a DNS record, a host mapping on the deployment platform, a TLS certificate, and the application's own redirects or callback URLs. A browser can fail at any one of these layers. Treating “DNS propagated” as the end of setup misses the certificate and routing steps.
The platform usually gives you a target hostname or address. Add your custom hostname in its domain settings, then create the exact DNS record it requests. A subdomain often uses CNAME. The apex domain may need ALIAS, ANAME, or provider-specific flattening because ordinary CNAME rules do not fit the apex alongside other records.
Trace the request
DNS only gets the browser to an address. The edge must still recognize app.example.com and present a certificate that covers it. A certificate for the platform's default domain does not cover your custom hostname.
Use dig +short app.example.com to check DNS and curl -Iv https://app.example.com to inspect TLS and the HTTP response. A correct DNS answer with a certificate error points to issuance or hostname configuration, not application code. A valid certificate with a 404 may mean the edge does not map that host to your app.
The app needs to know its new public origin
After the domain works, update OAuth redirect URIs, email links, CORS allowed origins, cookie domain settings where used, and absolute URL generation. Decide whether www.example.com or example.com is canonical and redirect the other. Avoid redirect loops caused by disagreeing proxy and app HTTPS settings.
DNS caches respect TTLs but different resolvers can hold old answers temporarily. Do not delete the old target until the new route and certificate are healthy. Test both an uncached resolver and an ordinary browser session.
Diagnose by symptom instead of waiting longer
If dig returns the old target, investigate the record and resolver cache. If it returns the new target but the browser reports a certificate mismatch, check whether domain validation finished and whether the certificate covers that exact hostname. If TLS succeeds but the page is a platform 404, inspect the host-to-app mapping. If the app loads but login fails, inspect callback URLs and cookies.
These are different failures; “DNS propagation” is not a useful diagnosis for all of them. Compare the apex and www hostnames independently. A certificate can cover one while the other redirects incorrectly, and a CNAME for a subdomain does not automatically configure the apex.
For a launch cutover, lower the existing record's TTL ahead of time if your DNS provider and traffic plan allow it. Keep the old app available during the transition, monitor both hostnames, and raise the TTL only after the new route is stable. A low TTL helps cache turnover but cannot compensate for an invalid record or missing TLS setup.
How this works on ProductEcho
Open the app's Custom domains card in the console, or ask your agent to add the domain. Either way you get two DNS records to publish:
The TXT record proves you own the domain. A CNAME alone never claims it. The CNAME sends visitors to the app. A static site's CNAME points to edge.productecho.net instead, and the console always shows the exact value for your app, so copy it from there.
The card then walks the domain through Waiting for DNS, Securing with HTTPS and Live. ProductEcho moves a domain forward when it is checked, not in the background. The console checks for you while the card is open, and Check now does it on demand. If you use your agent, ask it to check the domain after you publish the records. When the DNS is right, a container app's certificate is usually issued within a couple of minutes. It renews on its own, and the ProductEcho address keeps working beside your domain.
- Limits. Each app can have up to three custom domains, and your plan sets the total across the workspace. A domain that never proves ownership is dropped after 14 days.
- A private app. A private app has no public address, so a domain has nothing to point at. Make the app public first, then add the domain. To make an app private later, remove its custom domains first.
- A root domain. Most DNS providers cannot put a CNAME on
example.com. Use ALIAS, ANAME or CNAME flattening with the same value, or use awwwaddress. - A CAA record. If your domain has one, it has to allow Let's Encrypt and Google Trust Services, or the certificate cannot be issued.
- Stuck on HTTPS. Make sure the CNAME is the only record for that name, then use Check now.
- A record changes later. If the CNAME is removed or points elsewhere after the domain is live, the next check shows Needs attention and lists the records to restore. Put them back and the site returns.
Further reading
Cloudflare's DNS record reference explains record choices. Let's Encrypt's certificate overview explains why domain validation and issuance are distinct from DNS routing.