Skip to content
PixelRidge
← All guides

27 September 2026 · 7 min read

How to self-host your Lovable app on your own Vercel and Supabase (2026 guide)

Move a Lovable app onto hosting and a database in your own name: GitHub sync, Vercel deploy, the Lovable Cloud to Supabase move, auth redirects and the domain switch, plus the steps most guides skip.

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.

  1. 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.
  2. 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.
  3. 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

  1. 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.
  2. 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.
  3. Upload storage files and deploy Edge Functions.
  4. Re-enter secrets and OAuth settings.
  5. 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 old anon key by the end of 2026 (our guide).
  6. 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.

Part 3: fix login redirects

This step breaks more migrations than any other. In your Supabase project (the new one, or your existing one if you skipped Part 2) go to Authentication → URL Configuration:

  • Set the Site URL to your real domain, for example https://app.yourdomain.com.
  • Add your Vercel preview and production URLs to Redirect URLs.

If you skip this, password-reset and magic-link emails will send people back to the old Lovable address, and Google login will fail with a redirect error.

Part 4: switch the domain

  1. In Vercel, add your domain under Settings → Domains. Vercel shows the DNS records you need.
  2. At your domain registrar, update the records. If the domain was connected to Lovable, remove the old Lovable records at the same time.
  3. Wait for DNS to update. Often minutes, occasionally a few hours. Vercel issues the HTTPS certificate automatically.
  4. If your app had public pages indexed by Google on a different address (like yourapp.lovable.app), keep that address online for a while or redirect it, and submit your sitemap in Google Search Console for the new domain.

Part 5: after the move

  • Keep editing in Lovable if you like. GitHub sync keeps working, and Vercel redeploys on each change. Tell anyone else committing to the repo to use the active branch.
  • Turn on backups. Check which backups your Supabase plan includes and decide if you need more.
  • Add monitoring. At minimum, an uptime check and error tracking, so you hear about problems before your users do.
  • Write down where everything lives: GitHub, Vercel, Supabase, domain registrar, Stripe, email provider. Put every account in the business's name with two people able to log in.

How long does it take?

For a small app on your own Supabase project already, moving the frontend and domain takes a couple of hours. Moving off Lovable Cloud takes longer, typically a day or two of careful work for a small app, most of it testing. It takes more if you have lots of stored files, OAuth logins or scheduled jobs.


Want it done for you? Our Rescue & Migration service moves Lovable, Bolt and Replit apps onto accounts in your name, at a fixed price agreed in writing. We check your database rules on the way and hand over a document listing where everything lives. Tell us about your app.

Based on Lovable, Vercel and Supabase documentation as of September 2026. These platforms change often. If a step doesn't match what you see, the official docs linked above win.

Rather get it by email?

Leave your name and email, plus your app link if you like. We reply with a free Launch Check, no obligation.

We email you about this request only, and you can reply “unsubscribe” at any time. Prefer email? Write to info@pixelridgeweb.com. See our privacy notice.

Need it fixed for you? Lovable app fix and security audit.

Want a second pair of eyes on your app?

Send us your live link. We record a short video showing the top risks we can see, free and with no obligation.

Terms and conditions apply. Read the terms.