Export code from Bolt: what you get, what stays behind and how to run it

Exporting from Bolt is easy. Running the export somewhere else is the part that catches people out, because a Bolt app is more than its files. Bolt Cloud also holds your database, users, file storage, secrets and deployed server functions, and none of those are in the zip. This page covers the download route. Bolt's two-way GitHub sync is covered in taking a Bolt app to production, so I won't repeat it here.

Symptom

Signs the export route is giving you trouble:

• A teammate can't work out where the backend lives, because it isn't in the zip.
• There's no Open in StackBlitz option for your project.
• In the database Advanced tab, you can't use Claim or Connect. Both need a Pro or Teams plan, and on team accounts only the project owner, co-owners and team Admins can use them.

There is no single error message for a half-finished export. It shows up as a working front end with a missing backend:

Why it happens

Secrets never leave Bolt. Bolt reads a secret only when a server function needs it, and never writes the value into your project files, browser code or published site. That is good security and means your export has no keys.

The environment variables point at Bolt. If you have a database, the app connects to it through environment variables holding the database's web address and public key. Bolt's docs name these in the Supabase style, VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY. If those values are in your download, the exported app still uses the Bolt database.

Server functions run on Bolt, not in the zip. You get their source code, but they're deployed against your Bolt database. Running the front end elsewhere doesn't move them.

Data, users and files aren't code. Row data has its own export on the Tables page. Bolt's file storage docs say you can see buckets but not yet view or manage individual files.

StackBlitz export is fading out. Bolt's release notes say Open in StackBlitz is no longer available for new projects or those moved to its new code storage format.

The fix

1. Download and run it

1. Open the project in Bolt on a desktop browser.
2. Click the project title at the top left, then Download.
3. Unzip it, install Node.js if you haven't, and run:

cd my-bolt-app
npm install && npm run dev

If the build fails locally but works in Bolt, run npm run build in Bolt's own terminal (Code view, then the Terminal tab in the bottom panel) to see the same errors there. Running commands there doesn't use tokens.

2. Make an inventory of what the code expects

These commands list every variable the browser code reads, the server function files, and the secrets those functions expect:

# Browser-side environment variables (Vite exposes import.meta.env)
grep -rhoE "import\.meta\.env\.[A-Z0-9_]+" src | sort -u
 
# Server function source files (Supabase edge functions run on Deno)
grep -rlE "Deno\.serve|Deno\.env\.get" . --include=*.ts | grep -v node_modules
 
# Secrets the server functions read
grep -rhoE "Deno\.env\.get\([\"'][A-Z0-9_]+[\"']\)" . --include=*.ts | sort -u

Write the results into a .env.example so the next developer knows what to fill in, without real values:

# .env.example
VITE_SUPABASE_URL=
VITE_SUPABASE_ANON_KEY=
# Server-side only. Never prefix these with VITE_, or they ship to the browser.
STRIPE_SECRET_KEY=
RESEND_API_KEY=

3. Decide where the database lives

You have two documented options:

• Keep Bolt Database. Leave the .env values as they are and treat the export as a copy of the front end. Simple, but you still depend on Bolt Cloud.
• Claim it into Supabase. On a Pro or Teams plan, open the database icon, then Advanced, then Claim, and finish the steps in Supabase. You must be an owner of the Supabase organisation. After that, the database is a project in your own Supabase account.

Bolt's Database page now points to Claim as the way to move an existing Bolt database to Supabase. Its docs don't list exactly what comes across, so after claiming, confirm in Supabase that your tables, users and storage buckets are there. Also note that claiming into a free Supabase plan turns off leaked password protection; it needs a Supabase Pro plan or higher to stay on.

Whatever you choose, take a copy of the data first: in Tables, open each table, select all rows with the header checkbox and Export as CSV or JSON.

4. Move the server functions and secrets

If you claimed the database, Bolt's docs note that secrets added under Edge Functions, then Secrets in the Supabase dashboard update the same secrets Bolt uses, so you can manage keys from your own account. If you are moving to a different backend, each server function needs rewriting for that platform. Get new keys from each provider rather than reusing old ones.

5. Host the front end

For a browser-only app, npm run build produces the files to publish (Bolt's publishing docs mention folders such as dist or build). Bolt's own fallback is a manual Netlify deploy: run the build, download the project, then follow Netlify's drag-and-drop deploy. Netlify can't host a database or backend, which is why step 3 comes first.

For an Expo mobile app, the download is where publishing starts. Bolt's Expo docs have you install eas-cli, run eas login, npm install and npx expo-doctor, then set name and slug in app.json. You can't change the slug after the first build.

6. Get back into Bolt if you need to

A downloaded zip can come back: create an empty StackBlitz project, delete its files, drag in your download, save, and click Open in bolt.new. If the code went to GitHub, use the GitHub integration's Import an existing repository steps instead, which create a new Bolt project from the repository.

How to prevent it

• Connect GitHub early so the code history lives outside Bolt.
• Keep .env.example up to date as Bolt adds secrets.
• If you know you will want your own Supabase project, pick Supabase when you start the project, on a paid plan.
• Before deleting a Bolt project, use Export project first. Deleting also removes the Bolt database.

When to get help

An export is usually the first step of a bigger move. The prototype to product guide explains where it fits, exporting AI-built code covers the general handover, and moving off Lovable or Bolt hosting covers the hosting side. If data or policies are already messy, read Bolt database issues before you move anything.

Run the free vibe-code health check to see what you're exporting. If the code needs fixing before it moves, a Rescue Sprint is an audit plus fixes at a fixed price agreed after a technical assessment (from £750).