How to Deploy a Lovable App to Production

Lovable is one of the fastest ways to go from an idea to a working web app. Describe it, iterate in chat, and you have something real in an afternoon. Then comes the question every Lovable builder eventually asks: is this actually live, and is it ready for real users?

The answer depends on which of three paths you take — and on a security check that has caught out a lot of Lovable apps. Let's go through both.

Lovable changes quickly. Details here reflect the product as of September 2026; check Lovable's deployment docs for the current specifics.

What a Lovable app actually is

Under the chat interface, a Lovable project is ordinary code: typically a React frontend built with Vite, TypeScript, and Tailwind. The backend — database, authentication, file storage — is usually Supabase, either through Lovable Cloud or a Supabase project you connect yourself.

That matters because it means your app isn't locked inside Lovable. It's a standard frontend plus a standard Postgres-backed backend, and both can live elsewhere.

Path 1: Publish inside Lovable

The simplest path. Click Publish, and Lovable hosts your app at a Lovable subdomain. On paid plans you can connect a custom domain.

Good for: prototypes, internal tools, early validation, anything where speed matters more than control.

Watch for: your hosting, your builder, and often your backend are all the same vendor. That's convenient until you want something the platform doesn't do, or the pricing changes.

Path 2: Sync to GitHub and deploy the frontend elsewhere

Lovable can sync your project continuously to a GitHub repository. Once it's there, any static host can build and serve it:

Connect the Lovable project to GitHub.
Import the repository into Vercel, Netlify, or Cloudflare Pages.
Set the build command (usually npm run build) and output directory (usually dist).
Copy the environment variables your app uses — typically VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY — into the host's settings.
Deploy, then point your domain at the new host.

Your Supabase backend stays exactly where it was. Only the frontend moved.

Good for: people who want a mainstream host, preview deployments per branch, and freedom to keep editing in Lovable while deploying from GitHub.

Path 3: Move the whole thing onto infrastructure you control

When the app outgrows a frontend plus Supabase — you need a real backend server, background jobs, scheduled tasks, or a database you run yourself — you move the whole application. That means a host that runs server processes (not just static files), a managed Postgres, and migrating your data out of Supabase.

Good for: apps that have become products, and teams that want to keep developing with AI agents against the real running app rather than inside a builder.

Cost of the move: you're now responsible for, or paying someone to handle, the backend, database, backups, and SSL. We lay out the full list in You Built an App With AI. Now What?.

The security check you must do before launch

Here's the part that matters more than which path you pick.

In 2025 a security researcher found that a significant share of the Lovable apps he sampled — around 170 out of roughly 1,600 — exposed their users' data to anyone who asked. The issue was tracked as CVE-2025-48757. The cause wasn't exotic: Supabase row-level security (RLS) wasn't configured, or was configured too loosely.

To understand why that's so dangerous, you need one fact about how these apps work:

The Supabase key in your frontend is public. Anyone can open your site, view the source, and copy it. That's by design — the "anon" key is meant to be public. What stops someone using it to read your entire users table is RLS: database rules that say "a user can only read their own rows."

No RLS, and the public key is a skeleton key.

Before real users arrive, check:

RLS is enabled on every table in Supabase. Not most tables — every one.
Every table has policies that restrict reads and writes to the rows a user should see. A table with RLS on and a policy of true is as open as RLS off.
Test it as a stranger. Sign in as a second test user and try to read the first user's data. Then try with no login at all.
The service-role key is nowhere in the frontend. That key bypasses RLS entirely. It belongs only in server-side code.
Storage buckets have policies too, if you store uploads.

Lovable has added security scanning since the incident, and it's worth running — but check the policies yourself. It's your users' data. We have a broader list in A Security Checklist for Vibe-Coded Apps.

The rest of the production checklist

Custom domain connected, with HTTPS working. (If DNS is new to you: How to Connect a Custom Domain to Your App.)
Backups. Know how your database is backed up and how to restore it. Check what your Supabase plan actually includes.
Email. Supabase's built-in auth email is fine for testing but rate-limited; connect a real email provider before launch.
Payments, if any, in live mode with webhooks pointed at the production URL — and tested with a real card.
Error visibility. Some way to know when something breaks that doesn't depend on a user emailing you.
Code in GitHub. Whatever path you chose, sync to GitHub. It's your undo button and your exit.

Which path should you choose?

Still validating the idea? Publish in Lovable. Don't optimise hosting for an app nobody's used yet.
Have real users and want a mainstream setup? Sync to GitHub and deploy the frontend to a static host.
Need a real backend, or want to keep building with AI against the live app? Move to infrastructure that runs the whole application.

Whichever you pick, do the RLS check first. It's the one mistake that can't be undone after launch.

EasySpawn is where an AI-built app can live once it's outgrown the builder: managed Postgres with daily backups, automatic SSL, your own domain connected, and Claude Code working against the running app. See how it works for AI-built apps or join the waitlist.