Bolt.new Export Code: Prove the Project Works Outside Bolt

I would export Bolt.new code as a ZIP for a dated snapshot or use GitHub for continuing development. Before switching hosting, make the saved version build and pass a real user action at the destination. Downloading files does not move the services those files call.

This is a documentation-based procedure for web projects, with a suggested event-registration trial below. I have not performed a paid-account Bolt migration. Mobile projects and specialized runtimes need their own deployment checks.

Download a ZIP for a snapshot; use GitHub for continuing edits

Bolt documents project title → Export → Download for a ZIP snapshot. Its download guide describes unzipping the project and running it locally with Node.js.

Its GitHub integration supports a repository workflow, including branches and synchronization.

Choose the format around the next job:

A ZIP is easy to hand over, but a filename such as project-final.zip gives the next person little context.

Name the archive with a date and include a note describing which live version it represents. Keep the original archive separate from your working extraction.

For a repository, confirm that the most recent change is present on the branch you plan to deploy. A connected GitHub icon does not prove the production host watches that same branch.

Inventory the services before selecting another host

The code archive is only one part of the handoff. Bolt Cloud provides hosting and backend services such as databases, authentication, storage and server functions.

Write down which of those services the exported project actually uses. A repository connection does not document their destination or transfer their ownership. Build this inventory before choosing a host:

For every dependency, choose retain, migrate, or replace. For example, retaining an existing database while moving the frontend may be reasonable. It is still a dependency on that database provider. Do not describe the project as fully independent until you have accounted for it.

This inventory also prevents an expensive mismatch. A static file host may fit a browser-only frontend; it cannot execute an application’s server endpoints simply because the repository contains JavaScript.

Reproduce the installation before modifying the project

Start from an untouched extraction or clean clone. Read package.json, the README if present, and the lockfile. Look for scripts such as dev, build, preview, start, and test; generated projects do not all use the same names.

The following is an example for an npm project with a valid package-lock.json and a build script. Run each command separately:

npm ci
npm run build

Save the first failure before making a repair. npm ci uses the existing lockfile and fails if it disagrees with package.json.

If the project uses Bun or pnpm, use its matching lockfile and installation workflow. If there is no npm lockfile, npm install may be needed to create one before adopting npm ci.

Write down the runtime version that passed, using node --version, plus the package-manager version. “Install the latest Node” changes over time.

Record installation flags in the handoff. When those flags shaped the lockfile, the clean installation needs the same settings.

After the build passes, inspect its output using the project’s documented production-preview or start command. Use npm run preview only if that script exists and fits the project.

Use npm run dev separately when you need development inspection. Development mode may handle assets or route fallbacks differently from the destination host. Accept the production deployment using the saved version.

Reconstruct environment configuration safely

Keep a list of variable names and where they are configured. Share secret values through the appropriate secret manager or hosting settings, rather than in a public repository or setup document.

Example inventory:

DATABASE_URL: server only; supplied by database provider
VITE_API_ORIGIN: browser-visible Vite example; destination must allow this origin
AUTH_CALLBACK_URL: auth service setting; update for the final hostname
PAYMENT_WEBHOOK_SECRET: server only; verify the destination webhook

These are illustrative names, not a claim about the variables in your Bolt project. A browser-only project still needs a separate server service to use server-only credentials.

For a Vite project, Vite’s environment documentation explains that variables exposed through the default VITE_ prefix reach client code.

Treat that prefix as browser-visible configuration. Putting a privileged database credential behind such a name does not make it private.

Ask the maintainer to identify every value shipped into browser JavaScript and every value required only by a server process.

Also distinguish build-time configuration from runtime configuration: changing a host setting may require a new build if the value was compiled into the frontend.

Test the saved version with a protected route and a data write

Example trial: move an event-registration app

Suppose the project has public event pages, attendee registration and an organizer-only roster.

For the first destination deployment, you retain the existing backend while moving the frontend. This is a proposed evaluation, not a reported migration.

Give the developer the saved source version and service inventory. Ask them to build without your Bolt browser session, then check the destination hostname:

• Open an event detail URL directly and refresh it, using a path from your project.
• Register a disposable attendee and confirm the record persists in the intended database.
• As the attendee, request the organizer roster and try a roster update that should be denied.
• As the organizer, open that registration and save a permitted status change.

Pass when the registration persists and the attendee cannot read or modify the organizer’s roster. Verify the denial at the backend; hiding the roster link does not establish the rule.

Use the acceptance sheet to save the exact source version, path, account role and result. Supply your own representative paths and test accounts:

Keep a permitted action and a denied action in the handoff record. The next maintainer should be able to repeat both after a dependency or hosting change.

Keep the original project operating during the trial. Use a destination preview or temporary hostname, then compare the same actions against both environments. Avoid using production payment transactions as a diagnostic shortcut.

Verify the owner-triggered sync before handing over a branch

Bolt’s GitHub documentation says merges happen in GitHub and describes automatic commits. It warns that near-simultaneous Bolt and external changes can cause Bolt to overwrite the external version.

A less obvious handoff gap concerns shared projects: collaborators’ Bolt edits sync when the project owner next opens the project. The collaborator cannot manage the GitHub integration.

If a collaborator made the last change, have the owner open the project, then inspect that exact change on the intended repository branch. Save the commit before a developer clones it or a host deploys it.

I would assign one active editor per branch during a migration. Agree on a simple handoff: finish and save work, inspect the repository diff, then let the next person begin.

For a larger change, use a separate branch and review its difference before merging.

Do not equate a branch name with a deployment environment. Record which branch the production host watches and whether pushing to it publishes immediately. This is how you avoid an unfinished repair appearing on the customer domain.

Fix failures in the order they appear

If installation fails, resolve the package manager, lockfile, and runtime mismatch first. Do not start changing application components while the dependency tree is uncertain.

If the build passes but the deployed screen is blank, inspect browser errors and network requests. A missing configuration value, an asset path, or a blocked API request each calls for a different fix.

If only refreshed detail pages fail, investigate routing at the destination host. If data reads work but writes fail, inspect authorization, service configuration, and the target environment. A frontend rebuild will not repair a database permission rule by itself.

Save the failure and its fix in the handoff document. That record becomes more valuable than another clean screenshot of the homepage.

Next step: hand over one saved version and repeat the registration trial

Give the maintainer these items:

• The unchanged ZIP or repository commit, with its branch and source date.
• The installation and production-build commands, runtime version and required flags.
• Environment-variable names and the person or service supplying each value.
• The retain, migrate or replace decision for every running service.
• The completed acceptance sheet, including a permitted organizer action and a denied attendee action.
• A rollback instruction and the separate database backup/restore procedure.

My next step would be the event-registration trial above on a temporary hostname. Continue with the hosting move when the developer can repeat the clean build, persistent registration and denied attendee action from the saved version.

For a broader explanation of what portability includes, use our code-export guide. For choosing tools with different export models, consult the code and site migration shortlist. The Bolt profile supplies the documented product context.

Keep the source copy and the acceptance record together. Resolve a failed build, missing service owner or failed permission check before switching customer traffic.