How to move a Bolt website to GitHub and your own hosting

Bolt keeps a GitHub repository in sync and lets you download the project outright, so the code is easy to get. The parts that need care are hosting, the database, and the domain, each of which Bolt can hold for you. This guide is the sequence.

Published September 11, 2026 · About a 9 minute read · Last reviewed September 2026

This is the Bolt-specific version of leaving an AI builder. It maps what Bolt offers onto the general guides rather than repeating them. Everything was checked against Bolt’s support documentation on the date at the top; Bolt changed its hosting and project format during 2025 and 2026, so check the linked pages before acting.

Not sure yet what you own there? The companion guide, do you actually own your Bolt site?, sorts the layers before you move anything.

What Bolt lets you take with you

Layer	What Bolt offers today
Code	Export, then Download gives you a ZIP of the project with no documented plan restriction. The GitHub integration creates a private repository on `main` under your GitHub account, commits every change, and pulls outside changes every 30 seconds.
Hosting	Bolt Hosting at a `bolt.host` address, free with traffic limits. Custom domains need a paid plan. Publishing is manual: edits don’t go live until you click Update.
Backend	Bolt Database runs on shared Supabase infrastructure. A “Claim” action moves it into a Supabase organization you own. Or the project uses a Supabase project in your own account from the start, on paid plans.
Domain	Domains bought through Bolt are locked for 60 days; within that window they can move to your own Name.com account, and after it to any registrar. Bolt doesn’t let you override the record that points a Bolt-bought domain at Bolt Hosting.
Secrets	Server-side secrets live under Database, then Secrets, as Supabase edge-function secrets. Browser values use `VITE_` names.

Step 1: Work out which kind of project you have

Where is it published? Bolt Hosting, at a bolt.host address or a custom domain, is the default for projects created since August 2025. Older projects may publish to Netlify instead, in which case the host is already an ordinary Netlify site in your Netlify account.
Which database? Open the database panel. “Bolt Database” means the shared Supabase infrastructure Bolt runs; a connected Supabase project means it’s in your own Supabase account. No database means steps 4 and 6 are short.
Is GitHub connected? Check the project’s GitHub status. If so, most of step 2 is done.

Bolt projects are JavaScript projects (Node on the server, any browser framework on the front) that run with npm install and npm run dev. Bolt doesn’t document which framework it picks; look at package.json or ask the project which one it uses.

Step 2: Get the code

Download a ZIP first, from the project title menu: Export, then Download. That’s your backup. Then connect GitHub if it isn’t connected: Bolt authorizes your individual GitHub account (an organization needs its own setup, which Bolt documents separately), installs its GitHub App, and creates a private repository. From then on Bolt commits automatically after every change that doesn’t break the project.

The “Open in StackBlitz” export is being retired as projects move to Bolt’s new storage format, so don’t plan around it. GitHub and the ZIP are the durable routes.

Step 3: Make sure the repository is under an account you control

The repository is created in the GitHub account that authorized Bolt, which is usually the project owner’s. Check the owner in the repository address, as the GitHub guide describes. If a freelancer connected their account, you have the ZIP: put it in a repository under your own account and connect the new host to that. Bolt can also import a repository by URL, but that creates a new Bolt project rather than relinking the old one.

Step 4: Inventory secrets and platform-managed services

Method in the secrets guide. Bolt specifics:

Server secrets are under the database icon, then Secrets. They’re Supabase edge-function secrets and move with the database when you claim it. List the names.
Browser values are VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY.
One check worth making. Bolt’s introduction to databases lists VITE_SUPABASE_SERVICE_ROLE_KEY as an example variable name next to those two. The documentation doesn’t say Bolt creates such a variable, and we haven’t verified that any project ships one. But in a Vite project the VITE_ prefix marks a value as available to browser code, and the service-role key bypasses every access rule. So look through the project’s environment variables: if a name like that holds a real service-role key, treat the key as exposed and rotate it in Supabase before doing anything else.
Getting the full list: Bolt recommends prompting the project to “perform a full review and list every environment variable the application requires”. Do that and keep the answer.
Payments: the Stripe integration uses your own Stripe account and runs in Supabase edge functions, with webhooks registered automatically. It stays with the database.
Email: Bolt typically uses Resend with your own API key, stored as a secret.
Forms: there’s no separate forms product; forms post to functions or the database, so they move with them.

Step 5: Prepare the replacement host

Bolt doesn’t document deploying to Vercel or Cloudflare; its guidance is to connect GitHub and set up your own build with whatever host you choose. Follow the host move guide and the walkthrough for Vercel, Netlify or Cloudflare: connect the repository, set the build command (usually npm run build) and output folder the framework uses, and enter the VITE_ values. Netlify has a documented manual-deploy path too: build, download, upload.

