Do you actually own your Bolt site?

The short answer

You can own a Bolt site’s code, its database and its domain, and Bolt provides a route for each: the project can be downloaded as a ZIP or kept in sync with a GitHub repository under your account; Bolt Database, which runs on shared Supabase infrastructure, can be claimed into a Supabase organization you own; and a domain bought through Bolt can be moved out after the usual 60-day lock. Until you take those steps, Bolt hosts the site, runs the database and holds the domain for you. So a Bolt site is as portable as you’ve made it, and the making is a few deliberate actions rather than a rebuild.

A Bolt project connected to GitHub keeps a private repository in your GitHub account up to date after every change, and pulls in changes made outside Bolt. That makes the code portable. It does not, by itself, move the database, the hosting or the domain.

On ownership of the code itself, Bolt’s support pages are silent, but the StackBlitz terms of service that govern Bolt, republished on 14 September 2026, are not: you retain all rights in your content, and StackBlitz assigns to you its rights in the AI output generated for you. The same terms grant StackBlitz a licence to use your content for AI training unless you opt out in account settings, which is worth doing consciously either way.

What you should own

What Bolt controls by default

• Hosting. New projects publish to Bolt Hosting at a bolt.host address. Publishing is manual: edits don’t go live until you click Update. Custom domains need a paid plan.
• The database. Bolt Database runs on shared Supabase infrastructure managed by Bolt, with Supabase Auth for sign-in and storage buckets for files. Using your own Supabase project from the start is a paid-plan feature.
• Secrets live as Supabase edge-function secrets under the database panel. Server code, including Stripe payments, runs in those edge functions.
• The GitHub connection, once made, is Bolt’s to manage: disconnecting is permanent without support, and when Bolt and GitHub change at the same time, Bolt’s version wins.
• A Bolt-bought domain points at Bolt Hosting through a system record you can’t override from inside Bolt.

How to make the site portable

1. Download a ZIP from the project menu (Export, then Download) as a baseline copy.
2. Connect GitHub from your individual GitHub account, so Bolt creates the repository under you. Check the owner in the repository address.
3. Claim the database. Database panel, Advanced, Claim; you must be an owner of the Supabase organization it moves into. Afterwards the database is a Supabase project in your account. Bolt documents that outcome for the database itself and not for users, storage, functions or secrets, so verify each in the Supabase dashboard; the claim guide has the before-and-after checklists. Don’t “connect a different Supabase project” instead, which Bolt warns may lose the data.
4. List the secrets and variables. Bolt recommends asking the project itself to list every environment variable it requires and where each comes from.
5. Sort out the domain. A domain you connected from your own registrar is already yours. A Bolt-bought domain can have its NS records pointed at a DNS provider of your choice, or be transferred: to your own Name.com account within the 60-day lock, or to any registrar after it, via Bolt support. The builder-domain guide has the details.
6. Prove the deployment path by connecting a host to the repository and running the site on the host’s own address. Bolt doesn’t document a Vercel or Cloudflare recipe; its guidance is to set up your own build from GitHub, and Netlify has a documented manual route.

The full procedure, including DNS and what to do with Bolt afterwards, is in moving a Bolt site to GitHub and your own hosting.

What may not move automatically

• The database, unless claimed. Bolt’s per-table CSV or JSON export is a copy of rows, not a migration.
• Uploaded files. Bolt shows the storage buckets but doesn’t yet support managing individual files from its interface; after a claim they’re in Supabase Storage.
• Sync history. A project disconnected from GitHub can’t be reconnected to the same repository without contacting support.
• Stripe webhooks are registered by Bolt against the edge functions; they travel with a claimed database, not with the frontend.
• The framework and settings. Bolt doesn’t document which framework it picks or whether the ZIP includes an .env file; check package.json and the project’s environment variables yourself.

What happens if you stop using Bolt

What Bolt’s documentation says, and only that; the cancellation guide compares all four builders.

• Cancelling a paid plan downgrades to Free at the next billing cycle. Sites already published to a custom domain stay online, but you can’t republish or reconnect a custom domain on Free.
• Free hosting has hard monthly limits on traffic and requests, applied across the account, and sites stop serving once they’re reached.
• An unpublished project’s Bolt Database may be paused after about six days of low use; a published one isn’t paused.
• Deleting a project deletes its Bolt Database; a connected Supabase project is unaffected. Bolt prompts you to export first.
• Domains bought through Bolt stay in your account after a downgrade and can still be managed there. Custom domains and domain purchases themselves need a paid plan.
• Deleting a project removes its chat history, files and Bolt Database; deleting the account deletes its projects.
• The StackBlitz terms say that if StackBlitz ends your access other than for cause, it will give you thirty days to export your content before it may delete it.

What we could not verify: whether Bolt deletes projects or databases after a period of inactivity beyond the pause, what happens to a Bolt Database when a subscription simply lapses, and whether secret values can be viewed again after saving.

Ownership checklist

The real test

For a Bolt site with GitHub connected and the database claimed, yes: the repository and the Supabase project are the whole site, and the code is ordinary JavaScript any tool can work on. With the database still in Bolt, the answer is “the frontend, yes; the data only through Bolt”. The portability test scores each layer.

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.

• Terms of service (published 14 September 2026) · StackBlitz
• Projects and files: export and transfer · Bolt
• Git integration · Bolt
• Project lifecycle · Bolt
• Publish your site · Bolt
• Hosting plans · Bolt
• Bolt Database · Bolt
• Database: advanced (Claim) · Bolt
• Supabase integration · Bolt
• Secrets · Bolt
• Domains · Bolt
• Purchase a domain · Bolt
• DNS records · Bolt
• Billing · Bolt
• Stripe integration · Bolt
• Preview issues: listing environment variables · Bolt