How to Move a Bolt or v0 Project Into Your Own Codebase and Hosting

Bolt gives you a zip file to download; v0 gives you a live, syncing GitHub repository — different starting points, but the same set of things to check before you switch off the builder. Neither tool locks your code in, but each documents its own current export, hosting, and domain setup, and both have changed recently enough that older guides describe a previous version of each. This is the current path for both, plus the shared checklist that applies regardless of which one you used.

How do I get a Bolt project into my own codebase?

In Bolt, open your project, click the project title in the top left, then click Export > Download. Bolt bundles the project and your browser downloads a zip file; unzip it, open a terminal in that folder, and run npm install && npm run dev to confirm it runs outside Bolt (Bolt). That local run is the real test — if it fails here, it will fail the same way on any host, so fix it before you touch hosting at all.

Where does Bolt host a project today, and how do I add my own domain?

When you publish inside Bolt, the project "automatically goes live on a free bolt.host domain" — this is Bolt's own current hosting, not a third-party service (Bolt). A custom domain is managed from the same Project settings: you can "purchase one through Bolt or connect a domain you already own," but this "requires a paid plan" — Bolt is explicit that "Custom domains are only available on paid plans, so you'll need to upgrade from Free to any paid tier to use one" (same source). Worth knowing before you rely on this: if you later downgrade to the Free plan, "you'll no longer be able to publish to your custom domain" (same source). None of this affects the zip export above — Export > Download gives you the code regardless of which Bolt plan or domain setup you're on; the hosting and domain settings only matter if you're staying inside Bolt's own hosting rather than moving to your own.

What happens to my Bolt database and secrets?

If your Bolt project uses Supabase, check whose account the database lives in. Bolt's Supabase integration lets you "select an existing Supabase project or create a new one," and its documentation adds that "to claim your database in Supabase, you must be a Supabase org owner" (Bolt). So if Bolt set the database up for you, claim it into your own Supabase organization before you rely on it outside Bolt. Disconnecting later is a two-sided step: disconnect Supabase in Bolt's account settings and remove Bolt from the authorized OAuth apps in Supabase (same source); neither deletes your data.

For credentials, click the database icon at the top center of the project, then Secrets. Bolt's documentation describes the purpose directly: secrets "are used by your server functions (sometimes called edge functions) to safely access sensitive information, like API keys or database passwords, without exposing them to users" (Bolt). None of these values transfer automatically to a new host — re-enter each one in your new host's own environment variable settings once you've moved the frontend.

How do I get a v0 project into my own codebase?

Open the Project menu → Settings → GitHub, click Connect, choose the GitHub account or organization under Git Scope, name the repository, and select Create Repository. v0's documentation confirms what this actually creates: "v0 creates a private repository and pushes the project's current code to it." After that, v0 commits each chat's changes to a working branch and publishes through pull requests (v0). Clone that repository and confirm it builds locally before you do anything else — this is the same principle as testing a Bolt export, just with a git clone instead of unzipping a file.

Where does v0 host a project, and how do I add my own domain?

v0 projects run on Vercel by default. From Publish → Customize Domain, or Project menu → Settings → Domains, you can use a free .vercel.app address or add your own domain. For a custom domain, v0's documentation directs you to "Inspect on Vercel" from the Publish menu, then "Follow the detailed instructions" inside the Vercel dashboard itself to "Configure DNS records" at your registrar (v0) — the domain setup is Vercel's own feature, surfaced through v0's interface rather than a separate v0-specific system.

What happens to my v0 database?

Go to Project menu → Settings → Integrations to see available database options. v0's own documentation describes two paths: reuse an existing database by clicking the arrow "to select from previously created stores," or click Create "to open the Marketplace and accept the provider's terms" for a new one (v0). When you add an integration this way, v0 "provisions a new user account on that service and adds the necessary environment variables to your project" automatically (same source) — and the database account itself sits with that provider, where you can sign in directly. Additional environment variables can be added manually anytime from Project menu → Settings → Environment Variables.

What's the shared checklist before I switch off either builder?

However you got your code out — Bolt's zip or v0's GitHub sync — the same handful of things need checking before the builder stops being the source of truth:

• Environment variables and secrets. List every value the builder's Secrets panel or environment settings held, and confirm each one is re-entered in your new host's own environment variable settings before the first production deploy. Neither Bolt's Secrets tab nor v0's Environment Variables settings transfer automatically to a different host.
• Database and backend ownership. Confirm you can log into the underlying database account (Supabase, or whichever provider was connected) directly, independent of Bolt or v0 — not just through the builder's integration panel. If you can't sign in without going through the builder first, that's a gap to close before you leave.
• Auth callback URLs. If your project uses OAuth sign-in (Google, GitHub, or any provider), update every redirect/callback URL registered with that provider to point at your new production domain before you cut traffic over — a stale callback URL fails silently for users mid-login rather than throwing an obvious error.
• Build and run locally. Confirm the project builds and runs with no builder-specific step (a Bolt-only or v0-only command, an implicit environment variable the builder injected) before you trust a new host's build pipeline with it.
• SEO and rendering check. Once the project is live on its own domain, confirm the pages you care about are actually crawlable there — check rendered HTML and page titles the way you would for any new site, rather than assuming whatever rendering behavior the builder had carries over unchanged.
• Domain cutover. Point DNS at the new host only after the new deployment is verified working on its own temporary URL (a .vercel.app or bolt.host address), so there's no window where the domain points at something broken.

What if I used Lovable instead?

This post covers Bolt and v0 specifically, because their export and hosting mechanics are different from each other and from Lovable's. If your project is a Lovable app, its GitHub sync, Supabase integration, and domain setup work differently in the details even though the overall shape (own your code, own your database, re-point your domain) is the same — see our guide to moving a Lovable project to your own hosting for that path specifically, rather than assuming these Bolt and v0 steps apply directly.

Example (hypothetical): A founder builds a waitlist app in v0 with a connected Supabase database. Before hiring a developer to extend it: connect the project to GitHub via Project menu → Settings → GitHub, clone the resulting repo, confirm it builds locally, log into the Supabase project directly (outside v0) to confirm independent access, list every environment variable from Project menu → Settings → Environment Variables, and add a custom domain through Settings → Domains before sharing the repo with the developer. This is illustrative only, not a test we ran.

What if something breaks after the move?

Exporting a Bolt zip or connecting v0 to GitHub doesn't remove the project from the builder, so the builder-side version stays available as a reference or a fallback while you debug the standalone copy. If the standalone build fails with a missing-variable error, that's almost always an environment variable that lived in the builder's own settings and was never copied over; check the checklist above before assuming it's a code problem. If OAuth sign-in breaks only in production, check the callback URL registered with your auth provider first — it's the most common single cause of a login that works locally but not on the real domain.

Bottom line: Bolt's Export > Download and v0's GitHub connect are both real, current export paths — a zip file and a syncing repository, respectively — and each documents its own current hosting and domain setup rather than the third-party arrangement (like Bolt's earlier Netlify integration) that older guides may still describe. The checklist that actually determines whether you're safe to switch off the builder — secrets, database ownership, auth callbacks, a local build, an SEO check, and a careful domain cutover — is the same regardless of which tool you used.