Skip to main content
Stackbastion

Draft, not yet published

Bolt.new custom domain setup: DNS, SSL, and the gotchas

7 July 2026· 6 min read · by Stackbastion

You built something in Bolt.new, it works, and now you want it on yourdomain.com instead of a long .bolt.host URL. You add the domain, wait, and the browser shows a certificate warning or an endless spinner. Nothing in the dashboard tells you what’s wrong.

This is the most common snag people hit right after their first real deploy. The app is fine. The DNS is the problem. Here’s what’s actually happening and how to fix it in one sitting.

Why this happens on Bolt.new

Bolt.new deploys your app to a hosting layer (usually Netlify under the hood for the static and edge parts). When you attach a custom domain, two separate things have to line up, and they fail independently.

First, DNS. Your domain’s records have to point at the host. If you set the wrong record type, or you point the root domain (yourdomain.com) with a CNAME where the registrar won’t allow it, the domain resolves to nothing or to your registrar’s parking page.

Second, SSL. The certificate is issued automatically, but only after the host can prove you control the domain. It does that by reading your DNS. If DNS isn’t fully propagated, or a stale record is still cached, the certificate never issues and you get the warning. People assume the cert is broken when really it’s waiting on DNS that isn’t done yet.

The third trap is time. DNS changes aren’t instant. Your registrar might show the new record immediately, but resolvers around the world can hold the old answer for as long as the previous record’s TTL. If the old TTL was 24 hours, you could be waiting a while and refreshing a page that will never load until the cache expires.

How to fix it

Work through these in order. Don’t skip to SSL before DNS resolves, because SSL depends on it.

Step 1: decide root vs subdomain

Using app.yourdomain.com (a subdomain) is easier than the bare root, because subdomains take a CNAME cleanly. If you want the bare root (yourdomain.com), you need a registrar that supports CNAME flattening or ALIAS/ANAME records, or you use the host’s provided A record.

Step 2: set the DNS records

For a subdomain, add a CNAME at your registrar pointing to the host target Bolt gives you:

Type:   CNAME
Name:   app
Value:  your-app.bolt.host   (use the exact target from your Bolt/Netlify dashboard)
TTL:    3600

For the bare root domain, use the host’s A record (or an ALIAS if your registrar supports it):

Type:   A
Name:   @
Value:  75.2.60.5   (use the exact IP your host shows, not this placeholder)
TTL:    3600

Lower the TTL to 300 (5 minutes) before you make changes if you think you’ll be iterating. That shortens how long a mistake stays cached.

Step 3: verify DNS actually resolves

Don’t trust the browser here. Query DNS directly from your terminal:

# Check the record you just set
dig app.yourdomain.com CNAME +short

# Check what the world sees, using a public resolver
dig @1.1.1.1 app.yourdomain.com +short

If dig returns the host target, DNS is done. If it returns nothing or an old value, you’re still waiting on propagation or you set the record on the wrong domain. Wait, then re-check. Don’t touch SSL yet.

Step 4: let SSL issue, then confirm it

Once DNS resolves, the host issues a Let’s Encrypt certificate automatically, usually within a few minutes. Confirm it worked:

# Check the cert is live and matches your domain
curl -vI https://app.yourdomain.com 2>&1 | grep -Ei "subject:|issuer:|HTTP/"

You want to see an issuer from Let’s Encrypt and an HTTP/2 200. If you get a certificate mismatch, the cert issued for the wrong name, usually because you have both a root and subdomain record and only one was validated. Remove the record you’re not using and let it re-issue.

Step 5: force HTTPS and fix mixed content

After the cert is live, make sure every request goes to HTTPS. Most hosts have a “force HTTPS” toggle. Turn it on. Then load the site and open your browser console. If you see “mixed content” warnings, some asset is still loading over http://. Search your code for hardcoded http:// URLs and make them protocol-relative or https://.

Common gotchas checklist

  • Root domain won’t take a CNAME. Use A/ALIAS instead, or move to a subdomain.
  • Old TTL still cached. You changed the record but the browser sees the old one. Wait out the previous TTL or test from a different network.
  • Registrar added a trailing dot or extra domain. Some registrars append your domain to the CNAME value automatically. If the target shows as your-app.bolt.host.yourdomain.com, delete the domain suffix from the value field.
  • DNSSEC mismatch after moving nameservers. If you switched nameservers recently and enabled DNSSEC, resolvers may reject answers. Disable DNSSEC, confirm resolution, then re-enable.
  • www and root not both configured. Decide which is canonical, point the other at it with a redirect, so both work.

Or, we do it for you

Custom domains and certificates are the easy part until they aren’t, and a broken cert on launch day is a bad look. 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 check DNS, SSL, and the rest before your users do.

FAQ

How long does DNS propagation actually take?

Usually 5 to 30 minutes for a fresh record, but it can take up to 48 hours if the old record had a long TTL and is still cached. Lowering the TTL to 300 before making changes cuts the worst-case wait dramatically. Check with dig instead of your browser, since the browser caches aggressively.

Why does my SSL certificate keep failing to issue?

Almost always because DNS isn’t fully resolving yet. The certificate authority validates domain control by reading your DNS, so if the record is wrong, missing, or still propagating, validation fails and no cert issues. Confirm dig returns the right target first, then give it a few minutes.

Can I use my bare root domain instead of a subdomain?

Yes, but it’s more work. The root domain can’t take a standard CNAME under DNS rules, so you need an A record pointing at the host’s IP, or an ALIAS/ANAME record if your registrar supports it. A subdomain like app.yourdomain.com avoids all of this and is the simpler path if you don’t have a strong reason for the bare root.

The domain works but shows “not secure” in the address bar. What’s wrong?

The certificate hasn’t issued or your site is serving assets over plain HTTP. Confirm the cert with curl -vI first. If the cert is fine, open the browser console and look for mixed-content warnings, then fix any hardcoded http:// links in your code so every request is HTTPS.

Related posts