MMakerToLaunch

Launch

How to Launch an App Built With Lovable

Lovable.dev turns prompts into polished React apps — often with Supabase auth, databases, and storage wired in before you write a line of code yourself. The in-app preview URL is perfect for iterating, but production launch means owning your code on GitHub, separating dev and production backends, and deploying a frontend host like Vercel with the right environment variables. This guide covers the full Lovable-to-production path, including auth callback URLs and the Supabase mistakes that break apps after deploy.

Updated July 2026 · 12 min read

Written for AI makers using tools like Cursor, Bolt, Lovable, Replit, Claude, and ChatGPT.

Quick answer

Lovable's preview runs on Lovable infrastructure with dev Supabase keys — it is not production. Sync your project to GitHub, create a production Supabase project (or promote carefully), deploy the React/Vite frontend to Vercel with VITE_ env vars, configure auth redirect URLs in Supabase, and run a readiness scan before sharing your live URL.

Best for

Lovable.dev React apps with Supabase auth, database, or storage

What the tool gives you

A polished preview app — often with auth and data wired in

What still needs launching

GitHub sync, production Supabase, Vercel deploy, auth redirects

Main risk

Using Lovable preview + dev Supabase as if it were production

Who this is for

  • You built a Lovable app with login, database, or storage and want real users on your own URL
  • Your Lovable preview works but Vercel shows auth errors or empty data after deploy
  • You connected Supabase in Lovable and are unsure which keys belong in production

What you'll need

  • A Lovable.dev project with GitHub sync enabled (or ready to export)
  • A GitHub account and a Vercel account for frontend hosting
  • A Supabase account — ideally a separate production project from Lovable's dev instance
  • Fifteen to forty-five minutes to configure env vars and auth redirects

Key concept

Lovable preview vs production launch

Every Lovable project gets a preview URL on Lovable's infrastructure. You can share it for feedback, and it feels like a live app because it is — but it runs on Lovable's stack with development-grade configuration.

Production launch means three things change: you control the frontend host (usually Vercel), you point the app at a production Supabase project with its own keys and Row Level Security policies, and you configure auth redirect URLs for your real domain instead of Lovable's preview origin.

Lovable preview often uses Supabase's anon key in client code — that is normal for Supabase. The problem is using Lovable's linked dev project for real user data, or forgetting to update redirect URLs when the domain changes.

Treat Lovable preview as staging. When you are ready for beta users or a custom domain, follow the GitHub → Vercel → production Supabase path below.

  • Preview = Lovable hosting + often a shared/dev Supabase project
  • Production = your Vercel URL + production Supabase + updated auth redirects
  • Anon keys in the client are normal — service role keys are never safe in Vite

Deploy settings

Sync Lovable to GitHub

Lovable supports GitHub integration — use it. Connect your GitHub account in Lovable settings, link your project to a repository, and let Lovable push code on each publish or sync.

After the first sync, open the repo on github.com. Confirm you see a standard React/Vite structure: src/, package.json, vite.config.ts, and often a supabase/ folder or lib/supabase client file.

Before deploying, verify .gitignore excludes .env.local and .env. Lovable may generate env files during development. If any file with SUPABASE_SERVICE_ROLE_KEY or similar appears in the repo, remove it, rotate the key in Supabase, and add the filename to .gitignore.

If GitHub sync is unavailable, export or clone through Lovable's download option and upload via GitHub Desktop. The goal is the same: a clean repo on GitHub that Vercel can build.

  • Connect GitHub in Lovable and sync/publish
  • Confirm React/Vite structure on github.com
  • No .env or service-role keys in the repo
  • Zip + GitHub Desktop works if sync is unavailable

Watch out

Set up Supabase for production

Most Lovable apps use Supabase for authentication, PostgreSQL database, and file storage. Lovable typically connects a Supabase project during building — often a shared or development instance.

For production, create a new Supabase project (or carefully audit your existing one). Copy the schema: tables, RLS policies, and storage buckets. Lovable generates migrations in some projects — check the supabase/migrations folder.

You need two Supabase keys in production: the project URL and the anon (public) key for client-side use. The service role key bypasses Row Level Security — never put it in frontend code or commit it to GitHub. It belongs only in secure server environments if you add a backend later.

