Guides / Prompting and shipping
How to Connect a Custom Domain to Your App or Website
How to connect your own domain to an app or website: buying it, which DNS records to add, HTTPS, www vs root domain, and fixing common errors.
Mythex Team · · 6 min read
To connect a custom domain, you buy the domain from a registrar, add a DNS record that points it at your host — usually a CNAME record for a subdomain like www or app, or an A record (or ALIAS/flattened record) for the root domain — and then let your host verify the domain and issue an HTTPS certificate. It typically takes minutes, sometimes longer. Most problems come from a typo in the record, the wrong record type, or a proxy sitting in front of the host.
This guide covers each step, the www-versus-root decision, and how to troubleshoot. For the concepts behind domains, see how domains and DNS work.
The pieces involved
| Piece | What it is | Who provides it |
|---|---|---|
| Domain name | The name you rent yearly, like example.com | A registrar |
| DNS | The public lookup that turns names into server addresses | Your DNS provider (often the registrar) |
| Records | Individual DNS entries: "www points to…" | You add them |
| Host | The service that runs your app | Your hosting or app builder |
| Certificate | What makes https:// work | Usually issued automatically by the host |
The registrar and DNS provider are often the same company, but they don't have to be. What matters is: where do you edit DNS for this domain? That's where you'll add records.
Step 1: Buy a domain
Tips for choosing and buying:
- Keep it short and easy to spell out loud. If you have to explain the spelling, pick another.
.comis the default people guess, but country and newer endings (.io,.app,.co.uk) are fine if they fit your audience.- Check the renewal price, not just the first-year price. Introductory discounts are common and renewals can cost more.
- Turn on auto-renew and keep the payment card current. An expired domain takes your site and your email down, and can be bought by someone else after a grace period.
- Use WHOIS privacy if offered, so your personal details aren't published.
- Buy it in an account you control, not a freelancer's or agency's.
Some hosts and app builders let you buy the domain directly inside the product, which also sets up DNS for you.
Step 2: Decide on the address
Subdomain vs root domain
- Root (apex) domain:
example.com - Subdomain:
www.example.com,app.example.com
A common setup is a marketing site at example.com or www.example.com and the product at app.example.com. For a single site, choose between www and the root.
www.example.com | example.com | |
|---|---|---|
| Record type | CNAME to your host | A/AAAA record, or ALIAS/ANAME/flattened CNAME |
| Setup difficulty | Easy everywhere | Depends on your DNS provider |
| Looks | Slightly longer | Shorter |
The DNS standard doesn't allow a CNAME record at the root of a domain, because the root must hold other records (such as the nameserver records). Many DNS providers work around this with a special record type — called ALIAS, ANAME or CNAME flattening depending on the provider — that behaves like a CNAME at the root. If yours doesn't, the reliable approach is: serve the site on www, and set up a redirect from the root to www at your DNS provider or registrar.
Whatever you choose, pick one main address and redirect the other to it. Having both serve the same content without a redirect is confusing for users and search engines. See SEO for AI-built websites for why a single canonical address matters.
Step 3: Add the DNS records
Your host tells you exactly what to add. It will look like one of these:
| Type | Name / Host | Value / Target | Used for |
|---|---|---|---|
CNAME | www | yoursite.hostname.com | Pointing a subdomain at a hostname |
A | @ | 192.0.2.10 | Pointing the root at an IPv4 address |
AAAA | @ | 2001:db8::10 | Pointing the root at an IPv6 address |
TXT | _verify or @ | a code string | Proving you own the domain |
How to fill in the form at most DNS providers:
- Name / Host: just the subdomain part —
www, notwww.example.com. Some providers add the domain automatically, and typing it in full createswww.example.com.example.com. Use@for the root if your provider uses that convention. - Value / Target: paste exactly what the host shows. A trailing dot is fine if your provider adds one.
- TTL: the default is fine. A lower TTL (such as 5 minutes) makes future changes take effect faster.
- Proxy: if your DNS provider can proxy traffic (Cloudflare's orange cloud, for example), follow your host's instructions. Many hosts need "DNS only" so they can issue the certificate.
Leave existing records alone unless the host tells you to change them. In particular, don't touch MX records — those deliver your email. Deleting or changing them is the most common way a domain change breaks email.
Changing nameservers vs adding records
Some hosts offer two options: add a record, or move your whole domain's DNS to them by changing nameservers at the registrar. Changing nameservers moves every record, including email. Only do it if you're ready to recreate all existing records at the new provider. Adding a single record is lower risk.
Step 4: Verify and get HTTPS
After the record is in place, go back to your host and click its verify button. The host checks DNS, then requests a certificate — typically from a free certificate authority such as Let's Encrypt — and starts serving your site over HTTPS.
- Verification may take a few tries while DNS changes spread.
- Certificates renew automatically as long as the DNS record stays in place.
- If your domain has CAA records (which limit which certificate authorities may issue for it), make sure they allow your host's authority, or certificate issuance fails.
Once HTTPS works, make sure http:// redirects to https://. Most hosts do this automatically.
Step 5: Test it
-
https://www.example.comloads your site with a padlock icon - The other form (root or
www) redirects to your main address -
http://redirects tohttps:// - Login, OAuth sign-in and payment redirects work on the new domain (they often have allowed-URL lists that still point at the old address)
- Email to your domain still arrives
- Links in emails your app sends use the new domain
The fourth item catches people out: Google sign-in, Stripe webhooks and password-reset links are all configured with specific URLs. Add the new domain wherever your old address appears. See how to add login to your app for the OAuth side.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Verification keeps failing | Typo in the target, wrong record type, or name entered as the full domain | Compare the record character by character with what the host shows |
| Worked for you, not for others (or the reverse) | DNS caching during a change | Wait out the TTL; test from a phone on mobile data |
| Certificate or "not secure" error | Certificate not issued yet, proxy in front, or CAA records blocking | Wait a few minutes and re-verify; set proxy to DNS only; check CAA |
| "Too many redirects" | Two layers both redirecting (e.g. proxy forcing HTTPS and host doing the same) | Turn off one of the redirects, or use "DNS only" |
Root domain doesn't work, www does | No record or redirect for the root | Add ALIAS/flattened record, or redirect root to www |
| Email stopped working | MX records changed or lost when moving nameservers | Restore MX records from your email provider's instructions |
| Old site still shows | Old A record still present alongside the new one | Remove conflicting records for the same name |
A free online DNS lookup tool, or dig www.example.com in a terminal, shows what the world currently sees for your record — useful for checking whether the problem is DNS or the host.
Connecting a custom domain on Mythex
Custom domains are a Pro feature on Mythex. Free plans publish to a yourname.mythex.app address. On Pro you can:
- Buy a domain inside Mythex from Domains in settings, or from Publish → Custom domain on a live project. Mythex registers it and sets up DNS; registration is billed separately from the Pro plan, and auto-renew is on by default.
- Connect a domain you already own. Publish the project, choose Connect, enter the hostname (for example
app.example.com), then add a CNAME at your DNS provider pointing to the target Mythex shows (yourslug.mythex.ai). Click Verify. HTTPS is issued automatically.
If your DNS is on Cloudflare, set that CNAME to DNS only (grey cloud), not proxied. For a root domain, the docs recommend using www or app and redirecting the root at your DNS provider if it doesn't support ALIAS or flattening.
See Custom domains in the docs for the full steps and troubleshooting, and Plans for what's included in Pro. Before pointing a domain at an app, it's worth running through taking an AI prototype to production.
Questions
How long does it take for a custom domain to work?
Often a few minutes after you add the DNS record, but it can take longer depending on your DNS provider and the record's TTL (how long resolvers cache it). If you changed nameservers, allow more time.
Should I use www or the root domain?
Either works for visitors. A subdomain like www or app is usually easier to connect because it can use a CNAME record. Many sites serve www and redirect the root domain to it, or the other way round — just pick one as the main address.
Do I need to buy an SSL certificate?
Usually not. Most modern hosts, including app builders, issue free HTTPS certificates automatically once your DNS points to them. You only need to buy one for special cases such as some organisation-validated certificates.
Why can't I add a CNAME record for my root domain?
DNS rules don't allow a CNAME at the root (apex) of a domain because other required records live there. Some DNS providers offer ALIAS, ANAME or CNAME flattening to get the same effect; otherwise use www and redirect the root domain.