How to Connect a Custom Domain and SSL to Your SaaS Before Launch

Your product URL shows up in more places than you plan for: launch posts, cold emails, invoices, the footer of every page you ship. When that URL is still app-7f3c2b.yourplatform.io, every one of those touchpoints quietly says "temporary." And when SSL isn't set up correctly, browsers go further and label the page Not secure — a warning your prospective customer reads before your headline. A bare platform URL costs you trust at exactly the moment you're trying to earn it, and trust is what turns a visitor into a trial.

There's a practical cost too. OAuth providers expect stable redirect URLs, payment webhooks and cookie scoping behave better on a hostname you own, and email links from your domain are far less likely to look like phishing. Once the world points at your domain instead of your provider's subdomain, you can also change hosts without changing your address.

The good news: custom domain SSL setup for SaaS founders is a bounded, learnable task. It's a few DNS records at your registrar, a setting in your hosting platform, and a certificate a certificate authority issues once you prove you control the domain. Modern platforms automate the certificate part. Your job is the DNS layer, two or three decisions, and careful verification — which is what this guide covers.

Custom Domain SSL Setup for SaaS: What Actually Happens

Three things happen when you connect a domain. Knowing them makes every later step obvious.

First, DNS. The Domain Name System is the internet's address book. Your registrar sold you the right to use example.com; DNS records tell the world what that name points to. A CNAME record maps a name like app.example.com to a hostname your platform owns — something like app-target.example-host.com. An A record maps a name directly to an IP address. When a visitor types your domain, resolvers walk down to your domain's nameservers, read your records, and connect the visitor to your platform's edge, which serves your app.

Second, the certificate. A TLS certificate does two jobs: it lets browsers encrypt traffic to your server, and it proves the server answering on your domain is really yours, not an impostor. Before a certificate authority issues one, it demands proof of domain control. With ACME — the automation protocol behind Let's Encrypt and most modern platforms — the proof is mechanical: the platform either serves a one-time token file at your domain (an HTTP-01 challenge) or adds a short-lived TXT record (DNS-01). Pass the challenge, get the certificate, install it at the edge. From your side this is usually invisible.

Third, renewal. Certificates expire on purpose — 90 days for Let's Encrypt-style certificates, so a stolen key has a short shelf life. A platform with automatic SSL renews in the background; you never think about it again. This is what bites founders who upload a manual certificate and forget: an expired certificate produces a full-screen browser warning that looks identical to being hacked. Nothing about your app changed. It just stopped being provably yours.

The mental model that saves you later: you own the DNS records at your registrar; the platform owns certificate issuance and renewal as long as your DNS points at it. Break that link — move the domain, delete a record, add a proxying CDN — and you silently break future renewals. The failure surfaces weeks later as an expiring certificate, long after you remember touching anything. Everything else in this guide is about managing that boundary deliberately.

Prerequisites: Get These Ready Before You Touch DNS

• A deployed app that works on its platform URL. Load it, hit your health endpoint, expect a 200. If the app is broken, fix that first — never change two variables that both produce "site doesn't load" at the same time.
• A domain you actually control. Log into your registrar today and find the DNS records panel. Note whether DNS is hosted at the registrar or a separate provider — you edit records wherever the domain's nameservers point, which is not always where you bought the name.
• A hostname decision (next section). Know your canonical hostname and what happens to the others before you create records, not after.
• Awareness of anything else living on the domain. If you run email on example.com — MX records, SPF, DKIM — adding records is safe, but replacing nameservers or deleting records can break mail silently. If a marketing site already lives on the apex, your plan has to respect that.
• Optionally, lower TTLs. TTL is how long resolvers cache a record before checking again. Dropping it to 300 seconds on records you'll change, a day ahead, makes every mistake cheaper to undo. Free insurance.
• The platform's exact DNS targets. Every platform publishes the precise CNAME or A values to use. Copy-paste them — retyping from memory is the most common self-inflicted failure in this process.

How to Connect Your Domain to a Deployed App, Step by Step

1. Confirm the app is healthy on its platform URL. Open it, hit the health endpoint, confirm a 200 and a normal page render. This is your baseline and your fallback if DNS goes sideways.
2. Choose your canonical hostname. For a SaaS product, app.example.com or www.example.com are the common picks. The decision logic is in the next section.
3. Copy the exact DNS target from your hosting platform. You'll get a CNAME target for subdomains, and either fixed IP addresses for A records or an ALIAS/ANAME option for the apex.
4. Create the DNS records at your DNS provider:

