How to Point a Bolt.new Custom Domain to Your Live Site

AI-generated

Picture this: you click publish, the shared Bolt.new URL loads, and for about thirty seconds everything feels finished. Then you open a new tab, type in the domain you bought eight months ago, and nothing happens. That gap between a working prototype and a working bolt.new custom domain is where most builders lose a weekend, not because the steps are hard individually, but because they try to do them in the wrong order.

A prototype on a shared Bolt.new link proves the idea works. A site on your own domain, with SSL intact and no broken API calls, proves you're running a business. Those are two different problems, and treating them as one sequential handoff instead of two separate chores is the entire difference between a launch that works and one that breaks at the DNS step, the SSL step, or the moment your database URL goes missing in production.

Why hosting and DNS are not two separate decisions

Most guides split "deploy your app" and "connect your domain" into two chapters. That split is where things go wrong.

Your hosting choice determines what kind of DNS record you need, whether SSL is automatic or manual, and how environment variables get injected at runtime. Decide where you're hosting first, and the DNS configuration follows directly from that answer. Decide DNS first, and you'll likely point your domain at the wrong target, then redo it once you pick a host.

Think of it as a decision tree, not a checklist: hosting platform chosen → record type determined → SSL method follows automatically → environment variables migrate as part of the same deploy, not an afterthought. Skip a branch and the next one breaks in a way that looks unrelated. A CORS error three days after launch is often a DNS decision made in isolation a week earlier.

AI-generated

Your three realistic paths from Bolt to production

Builders coming out of Bolt.new generally take one of three roads, and each one fits a different kind of project.

Managed deployment platforms (Vercel-style hosts, or Bolt-native hosting partners) are the fastest path. You connect your project, the platform builds and serves it, and SSL is handled for you. Deployment on these platforms typically completes in seconds rather than hours Kuberns. This path suits solo founders and indie hackers who want the app live today and don't want to manage servers.

GitHub plus a container registry suits builders with a backend that needs more control than a managed platform offers, or that other engineers will need to touch later. You push to a repo, a CI pipeline builds an image, and a container host runs it. It takes longer to set up, usually an afternoon rather than minutes, but gives you portability if you ever switch hosts.

Manual export is the slowest and most flexible path: you download the Bolt project, bring it to a server or provider you already manage, and configure everything by hand. This fits builders with existing infrastructure or specific compliance needs. It's also the path if you decide the Bolt output needs to live inside a broader system rather than stand alone, since you can bring or port a site built in Lovable, Bolt, or plain React into that system Tyashin. If your prototype needs to become an actual indexable, sales-ready site with a blog and SEO running in the background, that's worth reading before you lock in a hosting choice: why prototypes fail without an OS behind it.

Pick based on who maintains this after launch. If it's just you, take the managed path. If a team inherits it, the container path. If it's becoming part of something bigger than one app, the export path.

How to point your domain at your live site without losing SSL

Once hosting is decided, DNS is almost mechanical. On most platforms, you go into project settings, click something like "Add custom domain," paste in your domain, and update a single DNS record at your registrar. This works the same way across Cloudflare, Namecheap, and GoDaddy, all of which support custom domain configuration from their standard DNS settings Livemy.

The record that matters is usually one of two types: an A record pointing to an IP address, or a CNAME pointing to a hostname the platform gives you. Your host's dashboard will tell you which one to use, and it will usually show a verification status once the record propagates.

Three things to watch:

• Don't delete existing MX records when you edit DNS. Changing the wrong row breaks email, not the site.
• Propagation can take anywhere from a few minutes to 48 hours depending on your registrar's TTL settings. Don't panic and re-edit the record every ten minutes; that resets the clock.
• SSL certificates on managed platforms are usually issued automatically once DNS verifies. If your certificate shows "pending" for more than an hour after DNS resolves, check that you didn't leave an old A record alongside the new one. Two conflicting records is the single most common cause of a stuck certificate.

Environment variables, secrets, and why they break at launch

Environment variables are the API keys, database connection strings, and third-party secrets your app needs to run but that should never be visible in your code. Bolt.new stores these inside your project's environment during development, which is convenient until you move to a different host that has no idea those values exist.

This is where launches quietly fail. The frontend loads fine because it's static. The database calls fail because the production environment is missing a connection string that only ever lived inside the Bolt workspace. The symptom looks like a broken feature; the cause is a variable that never made the trip.

Before you send anyone the live link, confirm:

• Every variable from your Bolt project has a matching entry in your production host's environment settings, not hardcoded into a file.
• Database connection strings point to a production database, not the development one Bolt spun up for testing.
• API keys for third-party services (payments, email, auth) are production keys, not test keys left over from the demo.
• CORS settings on your API allow requests from your new domain, not just the old Bolt shared URL.
• A test transaction or form submission completes end to end on the live domain, not just in the Bolt preview.

Run through each of these once you believe you're live. It takes ten minutes and catches most of what would otherwise surface as a support ticket from your first real visitor.

Your pre-launch checklist: what to verify before traffic arrives

Five things fail more often than everything else combined, and all five are checkable without touching production code:

1. SSL certificate: load the domain in an incognito window and confirm the padlock shows, not just that the page loads.
2. DNS propagation: use any public DNS lookup tool to confirm your domain resolves to the new host's address from outside your own network, not just your machine.
3. Environment variables: trigger one action that depends on each secret (a login, a database read, a payment test) and watch for errors in the host's logs, not just the browser.
4. Database connection: confirm the production app is writing to and reading from the production database, not a cached or development instance.
5. CORS: open the browser console on the live domain and check for blocked cross-origin requests before you call it done.

Once those five pass, the technical side of launch is finished. What happens after that, whether Google can actually find and index the site, whether the page structure supports search traffic, is a separate pass worth running before you promote the link anywhere: a technical SEO audit for a Bolt site covers that step. And if the goal was never just "get it live" but "get it selling," the gap between a working domain and a working sales page is worth closing next: turning your prototype into a sales-ready website.

Start with your hosting choice above, then follow the DNS and environment steps for your provider, and run the pre-launch checklist before you tell anyone the site is live.