How to Migrate Off Bolt (Step-by-Step)

Bolt is one of the fastest ways to turn a prompt into a working app, and the code it writes is real, standard code. That makes it one of the easier platforms to leave. It does not make leaving a one-click job.

Short version: the Export button gets you the code. A complete Bolt migration also moves the database, users, storage files, secrets and hosting that live on Bolt Cloud.

Step 1: Export your code

Bolt gives you two ways out:

• Export → Download bundles the project into a .zip file.
• Connect to GitHub in the toolbar pushes the project to a new repository with an initial commit.

We recommend GitHub, because you get a real history from that point on. Either way, run npm install and npm run dev locally to confirm it builds before you touch anything else.

Two things don’t travel with the code. Version History stays inside Bolt, so only commits you’ve pushed to GitHub come with you. And values in the Secrets panel are not exported at all.

Step 2: Inventory Bolt Cloud

Open your project’s Cloud settings and write down everything the app depends on:

Bolt Cloud service	What to record	What replaces it
Bolt Database	Every table, row count, security rules	Your Supabase or Postgres
Authentication	Sign-in methods, user count	Your auth provider
File storage	Buckets, total size	S3, R2 or Supabase Storage
Server functions	Each function and its trigger	Your API or edge functions
Secrets	Every key name and its provider	Your secret manager
Hosting & domain	*.bolt.host URL, custom domain	Your server or host

The secrets list matters most. Bolt’s secrets are write-only, so the list of key names is what tells you which providers to visit.

Step 3: Choose your target stack

Because Bolt apps are usually React with Vite, and often already talk to a Supabase-style backend, the lowest-effort target is your own Supabase project plus a host you control. If you want to leave managed backends entirely, the usual choice is PostgreSQL behind a small typed API on an EC2 instance or VPS with Nginx and Certbot.

Pick one option per row of the inventory table. Don’t change frameworks during the migration. That’s a separate project.

Step 4: Move the database

You have two options:

1. Claim the database. From the Advanced settings, Bolt can transfer the database into your own Supabase organization, where it becomes an ordinary Supabase project you administer. You’ll need to be an owner of that Supabase organization.
2. Export tables. Export each table as CSV or JSON and load it into your target database, recreating keys, indexes and security policies.

Bolt’s public docs don’t fully document how the claim handles auth users and password hashes or storage bucket files. Confirm both in a test run before you schedule the cutover. If password hashes don’t come across, plan a password-reset or magic-link email for your users.

Step 5: Re-issue secrets and move files

For every key on your list, sign in to the provider, create a new key, and store it in your secret manager or your host’s environment settings. Rotating is better than copying: an old key that was pasted into a builder is a key you no longer fully control.

Then copy every file out of Bolt storage into your own bucket and rewrite the URLs saved in your database.

Step 6: Deploy and test

Set up a pipeline so a push to main builds and deploys the app. A typical setup is GitHub Actions or CircleCI deploying static files and an API to a server running Nginx with Certbot SSL. Test on a staging domain with real accounts: sign-up, sign-in, password reset, file upload and payments.

Step 7: Cut over

1. Announce a short maintenance window.
2. Freeze writes on the Bolt app.
3. Run a final data sync and compare row counts table by table.
4. Point your domain at the new stack.
5. Verify with real accounts, then keep the Bolt project read-only for a couple of weeks as a fallback.

After that, your app runs on infrastructure you pay for directly, and you can keep building with whichever AI coding tool you like.

Want it done for you?

This is the process X & Company runs on every Bolt migration: a fixed-scope audit, a tested move, and a cutover with a rollback plan.