; Example records for example.com — values are placeholders.; Use the exact target your platform gives you.app.example.com. CNAME app-target.example-host.com.www.example.com. CNAME app-target.example-host.com. ; Apex options — use whichever your DNS provider supports:example.com. A 203.0.113.10example.com. ALIAS app-target.example-host.com.

1. Register the custom domain in your platform's dashboard. Most platforms must know the hostname before they'll issue a certificate for it. Follow the documented order — some want the domain added before DNS resolves, some verify automatically afterwards.
2. Wait for DNS to resolve. Run dig app.example.com +short or use an online propagation checker. Fresh subdomains usually resolve in minutes; changes to names that existed before take as long as the old TTL.
3. Let the certificate issue. On platforms with automatic SSL this happens once DNS resolves. If there's a manual "issue certificate" button, click it once and wait — hammering it can trip the certificate authority's rate limits and lock you out for an hour.
4. Configure redirects. Force HTTPS, and 301-redirect every non-canonical hostname (apex, www, or both) to your canonical one, at the platform level where possible. One redirect layer, not two.
5. Update everything that references your app URL. OAuth redirect URIs (Google and GitHub sign-in break without this), payment webhook endpoints, CORS allowlists, framework "allowed hosts" settings, email templates, and any hardcoded http:// URLs in your codebase.
6. Verify end-to-end on the real hostname using the checklist later in this article. A domain that loads the homepage but can't complete an OAuth signup is a launch-day surprise you can prevent tonight.

Subdomain vs Apex vs www: Picking the Hostname That Serves Your SaaS

You have three realistic candidates, each with a trade-off.

The apex (example.com) is the shortest thing a person can type. But it's historically awkward: DNS doesn't allow a CNAME at the apex because it conflicts with the zone's required records, so you need either A records to fixed IPs or ALIAS/ANAME flattening, which not every DNS provider supports. Hosting the product on the apex also couples your bare domain to your app host — move the app, and you're editing records that may also carry email or a marketing site.

www is unfashionable but operationally excellent. Technically it's just a subdomain: it can be a CNAME, point anywhere, and move to a CDN or a new host later without touching your apex records. Nothing about "www" limits SEO if you're consistent.

A product subdomain (app.example.com) is the common SaaS pattern: the marketing site lives on the apex, the product runs on app., and each can move independently. That separation matters when your marketing site is a different tool from your app — which it usually is.

Whatever you choose, follow one rule: pick a single canonical hostname and 301-redirect the others to it. Fragmented canonicals split your analytics, split cookies (scoped per host), and split search signals. For a solo founder, the pragmatic default is to serve the product on a CNAME-able hostname — www or app. — and redirect the apex to it. If your DNS provider supports ALIAS at the apex and you want the bare domain, that works too. Choose once, redirect everything else.

SSL Certificates, Explained for Founders Who Don't Run Servers

Think of a certificate as a tamper-evident ID card for your domain, issued by a certificate authority (CA) that browsers already trust. Two flavors exist, and the difference is who does the renewal work.