Step 6: Claim or keep the database

Bolt Database

Claim it. In the database panel, open Advanced, then Claim, and follow the prompts to transfer the Supabase project into a Supabase organization you own; you must be an owner of that organization. After the claim, the database is a Supabase project in your account. Bolt’s documentation states that outcome for the database itself; whether users, storage, functions, secrets and the project keys come across unchanged isn’t stated, so check each in the Supabase dashboard straight away. The claim guide is the precise version, with checklists. This is still the whole reason the exit is manageable.

Don’t “connect a Supabase project” as a way out. Bolt warns that connecting a different Supabase project replaces the connection and may lose the Bolt Database’s data. Claim instead. If you only need the rows, tables can be exported as CSV or JSON, but that’s a copy, not a migration.

Your own Supabase

Nothing to move. Removing the connection in Bolt leaves the Supabase project untouched. Note the organization owner and billing, per the data guide.

Step 7: Deploy and test before changing DNS

Test on the new host’s own address: pages, sign-in (Supabase Auth, so it should just work once the values are in), forms, storage, Stripe in test mode. Add the new domain to any OAuth provider’s allowed redirects, and check the Supabase project’s site URL and redirect settings point at the new domain.

Step 8: Change the website DNS records

Follow the DNS guide. Bolt specifics:

A domain you connected to Bolt has www as a CNAME to site-dns.bolt.host and the root as an ALIAS or flattened CNAME to the same, or an A record of 75.2.60.5 where the registrar can’t do ALIAS. Replace those with the new host’s values. A TXT verification record exists only if you connected a subdomain.
A domain bought through Bolt is harder. Bolt lets you edit most record types for it but won’t let you create an A or AAAA record where its own system record already points at Bolt Hosting. Your options: change the NS records to your own DNS provider, which Bolt does allow, and manage the domain there; or transfer the domain out, to your own Name.com account within the first 60 days or to any registrar afterwards, using the transfer guide. Bolt doesn’t document the transfer-out steps; ask its support for the authorization code.

Step 9: Verify the site, forms, auth, email and payments

The site loads at the domain and at www, over https.
Sign-up, sign-in and password reset work from the real domain.
Forms and anything that writes to the database work, and the rows land in the claimed Supabase project.
Uploaded files still load from storage.
Email sends through your Resend account.
Payments complete and the Stripe webhook records them.

Step 10: Only then decide what to do with Bolt

Disconnect the custom domain in Bolt, then unpublish if you want the bolt.host address dead. Bolt requires the domain be disconnected before unpublishing.
If you keep the project on a Free plan, sites already on a custom domain stay online but can’t be republished, and free hosting stops serving once it hits its monthly traffic limit.
Don’t delete the project until the database has been claimed: deleting a project deletes its Bolt Database. Bolt prompts you to export first.
An unpublished project’s Bolt Database can be paused after about six days of low use, so if you haven’t claimed it yet, don’t unpublish.
Disconnecting GitHub is permanent, and there’s no need to do it: leaving the connection in place is harmless as long as nobody edits in Bolt.

Traps: when “connected to GitHub” isn’t the whole site

Bolt wins conflicts. Simultaneous edits overwrite GitHub with Bolt’s version.
The database is not in the repository and isn’t yours until claimed.
A service-role key stored under a VITE_ name in a Vite project should be treated as exposed. Check whether your project has one; rotate it if so.
Transferring a project to another Bolt user removes the GitHub integration, requires removing the custom domain first, and strands a Bolt-bought domain until it expires. Move the code and claim the database instead.
Free hosting has hard limits and stops serving when they’re reached; a site you thought you’d left running may not be.

With the repository, the host and the Supabase project in your own accounts, the site is yours to hand to any developer or coding agent. Editing its words without prompting anyone is what Refino adds to a site in that state.

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

Keep going

Or go back to the overview of what owning your site means, which ties all of these together.

Do you actually own your Bolt site?
What you own when you build with Bolt, and what still depends on Bolt: the code and its GitHub sync, Bolt Hosting, domains bought through Bolt, Bolt Database versus your own Supabase, secrets, and what the documentation says happens when you stop paying. With an ownership checklist.
About a 8 minute read
How to take your website with you when you leave an AI builder
Leaving an AI website builder means more than downloading the code. An inventory of everything a site depends on, from the domain to the database to the secrets, and a structured checklist for moving it all.
About a 10 minute read
How to put your website’s code in GitHub
How to get the actual source code of your website into a GitHub repository you control, whether it’s already on GitHub under someone else’s account, only on a developer’s computer, or inside an AI or site-building platform. With a verification checklist.
About a 11 minute read