Deploy a Bolt.new app to your own domain

Does your app still need Bolt once it's built?

Bolt Cloud hands a project a database as soon as the app looks like it needs one, and it also covers auth, file storage, server functions and Stripe payments. The frontend is a JavaScript bundle either way. The question is what that bundle calls when it loads.

Three checks, all inside Bolt, none of which spend tokens:

1. Click the database icon in the top centre of the screen. Look at Tables and at Server Functions. Empty means nothing of yours is running on a server.
2. Open Code View (the <> icon), click Terminal, and run npm run build. Running the build here costs nothing and tells you whether it compiles and which folder the output lands in - Bolt's web projects are Vite-shaped, so usually dist/. A build that fails here fails in CI too.
3. Search the code for import.meta.env. Every hit is a value that lives in Bolt's Secrets menu rather than in your files. Remember the count; it matters later.

If tables and server functions are both empty, you have a plain static build and it will run on anything that serves files. If there are tables, a logged-in user, or a Stripe flow, your frontend is still static but it calls Bolt Cloud at runtime - and moving the hosting does not get you off Bolt in that case. The backend stays where it is, still attached to your account. You'd be changing who serves the HTML, nothing more.

Route A: leave it on Bolt and point your domain at it

This is the least work, and for one site it's a defensible $25 a month. Publish the project first - the connect-a-domain option only shows up on a published site. Then the gear icon → All project settings → Domains & Hosting → Connect a domain you own → type the domain → Verify and add domain.

At your registrar you add (checked August 2026):

• www as a CNAME pointing to site-dns.bolt.host
• the root domain as an ALIAS, ANAME or flattened CNAME, also to site-dns.bolt.host
• a TXT record first, if you're attaching a subdomain like app.example.com rather than the root

Most domains go live within a few hours; Bolt allows up to 24. Worth knowing before you commit: the free hosting tier is 10 GB of bandwidth and 333,333 requests a month, and it's a hard limit - the site stops serving and stays down until the billing cycle resets. Any paid plan removes the "Made in Bolt" badge.

To see what a crawler actually gets, from either host:

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://yourdomain.com

If that returns an empty <div id="root"> and a script tag, that is what Google indexed.

Route B: getting the code out

Two doors.

The zip. Click the project title, top left, then Export > Download. Unzip it and npm install && npm run dev runs it locally. This is a snapshot - fine for a backup, useless as a workflow.

The repository. Click the GitHub icon in the top right, then Create a repository. It starts private on main. This is the one you want if you expect to keep editing in Bolt after the domain is live.

Bolt's sync is more assertive than most. It commits automatically every time you make a change that doesn't break the project, and it polls GitHub every 30 seconds for changes made elsewhere. On a collision the docs don't hedge: "Bolt keeps your changes and overwrites the GitHub version." Three consequences worth planning around:

• If your host builds on push, every accepted Bolt change is a production deploy. There is no "save then publish" gate on the repo side.
• Don't hand-edit the repo with the Bolt tab open. Bolt wins.
• Disconnecting a project from GitHub is permanent - the docs say you can't manually reconnect it, and transferring a project to another Bolt user strips the integration entirely.

One more sequencing rule, in case Netlify is where you're heading: a project has to be unpublished to switch its hosting provider, and once you've published to Bolt hosting, "There is no going back" - you need a fresh, unpublished copy. Decide before the first publish, not after.

What breaks the first time you build it somewhere else

The environment variables you counted earlier. They live in Bolt's Secrets menu, not in your repository. A CI build will happily succeed without them and ship a bundle full of undefined - which shows up as a white screen with console errors referencing a Supabase URL. That symptom is in Bolt's own troubleshooting docs, and it's the failure I see most often when someone's first deploy from a builder-exported repo goes green in CI and blank in the browser. Ask Bolt to list every variable the project expects, then add them wherever your build runs.

Deep links. A Bolt app is a single-page app with client-side routing. Clicking through to /pricing works because JavaScript handles it; typing /pricing into the address bar asks the host for a file that isn't there. On a WordPress host that miss is not a generic 404 - WordPress's own rewrite rules send any path with no matching file to index.php, so the visitor gets the WordPress 404 page instead of your app. Pre-rendering each route into a real HTML file is what stops that, and it fixes the crawler problem at the same time.

Anything genuinely server-side. Server functions and the database stay in Bolt Cloud, whatever you do with the frontend.

Putting the build on WordPress hosting

If you already pay for WordPress hosting for something else, that host is already serving files - every image in wp-content/uploads goes out without WordPress being involved. This is the gap Parkstatic sits in: a GitHub Action builds the repo Bolt syncs to, pre-renders each route to real HTML, and publishes the output to your existing WordPress site, keeping every deploy as a version you can roll back to. The workflow is one file:

name: Build and Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: ParkStatic/action@main
        with:
          parkstatic-secret: ${{ secrets.PARKSTATIC_SECRET }}
          prerender-routes: |
            /
            /about
            /pricing

Every path in prerender-routes becomes a real HTML file, which is what fixes the deep-link and crawler problems above. GitHub Actions is free on public repositories and includes 2,000 minutes a month on GitHub Free for private ones (checked August 2026); a Vite build spends one or two. The React and Vite guide covers the build side in more detail, and the Replit walkthrough is the closest sibling if you're comparing exit routes from a hosted builder.

When this is the wrong move

• You don't already pay for WordPress hosting

  Buying it to serve a Bolt build makes no sense. Bolt's own free tier handles roughly 10,000-15,000 visits a month by their estimate, and Cloudflare Pages will host a static build for nothing.

• Your app has accounts, a database or payments

  You'd still be on Bolt Cloud for the parts that matter, and you'd have added a deployment pipeline to save nothing. Keep it where it is.

• You want one bill and one interface

  Bolt Pro at $25 a month bundles the domain, badge removal and SEO Boost into the tool you're already in. That's $300 a year, more than the alternative below, but it's one place to look when something breaks - which is worth real money to some people.

• Your Bolt project is a Next.js app using the App Router

  That's a different problem - it isn't static until you configure it to be, and Bolt's own pre-renderer is currently not recommended there.

That last case has its own page now: the v0 and Next.js guide covers output: 'export', the features it breaks, and the trailingSlash setting an Apache host needs. The deploy hub has the other builders.

If your Bolt app is a plain frontend

If your traffic is ordinary and the WordPress bill already exists, the arithmetic is simple. The full argument for static hosting on WordPress is the long version; Parkstatic is $29.99 a year or $89.99 once, per WordPress site (checked August 2026), and one licence covers one site.