Automated certificates (ACME / Let's Encrypt-style). Your platform requests the certificate on your behalf, proves domain control through the HTTP-01 or DNS-01 challenge, installs it, and renews it. This is what "automatic SSL" means in a platform feature list, and it's what you should prefer: when DNS points correctly and the challenge path is reachable, you never touch certificates again.

Manual certificates. You buy or generate a certificate, upload it, and renew it by hand before expiry. Renewal risk is the whole problem: an expired certificate produces a full-page browser warning your users will read as a breach, and it happens because nobody set a calendar reminder. Manual certificates only make sense for unusual topologies — your own load balancer, an enterprise CA a customer mandates, or a platform without automation.

Even with automation, four things quietly break renewal:

• DNS moves. You point the domain at a CDN or a new host, the old platform can no longer prove control, and renewal fails. This is why "check the certificate" belongs on your post-migration checklist.
• Proxy modes. Some CDN configurations proxy your traffic and intercept the ACME challenge, preventing issuance against your origin. Follow the platform's documented CDN setup if you use one.
• Firewall rules. If the challenge path (typically under /.well-known/acme-challenge/) is blocked, issuance fails. Allow it.
• CAA records. A CAA record is a DNS record that says "only CA X may issue certificates for this domain." If you added CAA records for security and your platform's CA isn't on the list, issuance fails with a confusing error. Check for CAA records before launch if any exist.

One forward-looking note: if you plan to serve per-customer subdomains (acme.example.com, globex.example.com), you'll need a wildcard certificate, which requires the DNS-01 challenge. Not every platform supports wildcard issuance, so verify before you commit to multi-tenant subdomains as an architecture.

How to Verify Your Domain and SSL Before Launch

"Looks fine in my browser" is not verification. Run these checks deliberately:

1. HTTPS loads with a padlock and no warning, on every hostname you serve — canonical, apex, www. A cert covering only www means your apex visitors see a warning.
2. HTTP redirects to HTTPS, permanently. Test from a terminal, because it shows you the raw status codes:

curl -I https://app.example.com# expect: HTTP/2 200 — your app answers over TLS curl -I http://app.example.com# expect: 301 or 308, with Location: https://app.example.com

1. Check the redirect matrix. Every combination — http and https, apex and www, with and without a path — should land on the canonical hostname over HTTPS in a single hop.
2. Check the certificate expiry date. Click the padlock in your browser, open the certificate details, and note the expiry. On recent curl versions you can also run curl -vI https://app.example.com 2>&1 | grep -i expire. If renewal is automatic, the date should be ~90 days out, which means issuance happened today. If it isn't automatic, set a calendar reminder 30 days before expiry.
3. Walk the real flows on the real hostname. Sign up, log in with an OAuth provider, complete a test-mode checkout, and confirm your payment provider's webhooks arrive. Homepage checks miss exactly the integrations that break on hostname changes.
4. Watch the browser console on signup, pricing, and checkout pages. Mixed-content warnings there mean some asset or API call is still going over plain HTTP — see the failure table below.

Common Domain and SSL Failure Modes (and Fixes)

Most domain problems announce themselves clearly once you know the vocabulary:

• Symptom: Domain won't resolve at all (NXDOMAIN) — Likely cause: Record missing, typo in the CNAME target, or the name entered as a full hostname where the provider wants only the subdomain — creating app.example.com.example.com — Fix: Verify with dig app.example.com +short; correct the record; wait out the old TTL
• Symptom: Resolves to the wrong place or an error page — Likely cause: Stale record still pointing at an old host, or the platform doesn't recognize the hostname — Fix: Remove stale records; add the custom domain in the platform dashboard and wait for verification
• Symptom: "Your connection is not private" / certificate name mismatch — Likely cause: Cert issued for a different hostname (www only, while visiting the apex), or you visited before issuance completed — Fix: Add every hostname you serve in the platform; wait for issuance; re-test
• Symptom: Certificate worked once, then expires anyway — Likely cause: CAA record restricts CAs and the platform's CA isn't listed, so renewal fails silently — Fix: Add a CAA record permitting the platform's CA (or remove the restrictive one), then re-issue
• Symptom: Renewal keeps failing — Likely cause: DNS moved behind a CDN proxy that intercepts the ACME challenge, or a firewall blocks the challenge path — Fix: Point DNS directly at the platform or follow its CDN instructions; allow the challenge path; re-issue
• Symptom: http:// works but https:// fails or times out — Likely cause: HTTPS binding or force-HTTPS configured before the certificate existed — Fix: Confirm the certificate first, then enable forcing — one redirect layer only
• Symptom: Redirect loop (ERR_TOO_MANY_REDIRECTS) — Likely cause: Two layers both forcing HTTPS while the app behind a proxy thinks the request is still HTTP — Fix: Leave forcing to the platform; mark the proxy as trusted so the app sees the real scheme
• Symptom: Page loads but fonts, scripts, or images fail; console shows mixed content — Likely cause: Hardcoded http:// asset URLs in templates, CSS, or API calls — Fix: Replace with https:// URLs; search your codebase for "http://" before launch
• Symptom: Some visitors still see the old site — Likely cause: DNS caching — resolvers hold the previous record until its TTL expires — Fix: Lower TTLs before the change; verify from a fresh network or online checker; wait it out

Notice the pattern: nearly all of these failures live at the boundary you own — DNS records, stale caches, redirect rules, and URLs inside your app — not in the certificate machinery. Automated issuance is boring when its inputs are correct.

Your Rollback Plan for DNS Changes

DNS is the rare production change where you can prepare the undo completely before you need it.

Export or screenshot the entire zone first. Every record, value, and TTL. Most providers can export a zone file; if yours can't, screenshot each record. Write down what you're about to change, so "put it back" means something at 9 a.m. with your heart rate up.

Add, verify, then remove — in that order. Create new records alongside old ones, confirm the new hostname serves correctly over HTTPS, and only then delete the old records. Never delete anything during the launch window itself.

Change one hostname at a time. Point www or app. first, verify it end to end, then handle the apex. If something breaks, you know which change caused it and you have one record to revert instead of five.

Keep the platform URL alive through launch week. It's your bypass lane: if DNS misbehaves, you can still reach and demo the app while you fix records. Don't decommission it because it looks untidy.

Lower TTLs before, raise them after. At 300 seconds, a bad record reverts in minutes; once things are stable for a few days, raise them back.

Time the change for a weekday morning, your time zone. You want a full attention window and a reachable support channel — not a Friday 6 p.m. surprise. If customers already use the old URL, tell them what's changing and when.

One distinction worth writing down: DNS rollback is not deploy rollback. If the release itself is the problem, that's your platform's blue/green or rollback mechanism — a separate lever you should know how to pull before launch day.

Where Deployxa Removes Most of This Work

Everything above is learnable in an afternoon, but it's also work you'll repeat for every app, every staging environment, and every client project. This is where a managed platform earns its keep.

Deployxa deploys Git repositories or local projects as containerized applications, with automatic framework and runtime detection across the Node.js, Python, Go, PHP, Rust, and .NET ecosystems — no Dockerfile needed for supported stacks. Custom domains are supported and SSL is automatic: you add the domain in the dashboard, create the DNS records at your registrar, and the platform handles certificate issuance and renewal from there. The certificate half of this guide collapses to "add the domain."

The DNS half stays yours — records, hostname choices, redirects — because nobody but you should control your registrar. The app-level work stays yours too: Deployxa won't pick your canonical hostname, fix mixed content in your templates, or update your OAuth redirect URIs. Those are decisions about your product, not your infrastructure. Under the hood, apps run on isolated tenant networks as long-lived workloads — a real, persistent application behind your domain, not a function that wakes up on request.

Two operational details round out the picture. Releases use blue/green: the new version runs in a standby slot, passes health checks, and only then receives traffic, with the prior release kept warm for a short rollback window — rollback can be sub-second inside that window. And if a build fails, AI-assisted build repair analyzes the failure and may apply bounded fixes before retrying; helpful, not guaranteed. The exact DNS targets and the full domain flow are documented in the Deployxa docs.

Pre-Launch Domain and SSL Checklist

Run this list top to bottom the week before launch, then again on launch morning:

• [ ] App is healthy on its platform URL before any DNS change
• [ ] Canonical hostname chosen; every other hostname 301-redirects to it
• [ ] DNS records created exactly as the platform specifies (CNAME for subdomains, A/ALIAS for apex)
• [ ] TTLs lowered to ~300 seconds on records you touched, at least a day before the change
• [ ] Custom domain added in the hosting platform; certificate issued for every hostname you serve
• [ ] CAA records (if any) permit the platform's certificate authority
• [ ] https:// loads with a padlock and no warnings on every hostname
• [ ] http:// 301-redirects to https:// on every hostname, verified with curl -I
• [ ] Certificate expiry date noted; automatic renewal confirmed working
• [ ] Browser console clean on signup, pricing, and checkout pages — no mixed content
• [ ] OAuth redirect URIs, payment webhook endpoints, CORS, and allowed-hosts settings updated to the real domain
• [ ] DNS zone exported or screenshotted; rollback steps written down
• [ ] Old platform URL still works and will through launch week
• [ ] Calendar reminder set for ~25 days after launch to confirm the first automatic renewal happened

Rehearse the Whole Flow Before Launch Day

DNS and SSL are exactly the kind of task you want to have done once before it counts. The cheapest rehearsal: create a non-production project on Deployxa, deploy the app you're about to launch, and point a spare subdomain you already own — staging.yourdomain.com works — through the full flow: records, issuance, redirects, verification, and the checklist above. You'll learn your registrar's quirks and your platform's exact DNS targets with zero pressure, and on launch day the real domain becomes a ten-minute exercise instead of a leap. Rehearse on staging, then ship the real thing.