How to export my Bolt.new project and host it elsewhere

To move your app off Bolt.new, get the code with Download or GitHub, move the database into your own Supabase account with Claim, recreate the secrets and deploy to a server you control. Then move the domain. Bolt confirms the code is yours; the real work is in the database and settings that live on the platform.

Heartscale’s recommendation: move the Bolt Database with Claim, never with the Connect button, and delete the Bolt project only after you check the data in your new account. If the app has real users, sign-in or server functions, get the database access rules reviewed before you switch the domain.

Before you start: what is yours and what stays on Bolt

Bolt’s help center says all code you create with Bolt and StackBlitz is your own, including for commercial use (Corporate and commercial). The code leaves in full. Everything else depends on where the project keeps it:

Part	Where it lives	How it leaves
Code	The Bolt project	Download (.zip) or GitHub
Database	Bolt Database (Bolt Cloud) or a connected Supabase	Claim into Supabase, or export tables
Secrets	The database’s Secrets tab	Recreated by hand
Published site	bolt.host or Netlify	A new deploy on your server
Domain	Your registrar, or bought through Bolt	DNS change or transfer

First, find out which database the project uses. Click the database icon at the top center of the screen. Bolt Cloud creates a database on its own when a project needs one (Bolt Cloud). If the project was connected to your own Supabase, the database already sits in your account and the move gets much smaller.

Step 1: get the code

The official docs offer two routes.

Download the .zip (Manage your projects):

1. Open the project in Bolt.
2. Click the project title in the top left, then click Download.
3. Unzip the file.
4. With Node.js installed, run this in the project folder:

npm install && npm run dev

GitHub (GitHub for version control):

1. In the project, click the GitHub icon in the top right and then Log in to GitHub.
2. Click Authorize and Install the GitHub App. Pick All repositories or Only select repositories and confirm with Install & Authorize.
3. Click the GitHub icon again, name the repository and click Create repository.

The repository starts private, on the main branch. Bolt syncs both ways: it commits each change that does not break the project and pulls GitHub updates every 30 seconds. Only the project owner can connect and manage the integration.

Prefer GitHub. It keeps history and lets your new server deploy on every push. Two warnings from the docs: if Bolt and GitHub change at nearly the same moment, Bolt overwrites the GitHub version. And disconnecting a project from GitHub is permanent; reconnecting the same repository takes a support request.

Step 2: move the database

The route depends on the database.

If the project uses the Bolt Database

The database page says there is currently no supported way to migrate an existing Bolt Database to Supabase (Database). The Connect button replaces the connection and may cause data loss (Advanced database settings).

The route Bolt points to for keeping your data is Claim, which moves the database into your Supabase account (Supabase for databases):

1. Make sure Bolt is connected to your Supabase account.
2. Open the project and click the database icon at the top center.
3. Open the Advanced tab and click Claim.
4. Finish the remaining steps in Supabase.

The database then shows up as a project on the Supabase Projects page. Claim requires a Pro or Teams plan on Bolt, and you must be an owner of the Supabase organization.

Without Claim, you can export data table by table (Database tables): database icon, open the table, tick the header checkbox to select all rows, click Export and pick CSV or JSON. That carries the rows but not the full database structure. Use Claim whenever your plan allows it.

If the project already uses your own Supabase

The database is already in your account and stays there. When you delete a project, Bolt does not delete external resources such as a Supabase database (Manage your projects). You only need to point the new app at it.

After Claim

The database is now yours to maintain and protect. Review the table access rules before you open the app to the public. Our guide to Supabase RLS shows how to check them. In our reviews, we open every table that came over with Claim, check that RLS is on and see what each policy lets an anonymous visitor and a signed-in user read and write.

Step 3: recreate secrets and variables

Bolt secrets live under database icon → Secrets, and server functions read them (Database secrets settings). The docs say never to store them in plain text in your code. Write down each secret’s name and recreate the values on the new server.

If the app is built with Vite, one Vite rule matters: variables prefixed with VITE_ end up in browser code at build time and should not hold secret keys (Env Variables and Modes). Changed one? Build again. Find where the app reads the database URL and key, and check they point to the right Supabase project.

Step 4: build and host

Open package.json and read the scripts. In a Vite project, npm run build writes the output to dist/ (Deploying a Static Site). vite preview is for local testing, not production.

npm ci
npm run build
# output in dist/

On a VPS with Nginx, copy dist/ and send every route to index.html:

location / {
  try_files $uri $uri/ /index.html;
}

Then add HTTPS. If you prefer a dashboard, Coolify installs on a Linux VPS with at least 2 CPU cores and 2 GB of RAM and deploys from GitHub.

If the app has server-side logic, it needs somewhere to run. After Claim, check in Supabase that your server functions are there: Bolt’s docs do not detail what Claim carries beyond the database. One note from Bolt’s Netlify page: that integration hosts browser-only sites, with no database or backend (Netlify for hosting).

Step 5: test before you switch

Run the new app on a temporary address and check:

• Open an inner route directly by URL and reload. A 404 means the index.html fallback is missing.
• Sign in and out. A redirect error usually means the new URL is missing from the auth redirect list in Supabase.
• Read, write and upload a file.
• Call each server function and confirm it finds its secrets.

Step 6: move the domain

Domain from another registrar. On Bolt, it points to site-dns.bolt.host (Connect your domain). To release it: gear icon → All project settings → Domains & Hosting, the three dots on the domain row → Remove domain. Then update the records at your DNS provider to point at the new server.

Domain bought through Bolt. Transfers to another registrar open 60 days after purchase. During that lock, Bolt lets you move the domain into a Name.com account you own (Purchase a domain). Auto-renewal lives under Settings → Cloud.

Step 7: wrap up on Bolt

1. To take the bolt.host site down, disconnect your custom domain and use Publish → Unpublish (Publish your project).
2. Do not delete the project before you check the new database. Deleting permanently removes the files, chat history and Bolt Database, and it cannot be undone (Manage your projects).
3. Do not treat a duplicate as a database backup: when you duplicate a project, the Bolt Database copies its structure but not its data.

How long it takes

A site with no database is the simple case: steps 1, 4, 5 and 6. With a Bolt Database, Claim sets the pace. With sign-in, files and server functions, step 5 needs more care. The same logic applies to other platforms, as our guide on how to leave Lovable shows. See also our platform migration service.

Do it yourself or hire help?

This guide is enough when the app is simple; the table shows when it pays to have a team alongside you.

Situation	Path
A site with no database, or a database already in your own Supabase, and someone on the team who can run npm run build	Do it yourself with this guide
A Bolt Database with real users’ data	Bring in a team to run the Claim and check the data before you delete the project
Sign-in, payments or personal data in the app	Request a Heartscale diagnostic before you switch: database, secrets, server functions and access rules
A tight deadline, or no one technical on the team	Hire the migration at a fixed price

Request a Heartscale diagnostic

Our team maps what your app uses from Bolt: database, secrets, server functions and domain. We review the access rules of the database moving into your account and deliver a migration plan with a fixed price.

The launch-price diagnostic costs US$ 19 (was US$ 79) and is credited toward the migration if you go ahead. We only work on apps whose owners can prove they own them.

Request the diagnostic