How to Export Your Code Out of Bolt

Bolt does not trap your code. The project you built is a normal directory of files — a package manifest, a build config, source folders — and you can have all of it in about thirty seconds.

The interesting part starts after that. Bolt runs your project inside a sandboxed environment in the browser, and that environment quietly provides a few things a normal machine does not: a preinstalled toolchain, a preview server on a domain that already exists, and a set of assumptions about what your project needs to run. Pull the files out and those assumptions leave with the tab.

None of this is hard. It is just a list, and it goes in a particular order.

Two ways out, and which to pick

Download the project. You get a zip of the file tree, immediately. Fine for a quick look; bad as your migration path, because you get a snapshot with no history. Nobody can see how the app arrived at its current shape, including you in three weeks.

Push to GitHub. Bolt can connect to a GitHub account and create a repository from the project. Use this one. History is the thing that makes a codebase maintainable by someone other than its author, and starting the repo at the moment of export is better than starting it never.

If you are handing the project to a developer, push to GitHub and add them as a collaborator rather than emailing a zip. It sounds obvious and it is skipped constantly.

What the sandbox was handling for you

Before you try to run anything, know what changed by leaving the browser.

That last row is the one that changes the nature of the project. Escape.tech scanned 5,600 vibe-coded apps and found more than 2,000 vulnerabilities, and almost all of them only became vulnerabilities at the moment the app went public.

Getting it to build locally

Clone the repo, check the package manifest for an engines field or a lockfile hinting at the Node version, install dependencies, and run the dev script.

Three failures account for most of what goes wrong here:

1. Node version mismatch. The sandbox ran a specific version; your machine runs another. Symptoms are cryptic build errors in dependencies rather than in your code. Pin a version and move on.
2. Missing lockfile. If the export did not include one, your install resolves fresh versions and you get behavior the app never had. Commit a lockfile immediately after the first successful install so everyone builds the same thing.
3. Packages that do not exist. Worth checking explicitly: the Cloud Security Alliance found roughly 19.7% of 2.23 million AI-generated code samples referenced hallucinated package names. Most fail loudly at install time. The dangerous case is when someone has since registered the name — see dependency audits for AI code.

Environment variables, the reliable time sink

Bolt lets you set values in its interface, which means they are not in your repo and you may not have a complete list. Reconstruct it: search the source for every reference to an environment variable and write down each name.

Then handle two things that trip up nearly every Vite or Next.js export. Client-visible variables need the framework's specific prefix or the build strips them — and a missing value at build time frequently produces a blank page rather than an error, which sends people hunting in the wrong place. And any key that is genuinely secret must not be a client variable at all; if it is prefixed for the browser, it is in the bundle and it is public.

If your deploy comes up empty, start with the build-time variables — environment variables not working covers the specific ways this breaks.

Rotate keys, then check what is in the bundle

Do this before the first public deploy, not after.

Rotate anything that has ever been pasted into a prompt, a chat, a screenshot, or a committed file. Then build the project and search the output bundle for your key strings. If a secret appears there, no amount of server-side intent saves you — it shipped. API keys exposed in the frontend explains the pattern and the correct fix, which is a small server-side route rather than obfuscation.

Replace whatever was pretend

AI builders produce demos that look complete because parts of them are simulated. Check for these specifically before you call the app real:

• Mock data. Arrays of sample records hardcoded in components, sometimes behind a flag nobody flipped.
• A backend that does not exist. Calls to endpoints that were never implemented, with optimistic UI covering the gap.
• Auth that only checks the frontend. A login screen that hides a route is not access control; the data behind it must be protected server-side.
• No validation. Forms that accept anything and write it straight through, which is how duplicate records start.

Deploy, then harden

A Bolt project deploys to any standard host: connect the repo, set the build command and output directory, add environment variables in the host's settings, ship. Deploying to Vercel covers the specifics.

Getting deployed is not the finish line, though. The engineering that was never generated — error handling on external calls, rate limiting, database indexes, a test around login and payment, monitoring so you learn about failures from a tool instead of a customer — is still ahead of you. The full list, in priority order, is the production readiness checklist. If you would rather have someone else do the finding, what a code audit costs sets expectations.

Frequently asked questions

Will the app behave the same outside Bolt? Mostly, with the exceptions above: Node version, missing environment values, and anything the sandbox smoothed over. Frontend behavior transfers essentially unchanged. Anything that touched the network, the filesystem, or a native module deserves a second look.

Should I keep working in Bolt after exporting? You can, but pick one source of truth. Editing in both places without a disciplined sync is how a day of work disappears. Most teams export once development moves to a real editor, and treat Bolt as the place the project started.

Is it worth exporting if I am not technical? Yes, for one reason: owning the repo means you can hire anyone to work on it. That option is worth having before you need it, and it costs nothing today. If you are not sure what to do with the code once you have it, that is a conversation with an engineer — not a reason to leave the project sitting in a browser tab.

---

If your Bolt project is exported and you are now deciding whether it is safe to put in front of paying customers, that question has a concrete answer and it takes a few days to produce. SprintX audits exported AI-built projects and hardens them at fixed scope. Send us the repository.