How to Export Bolt.new Code to GitHub

Built something in Bolt and want the code in a GitHub repository you own? Maybe as a backup, to share with a developer, or to deploy with the host of your choice. Bolt handles the Git side. You connect your account and name the repo.

Before you start

• An individual GitHub account. If your team works in a GitHub organization, an org admin sets that up separately with Bolt's organization setup guide.
• You need to own the Bolt project. Only the project owner can connect and manage the GitHub integration; collaborators don't see the GitHub icon.

Export your Bolt project to GitHub

Prefer a zip file instead? Click the project title in the top left, then Export > Download. You get the whole project to open in your own editor (you'll need Node.js installed to run it). From there, the Cursor guide shows how to push a local folder to GitHub.

What changes after you export

Bolt commits for you. Every time you make a change that doesn't break the project, Bolt creates a commit. You don't write commit messages or push anything yourself.

Changes made outside Bolt come back in. Bolt checks GitHub every 30 seconds for updates made outside Bolt and pulls them in. So you can edit on GitHub, or in a local editor and push, then carry on in Bolt. In the rare case that Bolt and GitHub change at almost the same moment, Bolt keeps its own changes and overwrites the GitHub version.

Branches work, but merging happens on GitHub. You can create and switch branches from the GitHub icon menu, and each new branch is created in your repository too. Bolt doesn't merge branches in the app, so you merge them on GitHub, usually with a pull request.

Collaborators sync through you. If someone else edits your shared project, their changes sync to GitHub the next time you, the owner, open the project.

Disconnecting is permanent. Disconnecting a project removes its connection to the repository, and you can't reconnect it yourself. If you ever need to, Bolt's support team can help. After a disconnect, Bolt's version history is how you restore earlier versions.

Where secrets belong. Bolt's database Secrets settings store API keys and passwords for your server functions, so the values stay outside your plain code and never reach your users' browsers. Bolt's GitHub docs don't say whether a .env file is kept out of the repository, so check for one yourself. That's the first check below.

Before you ship: what to check in the exported repo

Open the repo on GitHub and work through these before you share the link with real users:

1. No real secrets in a committed .env file. Open the repository on GitHub and look for .env or .env.local. A Supabase URL and publishable key are designed to be public. A secret key is not: if you find one, rotate it first (GitHub's own advice for leaked secrets, since deleting the file doesn't erase it from Git history), then keep the new value in Bolt's Secrets settings instead of the file. More on why this matters: secret exposure.
2. No secret keys in client code. Variables prefixed with VITE_ or NEXT_PUBLIC_ are bundled into the code sent to the browser. A service role key, a Stripe secret key or an AI provider key belongs in Bolt's Secrets or your host's server-side settings. See Secret API key exposed in client bundle.
3. Row level security on every table, with real policies. If your app uses Bolt Database or Supabase, each table needs RLS enabled and policies scoped to the signed-in user. Bolt's database Security settings flag problems such as a missing RLS policy or one that is always true. See Missing row level security.
4. Server functions check input and handle errors. Each one should reject bad input and fail with a clear message, not a blank screen. See Missing input validation and Error handling in AI-built apps.
5. Login and AI endpoints are rate limited. Without limits, one script can hammer your sign-in form or run up your AI bill. See No rate limiting on sensitive endpoints.

For more depth, Bolt.new Apps: 7 Production Issues covers the patterns that break in production, with code-level fixes.

A second pair of eyes before launch

Your Bolt repo starts private. To have FinishKit review it, connect the FinishKit GitHub App and give it access to that repository. The full review covers eight production readiness dimensions and ends in a Finish Plan that puts the blockers first. Made the repo public? You can also paste its URL into the free quick readiness check for a fast first pass, though that runs a short set of checks rather than the full review.

Sources: Bolt: GitHub for version control, Bolt: Manage your projects, Bolt: Database Secrets settings, Bolt: Database Security settings, GitHub Docs: Removing sensitive data from a repository, Supabase: API keys, Vite: Env variables and modes, Next.js: Environment variables.