Custom domain and SSL for a vibe-coded app: the parts that trip people up

Your app is live on some something.platform.app URL and you want it on your own domain with a padlock in the address bar. You bought the domain, you added a record, and now you’re staring at a “not secure” warning or a page that won’t load at all. The concepts are simple. The details are where people lose an afternoon. Here’s the walkthrough and the specific traps.

Why this happens

Getting a custom domain working is really two separate jobs that people blur together: DNS (pointing your domain at the right server) and SSL (getting the HTTPS certificate). Each has its own failure modes, and a problem in one looks a lot like a problem in the other.

The confusion is worse for AI-built apps because the hosting is often abstracted away. You didn’t set up the server, so you’re not sure what the DNS record should even point to. The platform gives you an instruction like “add a CNAME,” you add it, and then you wait, and nothing seems to happen. Or it half-works: the domain loads but the certificate is for the wrong name, so the browser throws a warning.

Three things cause most of the pain:

DNS propagation isn’t instant. You add a record and expect it live immediately. It can take minutes to hours to spread, and your browser or network may cache the old answer, so you’re testing against stale data and thinking it’s broken.

The wrong record type. A root domain (example.com) and a subdomain (www.example.com) often need different record types. Mixing them up is the single most common mistake.

SSL can’t issue until DNS is right. Certificates are issued by proving you control the domain, which means DNS has to resolve correctly first. If the certificate won’t provision, the root cause is usually a DNS problem upstream, not an SSL problem.

How to fix it

Do these in order. Don’t touch SSL until DNS is confirmed.

Step 1: pick the right record for root vs subdomain.

• Subdomain (app.example.com or www.example.com): use a CNAME pointing to the target your host gave you.
• Root / apex (example.com with no prefix): a plain CNAME isn’t allowed here by the DNS spec. Use an A record pointing to the server’s IP, or your provider’s “ALIAS” / “ANAME” / “CNAME flattening” feature if they offer one.

A typical setup for both the root and www:

Type    Name    Value
A       @       203.0.113.10
CNAME   www     yourapp.hosting-target.example

The @ means the root domain. Replace the IP and target with what your host actually gave you.

Step 2: confirm DNS actually resolves before doing anything else.

Don’t trust the browser, it caches. Query DNS directly:

dig +short example.com
dig +short www.example.com

You want the first to return your server’s IP and the second to return the CNAME target. If they return nothing or an old value, wait and try again. You can also check what the wider internet sees, not just your machine, with a public resolver:

dig +short example.com @1.1.1.1

Only move on once these return the right answers. Chasing an SSL error while DNS is still wrong is the classic time sink.

Step 3: let SSL provision.

If you control the server, a reverse proxy like Caddy gets you a valid certificate automatically once DNS resolves. The entire config for HTTPS is:

example.com, www.example.com {
	reverse_proxy localhost:3000
}

Caddy requests the certificate from Let’s Encrypt, proves domain control, installs it, and renews it before it expires. No manual certificate handling. If you’re on a managed platform instead, this step is usually a button, but it still won’t succeed until step 2 passes.

Step 4: verify the certificate is for the right name.

A common half-broken state: the site loads over HTTPS but the certificate is for the platform’s domain, not yours, so the browser warns. Check what’s actually being served:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
	| openssl x509 -noout -subject -dates

The subject should show your domain and the dates should be current. If it shows a different name, the host hasn’t finished issuing your certificate yet, or the domain is pointing at the wrong place.

Step 5: redirect http to https and www to root (or vice versa).

Pick one canonical version and send everything to it, so you don’t split traffic or confuse search engines. With Caddy, redirecting www to the root is a couple of lines:

www.example.com {
	redir https://example.com{uri}
}

That’s it. DNS right, certificate valid, one canonical URL, http bumped to https.

Or, we do it for you

If DNS records and certificate errors aren’t how you want to spend your week, this is routine work we handle as part of setting up a real host. If you want a second pair of eyes on your setup regardless of what you built it with, get a free production audit and we’ll flag anything wrong with your domain and SSL.

FAQ

Why can’t I use a CNAME on my root domain?

The DNS spec doesn’t allow a CNAME on the apex (the bare example.com) because the root needs other records to coexist. Use an A record pointing to the IP, or your DNS provider’s flattening feature (sometimes called ALIAS or ANAME) which fakes CNAME behavior at the root safely.

I added the record but nothing changed. Is it broken?

Probably not, DNS just takes time to propagate and your local cache may be showing the old answer. Check with dig against a public resolver like @1.1.1.1 rather than trusting the browser. If it’s still wrong after a few hours, then look for a typo in the record.

My site loads but says “not secure.” What’s wrong?

The certificate hasn’t provisioned for your domain yet, or it’s serving a certificate for the wrong name. SSL can’t issue until DNS resolves correctly, so confirm DNS first, then give the certificate a few minutes to be issued. Check the served certificate’s subject with openssl to see what name it’s actually for.

Should I use www or the root domain as my main URL?

Either works, just pick one and redirect the other to it. Consistency matters more than the choice. Serving your app on both without a redirect splits your traffic and can muddy your SEO.