Moving off Lovable or Bolt hosting to your own stack

Symptom

You import the project into Vercel or Netlify, the build goes green, and the home page loads. Then the problems start. Refreshing any page other than the home page shows Vercel's not found page:

Or the app loads as a blank page, and the browser console shows the Supabase client refusing to start:

Or everything works until someone logs in with Google, and they land back on the old lovable.app or bolt.host address. Payments still go through, but nobody gets upgraded, because Stripe is sending webhooks to a URL that no longer runs your code.

Why it happens

Lovable and Bolt hosting hide several jobs inside one Publish button. When you move, each of those jobs becomes yours.

• Routing. Older Lovable apps are React and Vite single-page apps. Every route is handled in the browser, so the host must serve index.html for any path. Lovable hosting does that for you. A plain static host does not.
• Build-time variables. In a Vite app, VITE_ variables are baked in when the app is built. If they are missing at build time, the code that reads them gets undefined, and the Supabase client throws the error above. Adding them afterwards does nothing until you rebuild.
• Server code. Lovable projects created from 13 May 2026 run on TanStack Start, which renders pages on the server. Lovable's docs say these need a host that runs server code; static file hosting is not enough.
• The backend stays behind. Moving the frontend does not move the database, login, file storage or server functions. Lovable's docs are explicit that AI features and connectors keep running through Lovable until you replace them. On Bolt, the database, login, storage and server functions live on Bolt Cloud.
• Redirect URLs and webhooks point at the old address. Your auth provider only redirects to URLs on its allow list, and Stripe only sends events to the endpoints you registered.

The fix

Work through these in order. Keep the old site running until the last step.

1. Decide what is moving

Most of the time, the right first move is the frontend only. Keep the database and auth where they are, and point the new host at them. Moving the backend is a separate project with its own risks, covered in step 7.

2. Get the code into GitHub

Use each tool's Git sync rather than a one-off download, so future changes deploy automatically. Lovable always creates a new repository when you connect, and syncs both ways. Bolt creates a private repository on main and commits changes that don't break the project. I go through the details in exporting and owning your AI-built code.

3. Deploy a newer Lovable app (TanStack Start)

Vercel's docs say Lovable projects deploy with zero configuration because they use TanStack Start and Nitro. Import the repository at vercel.com/new and Vercel detects the framework. One check first: zero-configuration detection needs @lovable.dev/vite-tanstack-config at ^2.6.2 or higher.

npm ls @lovable.dev/vite-tanstack-config
# if it is older than 2.6.2:
npm install @lovable.dev/vite-tanstack-config@^2.6.2

For a container or your own server instead, Lovable's docs give NITRO_PRESET=node-server npm run build, then node .output/server/index.mjs, listening on port 3000 unless you set PORT.

4. Deploy an older Lovable or Bolt Vite app

The build is npm run build with output in dist/. Then add the single-page app fallback for your host.

On Vercel, add vercel.json at the project root:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

On Netlify, add public/_redirects so Vite copies it into dist/:

/*  /index.html  200

Netlify's docs note this rule does not override files that exist, so images and scripts still load normally. That fixes the 404: NOT_FOUND on refresh.

5. Set every environment variable before the build

List what the code reads, then recreate each one on the new host. Lovable's docs name VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY for Vite apps, and SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY for TanStack Start apps, plus any secrets your server functions read. Vercel's guide for Bolt exports says values in Bolt's Secrets panel are not included in the export.

grep -rhoE "import\.meta\.env\.[A-Z0-9_]+|process\.env\.[A-Z0-9_]+" src | sort -u

Vercel's docs say variable changes only apply to new deployments, so redeploy after adding them. Anything prefixed VITE_ ends up in the browser bundle. Publishable keys belong there. Secret keys never do.

6. Update auth redirects, OAuth apps and webhooks

• In Supabase, add the new domain under Authentication, URL Configuration. Supabase's docs show a wildcard for Vercel preview URLs: https://*-your-team.vercel.app/**.
• If you use Google or GitHub sign-in through your own OAuth app, add the new domain there too.
• In Stripe, add a webhook endpoint for the new URL. It gets its own whsec_ signing secret, so update the variable on the new host. Keep the old endpoint until traffic has moved. Adding Stripe properly covers the webhook code itself.

7. Move the backend only if you need to

For Lovable, the supported backend destinations are managed Supabase and self-hosted Supabase. Lovable's guide says to restore the export and storage files, test with migrated accounts, search for remaining Lovable dependencies, then pause writes for the final copy. Its database export can only be taken once every 24 hours, so rehearse the timing.

If your data is already in a Supabase project you control, Supabase's backup and restore guide uses the CLI:

supabase db dump --remote="$OLD_DB_URL" -f roles.sql --role-only
supabase db dump --remote="$OLD_DB_URL" -f schema.sql
supabase db dump --remote="$OLD_DB_URL" -f data.sql --use-copy --data-only \
  -x "storage.buckets_vectors" -x "storage.vector_indexes"
 
psql --single-transaction --variable ON_ERROR_STOP=1 \
  --file roles.sql --file schema.sql \
  --command 'SET session_replication_role = replica' \
  --file data.sql --dbname "$NEW_DB_URL"

That covers the database only. Supabase lists what it leaves out: storage objects, Edge Functions, custom role passwords, migration history, and changes to the auth and storage schemas.

For Bolt, the documented route is Claim. Connect Bolt to your Supabase account, open the database, go to the Advanced tab and click Claim, then finish in Supabase. It needs a Pro or Teams Bolt plan, and you must be an owner of the Supabase organisation. Bolt's docs add that claiming into a Supabase organisation on the Free plan turns off leaked password protection, so plan for Supabase Pro if you rely on it.

8. Switch the domain, then retire the old host

Point your custom domain at the new host using its own DNS instructions. Bolt's docs say custom domains don't carry over between hosts automatically. Once traffic is flowing, unpublish on Lovable or Bolt. Lovable's lovable.app address keeps serving the last published version until you do, which is useful for rollback and confusing for users if you forget.

Download and check every export before deleting anything. Lovable's docs warn that removing the database deletes its exports and files permanently.

How to prevent it

• Keep one source of truth. If you still prompt in Lovable, its changes sync to GitHub and trigger Vercel deploys. That is fine, but a prompt can still undo a fix made in code.
• Keep a .env.example listing every variable, without values.
• Test deep links, sign-in, password reset and a test payment on the new domain before switching DNS.
• Write down every external URL that points at your app: auth redirects, OAuth apps, Stripe webhooks, email links.

Tool-specific notes are in taking a Lovable app to production and taking a Bolt app to production. The wider plan is in the prototype to product guide, and it is worth running the launch checklist once you have moved.

When to get help

Moving the frontend is a day's work if nothing surprising turns up. Moving the backend, with auth users, stored files and live payments, is where things go wrong quietly. If paying users depend on the app, plan it with someone who has done it.

That migration can be part of a Rescue Sprint. The free health check is a good first step if you are not sure what your app depends on.