Enable Row Level Security on every table with user data. Lovable sometimes creates tables without RLS enabled. In production, missing RLS means anyone with your anon key could read or write data they should not access.

  • VITE_SUPABASE_URL — your production project URL
  • VITE_SUPABASE_ANON_KEY — public anon key (safe in client with RLS enabled)
  • Never expose SUPABASE_SERVICE_ROLE_KEY in the Vite frontend bundle
  • Run migrations against production Supabase before switching traffic

Deploy settings

Deploy the frontend on Vercel

Lovable generates React + Vite + Tailwind apps in most cases. Vercel detects Vite automatically: build command npm run build, output directory dist.

Connect your GitHub repo in Vercel. Before the first deploy, open Project Settings → Environment Variables and add VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY with your production Supabase values. Vite only exposes variables prefixed with VITE_ to the browser.

If Lovable added other integrations — Stripe, OpenAI, Resend — add those as VITE_ vars only if they are meant to be public. Secret keys belong in Supabase Edge Functions or a separate backend, not in the React bundle.

Deploy and wait for the build. Open the *.vercel.app URL in incognito. If you see a blank page, check the browser console for 'Supabase URL is undefined' — that means env vars were missing at build time.

  • Build: npm run build · Output: dist
  • Add VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY before first deploy
  • Secrets stay off VITE_ — use Edge Functions or a backend
  • Blank page? Check console for undefined Supabase URL

Watch out

Configure auth flows for your live domain

Supabase Auth is the most common Lovable launch failure. Auth works in Lovable preview because redirect URLs include Lovable's domain. Your Vercel URL is different.

