Dec 17, 2025·8 min
Custom domain setup for web apps: DNS, SSL, and cutover
Custom domain setup for web apps with clear DNS record steps, SSL issuance, redirects, and a low-risk cutover plan to avoid downtime and cookie issues.
Custom domain setup for web apps with clear DNS record steps, SSL issuance, redirects, and a low-risk cutover plan to avoid downtime and cookie issues.
A custom domain is more than a nicer URL. The moment you move from a platform address (for example, an app you built on Koder.ai under a platform subdomain) to your own domain, browsers and networks treat it as a different site. That affects routing, security, and how user sessions behave.
Once you switch to a custom domain, a few things change immediately:
www or the apex domain, and you need consistent HTTP to HTTPS rules.old-platform.example will not automatically work on app.yourdomain.com.Short outages usually come from timing. DNS can start sending traffic to the new host before the SSL certificate is ready, which leads to browser warnings. Or the opposite happens: SSL is ready, but many users still hit the old place because their DNS cache hasn’t expired.
Redirects can also break logins in subtle ways. A redirect that changes the hostname (apex to www, or vice versa) can drop cookies if they were set for the other host. Auth providers can fail if their callback URL is still the old domain.
A low-risk cutover means you plan for overlap: keep the old URL working, bring up the new domain in parallel, switch traffic at a predictable moment, and make rollback as simple as changing DNS back.
Before you change anything, write down exactly which names you want users to type, and which names should quietly redirect. Most “why is this half-working?” moments come from a team never agreeing on the one true hostname.
Start with the big choice: apex (example.com) or www (www.example.com) as the primary. Either can work, but pick one and treat the other as a redirect. This matters later for cookies too: sessions are usually easiest when the app lives on one consistent host.
Next, decide which subdomains you need now, and which can wait. A common pattern is app.example.com for the web app and api.example.com for APIs, with admin.example.com or assets.example.com added later. If you’re setting up a custom domain on a platform like Koder.ai, these choices map directly to what you’ll validate for SSL and what you’ll point in DNS.
Many people buy a domain at a registrar, but DNS may be hosted somewhere else. Confirm where records are edited today, who has access, and whether any automation is managing changes (company IT, an agency, or a managed DNS provider). If you can’t log in and see current records, stop and fix that first.
Also audit what already uses the domain. Email is the classic trap: you can break mail delivery by deleting or overwriting records.
Before proceeding, capture these decisions in writing:
www) and the redirect directionIf marketing already runs email on example.com, keep mail-related records untouched while you add only what the app needs.
Most of the risk in a custom domain move isn’t the app itself. It’s one wrong DNS change that sends traffic to nowhere, breaks email, or makes SSL validation fail.
An A record points a name to an IP address. In plain terms: “send people to this server.” It’s common for the apex (example.com) when your provider gives you a fixed IP.
A CNAME record points one name to another name. In plain terms: “treat this name as an alias of that hostname.” It’s common for www.example.com pointing to a platform hostname.
Many DNS providers also offer ALIAS/ANAME at the apex. It behaves like a CNAME but works for example.com. If your provider supports it, it can be easier to manage because the target can move without you touching IPs.
A simple mental model:
You’ll often add TXT records for domain ownership checks (platform verification) and for SSL certificate validation (some CAs validate via a TXT token). TXT is also used for email policy like SPF. Accidentally deleting or replacing an existing SPF TXT can break mail delivery.
TTL controls how long other systems cache your DNS answer. A day before cutover, lower TTL on the records you plan to change (commonly 300 to 600 seconds). After everything is stable, raise it again to reduce query load.
Before editing, export or screenshot the current zone. Write down each record you will change, its old value, new value, and TTL. If something goes wrong, rollback is restoring the previous values.
This matters most when your domain already has MX, DKIM, or other TXT records for email.
SSL (the lock icon) encrypts traffic between the browser and your app. Modern browsers and many APIs expect HTTPS by default. Without it, you can get warnings, blocked requests, and features like service workers, geolocation, and some payment flows may stop working.
To issue a certificate, the certificate authority must verify you control the domain. The common validation methods are HTTP validation and DNS TXT validation:
DNS validation is often easier when you’re using a CDN or when your app isn’t reachable on the new domain yet.
Where the certificate is issued depends on your setup. Some teams issue certs directly on their hosting stack, some do it at the CDN, and some platforms that support custom domains handle it for you (for example, Koder.ai can manage the certificate during domain setup). What matters is knowing who owns the certificate lifecycle, including renewals.
Certificate issuance isn’t always instant. DNS propagation, validation checks, and rate limits can slow things down. Plan for retries and avoid scheduling your cutover for the last possible minute.
A practical timing plan:
A certificate must cover every hostname users will hit. Check the SAN list (Subject Alternative Names). If your app will be available on both example.com and www.example.com, the certificate must include both.
Wildcards (like *.example.com) can help for many subdomains, but they don’t cover the apex domain (example.com).
Concrete example: if you only issue a cert for www.example.com, users who type example.com will still see warnings unless you redirect at a layer that already has a valid certificate for example.com.
Redirects sound simple, but most domain problems show up here: loops, mixed content, and users getting logged out because they bounced between hosts.
Pick one canonical host and stick to it: either www.example.com or example.com (apex). The other entry point should redirect to your chosen canonical host so cookies, sessions, and SEO signals stay consistent.
Safe defaults:
http:// to https:// for every requestFor HTTP to HTTPS, avoid rules that bounce users back and forth. The easiest way to prevent loops is to base the decision on what the request actually was. If your app sits behind a proxy or CDN, configure it to respect forwarded headers (for example, a header that says the original scheme was HTTP). Otherwise, your app may think every request is HTTP and keep redirecting forever.
During a move, keep old paths alive. If you’re changing routes (like /login to /sign-in), add explicit redirects for those paths. Don’t rely on a blanket redirect to the homepage. It breaks bookmarks and shared links.
Hold off on HSTS at first. If you enable it too early and later need to serve HTTP for validation or troubleshooting, browsers may refuse. Wait until HTTPS is stable and you’ve confirmed subdomain coverage.
To test redirects without impacting everyone, use a temporary test hostname, try a few real deep links (including auth pages), and run a command-line request that shows each redirect step and final destination.
A safe cutover is mostly timing. You want your new domain ready and tested before any real users are sent to it, and you want DNS changes to spread quickly so you’re not stuck waiting during an incident.
Lower your DNS TTL (for the records you will change) well ahead of time. Do it the day before if you can, then wait out the old TTL window so caches have time to pick up the lower value.
Next, add the custom domain in your hosting/provider and finish whatever verification they require. If you’re using a platform like Koder.ai, add the domain there first so the platform can confirm ownership and prepare routing.
Issue SSL early. Certificates can take minutes or longer depending on validation, and you don’t want that delay during the switch.
Before making the domain public, do a private test: hit the new endpoint in a way that doesn’t depend on public DNS (for example, using a temporary host entry on your own machine) and confirm the site loads over HTTPS with the right certificate.
Use a staged approach so you can stop quickly if anything looks off:
www) before switching users.If you can’t do a true canary at the DNS level, you can still stage by switching only one hostname first (for example, www) and leaving the apex untouched until you have confidence.
Write down exactly what you will revert (which records, what values), and who will do it. Rollback is usually putting DNS back the way it was.
Make sure the old setup is still valid (including SSL on the old domain) so users can fall back cleanly while you fix the new path.
A domain change isn’t just a DNS change. For many apps, “being logged in” depends on cookies that browsers tie to a specific hostname. If you switch from one hostname to another, the browser may stop sending the old cookies, and your app looks like it logged everyone out.
Cookie settings are usually the reason:
app.old.com won’t be sent to app.new.com. A cookie set for .example.com can work across app.example.com and www.example.com./api), your web UI might not see it.Lax is often OK, but some SSO or payment redirects may need None plus Secure.To reduce risk, plan a short transition where both domains work. Keep the old hostname answering requests and redirect carefully, but allow sessions to be refreshed on the new domain. If you can, use a shared session store so a user who hits either hostname can be recognized.
If you use SSO or OAuth, update settings before cutover: callback URLs, allowed origins, and any “audience” or redirect URI allowlists. Otherwise logins may succeed at the identity provider but fail when returning to your app.
Test the flows that usually break first: sign up (and email verification), login/logout, password reset, checkout or payment return, and multi-tab sessions.
Example: if you redirect www.example.com to example.com, make sure cookies are set for .example.com (or consistently use one hostname). Otherwise users bounce between hostnames and lose their session.
Most domain problems aren’t “mystery internet issues.” They’re small mismatches between DNS, certificates, and redirect rules that only show up after real users hit the site.
One easy trap is the apex domain (example.com). Many DNS providers don’t allow a true CNAME at the apex. If you point the apex to a CNAME anyway, it may fail silently, resolve inconsistently, or break only on some networks. Use what your DNS host supports (often an A/AAAA record, or an ALIAS/ANAME-style record).
Another frequent cause of downtime is flipping DNS before SSL is ready on the new endpoint. Users arrive, the app loads, and then the browser blocks it because the certificate is missing or only covers part of your hostnames. In practice, you usually want the certificate to cover both example.com and www.example.com, even if you plan to redirect one to the other.
Common mistakes that create outages or strange behavior:
www to apex, then apex back to www), or forcing HTTP in one place and HTTPS in anotherhttp:// assets, which triggers browser warnings and broken featuresA quick sanity check: open both hostnames (www and apex) over HTTPS, log in, refresh, and confirm the address bar never flips back to HTTP.
If you’re doing this on a platform like Koder.ai, confirm custom domains are connected and SSL is issued before you touch production DNS, and keep a rollback option ready so a bad redirect or record change doesn’t linger.
A calm cutover is mostly prep work. The goal is simple: users should keep logging in, cookies should keep working, and you should be able to roll back fast if something looks off.
Do these while traffic is still going to the old domain. Give yourself a day if you can, so DNS changes have time to settle.
www, api, etc.) and choose your SSL validation method (DNS or HTTP).www to apex (or the other way), and one canonical host.When you flip DNS, treat the first hour like an incident drill. Watch real user flows, not just status dashboards.
Even if Koder.ai (or another platform) handles custom domains and SSL for you, this checklist still matters. Most issues come from DNS and redirects, not app code.
Your app is running on a temporary platform address like myapp.koder.ai. It works, but you want customers to use example.com, with www.example.com redirecting to the apex, and everything forced to HTTPS.
A simple DNS plan keeps risk low. Before changing anything, note the current working state (take a snapshot if your platform supports it, as Koder.ai does) and reduce DNS TTL to something short a day ahead of time.
Add the new records while leaving the existing platform URL untouched:
example.com: A/ALIAS record pointing to the hosting target your platform provideswww.example.com: CNAME pointing to example.com (or to the platform target, depending on the provider)myapp.koder.ai as-is so you always have a known-good fallbackOnce DNS is in place, request SSL for both hostnames (example.com and www.example.com). Don’t switch traffic until the certificate is issued and active, otherwise users will hit browser warnings.
Cutover timeline with clear checkpoints:
example.com in an incognito window (home page, static assets, API calls)www to apex)After the move, validate cookie behavior. Log in, refresh, and check you stay logged in on both www and apex. If sessions break, it’s often a cookie domain or SameSite setting that still assumes the old host.
After the cutover works, the job isn’t done. Most domain moves fail later because nobody notices slow drift: a certificate nearing expiry, a rushed DNS change, or a redirect tweak that breaks a login flow.
Set up a small monitoring routine you’ll actually keep. You don’t need an enterprise tool to start, but you do need a few signals you trust: availability checks for key pages (home, login, and one authenticated page), certificate expiry alerts (for example, at 30 days and again at 7 days), error-rate tracking (watch 4xx/5xx spikes, not just uptime), and occasional redirect validation (HTTP goes to HTTPS, and the preferred hostname wins).
Keep a short rollback window, even if everything looks fine. For 24 to 72 hours, keep the previous setup ready (old DNS targets, old hosting config, old TLS settings) so you can revert quickly if a hidden issue appears, like a payment callback or an OAuth provider still pointing at the old domain.
Once you’re confident, raise DNS TTL values back up. Low TTL is useful during change, but it adds load to resolvers and increases the impact of small mistakes later. Pick a normal TTL that matches how often you expect changes (many teams choose 1 to 4 hours).
Finally, document the final state while it’s still fresh: which records exist (type, name, value, TTL), which hostnames are supported, and the exact redirect rules. Include where certificates are issued, what they cover (apex, www, subdomains), and who owns renewals.
If you build and deploy on a platform, it helps when domains are treated as a first-class feature and rollback is simple. On Koder.ai, custom domains sit alongside snapshots and rollback, which can make future domain and redirect changes less stressful when something needs to be undone quickly.
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.