Getting your code out of Bolt.new is easy: download a zip or connect the project to GitHub. Getting your app out is a different question. What the move involves depends on where your data, logins and server logic live, and two Bolt apps that look identical can need very different migrations.
This guide covers what Bolt's download gives you, what varies from project to project, the three things to check first, and a step-by-step checklist.
What Bolt.new lets you export
Bolt describes its download as a zip of your project files. Its backups cover the project too, and restoring a backup doesn't change your database. In practice you can usually take:
- Your project files, through a zip download or GitHub
- A web project you can install and run on your own machine
- Row data, exported from the tables in Bolt Database
- Data in Supabase, if your project is already connected to your own Supabase account
What varies by project
The code is the easy part. These are the pieces that decide how big the move really is:
- Sign-in and user accounts managed in Bolt Cloud
- Files in Bolt Cloud storage buckets
- Server functions, which need rebuilding or redeploying for your new host
- Environment variables and build settings
The download gets you the files. If your app has logins or stored data, that code still needs a database, sign-in and functions to talk to, and Bolt's docs don't list a complete backend export.
Three things to check before you move
1. Bolt Database or your own Supabase?
If your project already uses your own Supabase account, the backend may be able to stay where it is while only the app moves. If it uses Bolt Database, Bolt's advanced settings document a way to claim the database in your own Supabase account on Pro and Teams plans.
2. Claiming and connecting are different
Claiming your Bolt Database moves it into your Supabase account. Connecting a different database replaces the connection and can lose access to the existing data. Make sure you know which one you're doing before you click anything.
3. Unpublished databases can pause
Bolt says a low-usage database in an unpublished project may pause automatically after six days or more. If your app isn't live yet, account for that before you plan the export.
A step-by-step Bolt.new exit checklist
- Find where everything lives. Identify the database, sign-in provider, storage, server functions and environment variables your project uses.
- Get the code into your own repository. Connect GitHub or download the zip, and confirm the project installs and builds on a clean machine.
- Decide the database route. Keep your existing Supabase, claim the Bolt Database on a Pro or Teams plan, or export the rows.
- Move users, files and functions. Set up sign-in, copy stored files and redeploy server functions for your host.
- Check the data. Compare row counts table by table and confirm access rules work at the destination.
- Test the core workflows on the new host before anyone relies on it.
- Schedule the switch. Plan the final data copy and the domain change, and keep the Bolt project until the new app has proved itself.
If you'd rather hand it over, every Bolt.new web app is a flat $199 with AppExit, code and database included, whatever its size. The Bolt.new migration guide shows how we handle each step.
Frequently asked
Can I just download the zip and host it?
For a simple site with no backend, possibly. If your app has logins or stored data, the downloaded code still needs a database, sign-in and functions to talk to, and those are the parts that need moving.
Does it matter whether I use Bolt Database or Supabase?
Yes. Your own Supabase account may be able to stay as it is. Bolt Database needs either claiming into your own Supabase account or a separate export.
Will my app keep the same access rules?
Only if they move with the database. If the data lands in Supabase, check its access rules with our guide to Supabase Row Level Security.
Sources
Vendor documentation checked November 2026. Plans and export paths can change. AppExit is not affiliated with Bolt.new.