Migrate from Bolt (bolt.new) to your own hosting (2026)

Migrating off Bolt (bolt.new) is one of the more straightforward exits, because Bolt generates real, standard code and gives you a one-click way to get it out. Bolt's own support docs describe two export routes from the editor — download the project as a .zip, or push it straight to a GitHub repository — and a native Netlify integration for hosting (source).

Most Bolt apps are frontend-first: a standard Vite + React build (Bolt can scaffold other frameworks too). That makes the migration shape close to Lovable's — the frontend is genuinely portable, and the only real question is what, if anything, the app uses for a backend.

What a Bolt project actually contains

A typical Bolt build looks like this:

Layer	Default in Bolt	What you migrate
Frontend	Vite + React (sometimes Next.js, Astro, etc.)	GitHub repo → Netlify, Vercel, Cloudflare Pages, or any static host
Backend / DB	Often none, or Supabase if you added it	Keep Supabase, or add a backend if the app only had mock data
Auth	Whatever you wired in (commonly Supabase Auth)	Redirect URLs, providers
Env vars	.env with VITE_* keys	Same keys on the new host
Hosting	Bolt's Netlify integration or Bolt-hosted preview	Your own Netlify/Vercel project
Custom domain	Configured in the host	DNS + SSL on the new host

Bolt itself — the in-browser editor and AI agent (built on StackBlitz) — cannot be self-hosted. Only the application it generates is portable. If you want to keep editing in Bolt after moving hosting, keep the GitHub sync connected; if you are leaving for good, the agent stays behind with the platform.

Decide what you are actually migrating

Two scenarios, very different scopes:

Scenario A: Frontend-only app. Many Bolt projects are pure frontend — a UI, maybe calling some public API, no database. The migration is just a static deploy: push to GitHub, point a host at it, done. This is the common case and it's quick.

Scenario B: App with a Supabase (or other) backend. If you wired in Supabase for data and auth, the frontend move is the same, but you also decide whether to keep the existing Supabase project or move it under your own account. That backend half is the real work — and it's the same shape as the Lovable migration, so the Migrate from Lovable guide's Supabase steps apply directly.

Start with A. If there's a backend, get the frontend stable first, then handle Supabase as a second pass.

Step 1 — Get the code into GitHub

In the Bolt editor, open the project menu (click the project title, top-left) and choose Export. You get two options: Download for a .zip, or the GitHub option to push directly to a new repository in your account — connect your GitHub account when prompted (source).

Prefer the GitHub route — it gives you version history and a clean path to continuous deployment. Once the repo exists, clone it and tag a rollback point:

git clone <your-github-repo-url>
cd <project-name>
git tag pre-migration
git push --tags

If you only have the .zip, unzip it, git init, commit, and push to a new GitHub repo manually.

Step 2 — Inventory the stack

cat package.json
cat vite.config.* 2>/dev/null
cat .env 2>/dev/null

A standard Bolt + Vite project has:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}

So the build command is npm run build and the output directory is dist. If package.json shows Next.js (next build) or Astro instead, let the host auto-detect the framework rather than forcing Vite settings.

Where Bolt stores secrets

Browser-safe keys live in .env as VITE_* values — these are safe to expose and belong on the host's environment-variables panel. Anything that must stay private (a third-party API key the app calls) should not be a VITE_* variable in a frontend-only app, because everything in the bundle is public. If the app genuinely needs a secret, that's a signal it needs a small backend (a serverless function) to hold it. See the hub guide's secrets-moving principles for what to rotate vs carry over.

Step 3 — Build locally first

npm ci
npm run build
npm run preview

If npm run build fails locally, it'll fail on the host the same way. Fix build errors — usually a missing env var or a TypeScript issue — before deploying.

Step 4 — Deploy the frontend

Netlify

Bolt's first-class hosting path. You can deploy from inside Bolt via the Netlify integration, but to own it fully, deploy from your GitHub repo instead:

1. netlify.com → "Add new site" → "Import an existing project" → pick your repo.
2. Build command: npm run build. Publish directory: dist.
3. Add your VITE_* environment variables under Site settings → Environment variables.
4. Deploy.

For client-side routing (direct navigation to /dashboard returning 404), add public/_redirects:

/* /index.html 200

Netlify's free tier adds no branding, supports custom domains, and issues SSL automatically.

Vercel

Equally good for a Vite project: import the repo at vercel.com/new, framework preset Vite (auto-detected), build npm run build, output dist, add the VITE_* env vars. For SPA fallback add a vercel.json with a catch-all rewrite to /index.html.

Step 5 — Handle the backend (Scenario B only)

If the app uses Supabase, you have the same choice as any Supabase-backed migration: keep the existing project (lowest risk) or move it under your own account. The mechanics — creating a new project, running the supabase/migrations/, moving data and storage, re-adding Edge Function secrets, and the passwords-don't-migrate caveat — are covered step by step in the Migrate from Lovable guide. Don't duplicate that work; follow it.

If the app had no real backend (mock data, hardcoded arrays), graduating is the moment to add one. The next-step guide below walks through standing up Supabase + Postgres from scratch.

Step 6 — Update auth redirect URLs

If the app uses Supabase Auth (or any OAuth), the new domain — both the host URL (my-app.netlify.app) and any custom domain — must be added everywhere the old Bolt/preview domain was registered:

• Supabase → Authentication → URL Configuration → Site URL + Additional Redirect URLs.
• Each OAuth provider's authorized redirect URIs.

New logins from the new domain fail until this list is updated.

Common gotchas

Client-side routing 404s. Covered above — Netlify _redirects or Vercel rewrites fix it.

Build passes locally, fails on the host. Almost always a missing or misnamed env var. Every VITE_* key on the host must match .env exactly.

A secret ended up in the frontend bundle. If you had a VITE_OPENAI_API_KEY (or similar) in a frontend-only Bolt app, it was public the whole time — rotate it immediately and move the call behind a serverless function.

The Netlify deploy works from Bolt but you don't control it. Deploying through Bolt's integration can leave the site owned by Bolt's flow. Deploying from your own GitHub repo into your own Netlify/Vercel account is what actually gives you ownership.

Where to go next

If your Bolt app had no backend, the next guide in this pillar — Your first real deploy: Supabase + Vercel from scratch — walks through adding Postgres, auth, and a custom domain end to end. If it was Supabase-backed, the Migrate from Lovable guide's backend section is the one to follow.