Short answer: the frontend is easy. Sync your Lovable project to GitHub, import the repository into Vercel, and it deploys with no configuration for current Lovable projects (Vercel docs). The backend is the harder part. If your app uses Lovable Cloud, Lovable says there is "no one-click migration" to your own Supabase project. You export your data and rebuild the setup yourself (Lovable docs). This guide walks through both, and through the parts that usually break: environment variables, login redirects, files, secrets and the domain switch.
First: should you move at all?
Staying on Lovable hosting is fine for many apps. People usually move for one of these reasons:
- Ownership. You want the code, database and hosting in accounts that are legally yours, for investors, a buyer or peace of mind.
- Control. You need server settings, regions, logs, backups or integrations that Lovable's hosting doesn't give you.
- A developer is joining. They want a normal Git workflow, staging environments and pull requests.
- Cost at scale. Past a certain level of traffic or data, direct Vercel and Supabase billing can be easier to predict.
You don't have to stop using Lovable to do this. With two-way GitHub sync, you can keep editing in Lovable while the live app runs on Vercel, and every change you make in Lovable redeploys automatically.
Step 0: find out what you actually have
Open your project and answer three questions. Everything else depends on them.
- Is it a TanStack Start project or an older Vite project? New Lovable projects have used TanStack Start since 13 May 2026. Older ones are React + Vite single-page apps, and can be upgraded in place for roughly 10 to 35 credits (Lovable docs). The upgrade also gives you server-side rendering, which helps Google see your pages.
- Which backend does it use? Either Lovable Cloud (the built-in backend) or your own Supabase project that you connected. Check your project's Cloud or Integrations settings.
- Is it connected to GitHub? GitHub sync is available on every plan, including Free (Lovable docs).
If your backend is already your own Supabase project, you can skip Part 2.
Part 1: move the frontend to Vercel
1. Connect GitHub
In Lovable, connect the project to GitHub and let it create the repository. Create it under your own GitHub account or organisation, not a freelancer's. One Lovable project links to one repository. Changes in Lovable are pushed to GitHub, and commits pushed to the active branch sync back into Lovable (Lovable docs).
2. Check the build config
Vercel's zero-configuration detection needs @lovable.dev/vite-tanstack-config version ^2.6.2 or higher in your package.json (Vercel docs). If yours is older, update it (or ask Lovable to) before you deploy.
Older Vite projects: these deploy to Vercel as a static single-page app. Choose the Vite preset. You'll probably need a rewrite so that refreshing a page like /dashboard doesn't show a 404. Add a vercel.json with a rewrite sending all routes to /index.html. It works, but upgrading to TanStack Start first is usually the better long-term move.
3. Import into Vercel
Go to vercel.com/new, pick the repository and import it. Before you click Deploy, add your environment variables, which are the thing most people miss.
4. Copy environment variables
Your Lovable app reads settings like the Supabase URL and keys from environment variables. Vercel doesn't know them yet. Look in your code for names starting with VITE_ (for example VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY or ..._ANON_KEY) and add each one in Vercel under Settings → Environment Variables.
Two rules:
- Anything prefixed
VITE_ends up in the browser. Only public values belong there: the Supabase URL and the publishable/anon key. Never a service role key, secret key, Stripe secret or OpenAI key. - Secrets used by Supabase Edge Functions stay in Supabase (Edge Function secrets), not in Vercel.
Deploy. You now have a working copy at your-project.vercel.app, running against the same backend as before.
Part 2: move from Lovable Cloud to your own Supabase
Lovable Cloud is built on Supabase, but it is managed inside Lovable. Lovable's documented process is manual: "you export your Cloud data, connect a Supabase project to a new Lovable project, and rebuild the schema there" (Lovable docs).
What the export covers, and what it doesn't
Lovable Cloud has a data export in the project's Cloud settings. According to a detailed third-party guide from July 2026, the export includes your schema, data, RLS policies and users (with password hashes), is limited to 5 GB and one export per 24 hours, and does not include storage files, secret values, OAuth provider settings, scheduled jobs or active sessions (bworlds guide). Check what your own export contains before relying on this list, as Lovable changes quickly.
So plan to move these by hand:
| Item | How to move it |
|---|---|
| Database schema, data, RLS policies | Lovable Cloud export, restored into the new Supabase project |
| Users | Included in the export (per the guide above). Test a login with a real account after restoring |
| Storage files (uploads, images) | Download from Cloud storage, re-upload to buckets with the same names and privacy settings |
| Edge Functions | The code is in your GitHub repo. Deploy it to the new project with the Supabase CLI |
| Secrets (Stripe, OpenAI, email API keys) | Re-enter them as Edge Function secrets in the new project. Consider rotating them at the same time |
| Google/GitHub login (OAuth) | Re-create in the new project's Auth settings, and add the new callback URL in the Google/GitHub console |
| Scheduled jobs | Re-create them (for example with pg_cron) |
| Active sessions | Can't move. Users sign in again once |
Order of operations
- Create the Supabase project in your own account. Pick the region closest to your users. Lovable Cloud's region can't be changed, but your new project's region is your choice.
- Restore the schema and data from the export, then check that RLS is enabled on every table and the policies came across. This is the most important check in the whole move. See Is Lovable secure? for a quick test.
- Upload storage files and deploy Edge Functions.
- Re-enter secrets and OAuth settings.
- Point the app at the new project: update the Supabase URL and key in Vercel's environment variables. Use the new-style
sb_publishable_key, since Supabase is retiring the oldanonkey by the end of 2026 (our guide). - Test everything on the Vercel URL before you touch the domain: sign up, log in, reset password, upload, pay (in test mode), and every screen a user normally sees.
Plan a short freeze. Any sign-ups or data written to Lovable Cloud after your export won't be in the new database. For a small app, the simplest approach is a quiet-hours cut-over: export, restore, switch, and put up a short maintenance notice.