In Supabase Dashboard → Authentication → URL Configuration, set Site URL to your production frontend URL (https://your-app.vercel.app). Add the same URL plus /auth/callback or whatever path Lovable generated to Redirect URLs.

If you use Google, GitHub, or magic-link login, update OAuth provider settings too. Google Cloud Console needs your production domain in Authorized JavaScript origins and redirect URIs.

Test the full flow in incognito: sign up, confirm email if enabled, log out, log back in. Auth bugs discovered after marketing launch are painful — catch them here.

  • Supabase Site URL → your Vercel domain
  • Add Redirect URLs for /auth/callback (or Lovable's path)
  • Update Google/GitHub OAuth origins for production
  • Test signup → logout → login in incognito

Key concept

Environment variables and API keys

Lovable preview injects configuration so features work immediately. Production requires you to replicate that configuration on Vercel with explicit env vars.

Document every variable in .env.example with placeholder values. This file goes to GitHub; real values go only in Vercel's dashboard.

Understand which keys are safe in the browser. Supabase anon key is designed for client use when RLS protects your data. Stripe secret keys, OpenAI keys, and service role keys are never safe in client code — if Lovable put them in a React component, refactor before launch.

Redeploy after every env change. Vercel bakes VITE_ variables in at build time, so a restart alone is not enough — trigger a new deployment.

  • .env.example on GitHub — real values only on Vercel
  • Anon key OK in client with RLS; service role never in Vite
  • Redeploy after every VITE_ change

Watch out

Lovable-specific issues after deploy

These failures show up repeatedly when moving Lovable projects from preview to Vercel + production Supabase.

  • Login redirects to Lovable preview URL → Supabase Site URL and Redirect URLs still point to lovable.app
  • Data loads in preview, empty in production → app still points at dev Supabase project or wrong VITE_ vars
  • RLS policy violation errors → policies reference auth.uid() but user session not established; check auth flow first
  • CORS or fetch errors on storage uploads → Supabase storage bucket policies not copied to production project
  • Build fails on Vercel → Node version mismatch; pin engines in package.json if needed
  • Stripe checkout works in preview only → webhook URL and secret key configured for Lovable domain, not Vercel
  • Infinite loading spinner → missing env var causes Supabase client to initialize as undefined

After your Lovable app is live

Keep developing in Lovable if the workflow suits you — sync changes to GitHub and let Vercel redeploy. Alternatively, clone the repo locally in Cursor and edit directly; many makers switch once the app stabilizes.

When you add a custom domain in Vercel, update Supabase auth URLs and any OAuth provider settings again. Stale redirect URLs are the top post-launch auth break.

Monitor Supabase usage on the free tier — auth MAU, database size, and storage limits can surprise you after real users arrive. Upgrade or optimize before you hit hard limits.

Lovable preview vs exported / deployed app

CriteriaLovable previewExported + deployed
Where it runsLovable infrastructureYour host (usually Vercel)
Code ownershipInside Lovable projectYour GitHub repository
BackendOften shared/dev SupabaseProduction Supabase you control
Auth redirectsLovable domain preconfiguredYou set Site URL + Redirect URLs
Best useIterate and get feedbackReal users, custom domain, control

Step-by-step

  1. 1

    Step 1

    Sync Lovable to GitHub

    Connect GitHub in Lovable and publish. Verify no secret keys or .env files are committed to the repository.

  2. 2

    Step 2

    Prepare production Supabase

    Create or configure a production Supabase project. Run migrations, enable RLS, and copy URL + anon key.

  3. 3

    Step 3

    Deploy frontend on Vercel

    Connect the GitHub repo to Vercel. Add VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY before the first build.

  4. 4

    Step 4

    Configure auth redirects

    Update Supabase Site URL and Redirect URLs to your Vercel domain. Update OAuth providers if used.

  5. 5

    Step 5

    Scan, test, and go live

    Run a readiness scan, then test signup/login and core data flows in incognito on the production URL.

Common mistakes

  • Using Lovable's dev Supabase project for real user data

    What happens: Preview and production share messy data — or production suddenly goes empty when preview config changes.

    How to fix it: Create a dedicated production Supabase project with RLS enabled and production keys on Vercel.

  • Forgetting to update auth redirect URLs after deploy

    What happens: Login sends users back to the Lovable preview URL, or auth callbacks fail on Vercel.

    How to fix it: Set Supabase Site URL and Redirect URLs to your Vercel domain — not the Lovable preview URL.

  • Putting VITE_ prefix on secret keys to 'make them work'

    What happens: Secrets ship in the browser bundle — anyone can copy them from DevTools.

    How to fix it: VITE_ vars are public in the browser bundle. Only use VITE_ for Supabase anon key and other client-safe values.

  • Deploying without env vars and debugging a blank page for hours

    What happens: The site loads blank or spins forever because Supabase URL/key is undefined at build time.

    How to fix it: Add all VITE_ variables in Vercel before the first deploy. Rebuild after any change.

  • Skipping Row Level Security on Supabase tables

    What happens: Anyone with your anon key can read or write other users' rows.

    How to fix it: Enable RLS on every table with user data. Test that User A cannot read User B's rows.

Copy-ready prompt

Prompt: prepare Lovable export for production

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready to paste

This React/Vite app was built in Lovable.dev with Supabase. I synced (or exported) it to GitHub and I am deploying to Vercel with a production Supabase project.

1. List every environment variable needed. Update .env.example with VITE_ prefixes where appropriate.
2. Confirm no secret keys (service role, Stripe secret, OpenAI) are in client-side code.
3. Tell me the exact Supabase auth redirect URLs to configure for https://my-app.vercel.app.
4. Check Row Level Security: are all user-data tables protected?
5. Identify anything still pointing at Lovable preview URLs or localhost.
6. Give me the Vercel build command and output directory from package.json.

Do not include real API keys in committed files.

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready check

Before you launch

Work through these checks before you connect a host.

  • Lovable project synced to GitHub — no secrets in repo
  • Production Supabase project created with migrations applied
  • RLS enabled on all tables containing user data
  • Vercel connected to GitHub repo
  • VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY set on Vercel
  • Supabase auth Site URL and Redirect URLs updated for Vercel domain
  • OAuth providers updated if using Google/GitHub login
  • Launch readiness scan completed
  • Signup, login, and core data flows tested on live URL

Frequently asked questions

Is Lovable's preview URL enough for beta testing?
It works for quick feedback with trusted testers. Production launch on your own domain gives you control over Supabase, auth, and scaling.
Do I need a separate Supabase project for production?
Yes, for anything beyond casual testing. Lovable's linked dev project may share data with preview builds. A dedicated production project isolates real user data and lets you configure RLS properly.
Why does auth redirect to Lovable after I deployed to Vercel?
Supabase Site URL and Redirect URLs still point at the Lovable preview domain. Update them in Supabase Dashboard → Authentication → URL Configuration to your Vercel URL.
Can I deploy Lovable apps somewhere other than Vercel?
Yes. Netlify and Cloudflare Pages also support Vite/React builds. The same VITE_ env vars and Supabase auth URL updates apply regardless of host.
How do I update my live app after making changes in Lovable?
Publish or sync from Lovable to GitHub. Vercel rebuilds automatically on push. Verify the deploy succeeded before telling users to refresh.

Related reading