All posts
5 min read

How to Connect a Custom Domain to Your App: DNS Without the Jargon

Your app works at a long platform URL, and you want it at yourname.com. What DNS records actually do, A vs CNAME in plain English, the apex-domain problem, how HTTPS gets issued, and how to fix the usual errors.

deploymentgetting starteddomainsno-code

Your app is live at something like my-app-x7f2.someplatform.app. It works. It also looks temporary, is impossible to remember, and isn't something you'd put on a business card.

Connecting your own domain is the easiest part of launching an app — usually ten minutes of work and some waiting. It's also the part people find most mysterious, because it happens in a settings page full of acronyms. Here's what's actually going on.

The two things you need

  1. A domain you own, bought from a registrar — Cloudflare, Namecheap, Porkbun, and many others. Expect roughly $10–15 a year for a .com.
  2. A host that supports custom domains for your app — almost all do, though some only on paid plans.

The registrar is where you own the name. The host is where your app runs. DNS is the instruction that connects the two.

What DNS does

DNS is the internet's phone book. When someone types yourapp.com, their browser asks DNS where that name lives, gets back an address, and connects to it.

Connecting a domain means adding an entry to your domain's DNS that says "this name lives at my host." You do that by adding records in your registrar's (or DNS provider's) dashboard.

The two records that matter

A record: "this name is at this IP address"

An A record points a name at an IP address — a number like 203.0.113.10.

Type: A
Name: @            (the "@" means the bare domain, yourapp.com)
Value: 203.0.113.10

CNAME record: "this name is an alias for that name"

A CNAME points a name at another name, and lets the host change its IP addresses without you updating anything.

Type: CNAME
Name: www          (so www.yourapp.com)
Value: my-app-x7f2.someplatform.app

Rule of thumb: use whatever your host tells you to use. They know their own setup. If they give you a CNAME target, use a CNAME. If they give you an IP address, use an A record.

The apex domain problem

Here's the one bit of genuine DNS weirdness. The bare domain — yourapp.com, called the apex or root — traditionally can't have a CNAME record. www.yourapp.com can.

That's why hosts often give you different instructions for the two:

  • www.yourapp.com → a CNAME to the host.
  • yourapp.com → an A record to an IP, or a special record type some DNS providers offer (called ALIAS, ANAME, or "CNAME flattening") that acts like a CNAME on the apex.

Then pick one as the main address and redirect the other to it, so both work and search engines see a single canonical site.

Step by step

  1. Add the domain in your host's dashboard. It will show you the exact records to create.
  2. Open your DNS settings at the registrar (or at Cloudflare, if you moved DNS there).
  3. Remove conflicting records. Registrars often add a default "parking" A record for @ or www. Two A records for the same name will send some visitors to the parking page.
  4. Add the records exactly as your host specified.
  5. Add any verification record the host asks for — usually a TXT record proving you own the domain.
  6. Wait. Changes typically work within minutes, but can take up to a day or two to be seen everywhere, depending on cached values.
  7. Confirm HTTPS. Visit https://yourapp.com and check the padlock.

Where HTTPS comes from

Once DNS points at your host, the host requests a certificate for your domain — usually from Let's Encrypt, for free — proves to the certificate authority that it controls the domain, and installs it. Good hosts renew it automatically before it expires, and you never think about it again.

If a host asks you to buy, upload, or manually renew certificates for an ordinary web app today, that's a sign to consider a different host.

When it doesn't work

Symptom Likely cause
Site shows the registrar's parking page An old default A record is still there. Delete it.
Works on www but not the bare domain (or vice versa) You only added a record for one of them.
"Your connection is not private" warning DNS just switched and the certificate hasn't been issued yet — wait. Or a proxy (like Cloudflare's orange cloud) is interfering with issuance; check your host's guidance.
Works for you but not for others DNS caching. Wait, or check with a DNS lookup tool from another location.
"Too many redirects" Two layers both forcing HTTPS or redirecting between www and apex. Usually a Cloudflare SSL-mode setting.

You can check what the world sees with:

dig yourapp.com +short
dig www.yourapp.com +short

If those return your host's IP or target, DNS is right, and anything else is a host or certificate issue.

Keep the domain yours

A few habits that save pain later:

  • Register the domain in your own account, not a freelancer's or an agency's. If you're building for a client, the client should own it — more on that in How to Hand Off an AI-Built App to a Client.
  • Turn on auto-renew and keep a valid card on the account. Expired domains get snapped up.
  • Enable two-factor authentication at the registrar. Whoever controls your DNS controls where your users go.
  • Be cautious about buying the domain through your host. It's convenient, but it ties two decisions together. Owning it separately makes switching hosts a DNS change instead of a domain transfer.

The short version

Buy the domain in your own name. Add it in your host's dashboard. Copy the records they give you into your DNS settings, deleting any parking records. Wait. Check for the padlock. That's genuinely all it is.

EasySpawn routes a domain you own to your app and issues and renews the SSL certificate automatically — the domain stays registered in your name, wherever you bought it. See how it works for AI-built apps or join the waitlist.

Related: You Built an App With AI. Now What? · How to Hand Off an AI-Built App to a Client

Keep reading