Bolt.new Download: Get Your Project as a ZIP or on GitHub

Bolt.new Download: Get Your Project as a ZIP or on GitHub

Bolt.new lets you take the project out in two real ways: download it as a ZIP, or connect a GitHub repository and push it there. Deploying is a third button that looks similar and does something else entirely: it puts the built result online without giving you the source. The ZIP arrives without node_modules, which is normal, and it needs one build step before it becomes a website.

What can you actually take out of Bolt.new?

The ZIP download. You get what you see in the file tree: source files, configuration and the package manifest. It is the fastest way to have a copy on your own disk.

The GitHub connection. The project goes to a repository you own. From there it is an ordinary project: clone it, edit it in your editor, deploy it anywhere. This is safer than a ZIP for one reason: the copy sits in a place that belongs to you and survives anything that happens on the platform side.

The deploy button. Often confused with export. Deploying uploads the built result to hosting, so the site is online in a minute. The source stays where it was. Having a live URL is not the same as having the code.

What each one gives you

That last row is where the confusion starts. Deploying shows a visible result fastest, so it feels like the job is done. But it hands over no sources, and on the day platform access goes away you are left with an address that stops opening.

Why is there no node_modules folder in the ZIP?

This is the first surprise when people unzip: the project looks complete, but the dependency folder is missing. It looks like a broken export.

It is not. That folder is not part of your project. It is rebuilt from the list in package.json with one command on your machine. It also weighs hundreds of megabytes and contains files compiled for a specific operating system, so shipping it would bloat the download and hand you binaries that may not run on your computer at all.

The same applies to the build output folder. It is derived from the sources, not stored with them.

The practical rule: having package.json with its dependency list matters more than having the dependencies. If that file is missing, then the export really is incomplete, and reconstructing the list by hand is painful.

What does "runs in the browser" mean for the move?

Bolt.new runs your project inside the browser rather than on a remote machine. For development that is genuinely convenient: nothing to install, everything starts instantly.

For moving out, it means one thing worth knowing in advance. The environment you watched it work in was a browser one; on your computer or your server it will be an ordinary one. In most cases there is no difference, but if the project leaned on something specific to that in-browser environment, it will behave differently outside. There is only one way to find out, and it is the same as the advice below: build and run it yourself before you cancel anything.

Four checks before you cancel the subscription

Check that the dependencies install. Installing on a different machine surfaces half the problems immediately: private packages, a pinned runtime version, missing files.

Look for calls to the platform. Search the sources for http. If the app fetches data from the platform's own infrastructure, it will stop working without an active account no matter how many files you have.

Check environment variables. Usually the export contains an example file and no values, which is correct. It means you have to fill them in before running, and any keys that lived on the platform are worth rotating anyway.

Confirm everything arrived. Compare the file tree in the archive with what you see in the platform. A missing folder shows up at the worst possible moment.

What does the build step look like if you do it yourself?

Do not be put off: it is two commands, and nothing gets broken. Building does not touch your sources, it writes the result next to them.

Install Node.js, open a terminal in the project folder, then install dependencies and build. In most projects that is npm install followed by npm run build. A folder appears, usually dist or build, and its contents are your website.

Three things commonly go wrong:

• An error about the Node version. The project was built for a different runtime. package.json usually says which one it needs.
• An error about an unavailable package. A dependency is private or was removed from the registry. Rare for platform-generated projects, but it happens.
• The build passes and the page is blank. Almost always empty environment variables. Find the example file and fill in your own values.

If none of the three explains it, this is the moment when half an hour of a developer's time is cheaper than an evening of guessing.

Where can the built project live?

A built project without a backend runs on any static host: Netlify, Cloudflare Pages, GitHub Pages, or ordinary hosting over FTP. That is free or nearly free and needs nothing but the folder.

If the project has a server part, the move is harder: it has to be stood up separately and the addresses repointed. Honest advice here is to budget a few hours of a developer rather than guess, especially if the platform wrote that part and you have not read it.

About the domain, the order matters. Put the project on the host's temporary address first, check it end to end, and only then change the records at your registrar. While the domain still points at the old place, any breakage is calm to fix. Cancel the old subscription a week after the move, not on the same day: repointing a domain takes minutes, restoring a deleted project does not work at all. The same sequence for another builder is described in how to move a Lovable project to GitHub.

How does export work in Zugo?

For comparison, since the question behind "bolt.new download" is usually "will I be locked in". In Zugo the project is pushed to your own GitHub repository, and single-file sites and games arrive ready to serve: everything is inline, so the folder opens by double-clicking and can go straight to a static host with no build step. React apps arrive as sources, so they follow the ordinary install-and-build path described above.

What matters more than the mechanics is that the question has an answer before you start. The mechanics are in can I export the code from an AI builder and export an AI app to GitHub.

In short

Downloading gives you the sources, the GitHub connection gives them to you more safely, and deploying does not give them at all. A project with a bundler needs one build step before it becomes a website, and the missing node_modules folder is correct rather than broken. Spend ten minutes on the four checks before you cancel anything: do dependencies install, does the app call the platform, are the environment variables filled in, did the whole tree arrive.