Lovable to Production: How to Ship a Vibe-Coded App Safely

“I built it in Lovable. It just needs a few finishing touches.” We hear that a lot, and it’s half right. The app works, and the product thinking behind it is real work. What’s left is what the preview doesn’t show until you deploy a Lovable app to production: who can see whose data, what happens with real traffic, and, in healthcare or finance, whether the app can hold that data at all.

This guide is for founders who put real time into a Lovable build and now need it to hold up with real users, payments or regulated data. You’ll learn how to host it, who owns the code, how to lock down the data, and what changes when that data is health or financial.

Two ways to deploy a Lovable app to production

The fastest route is Lovable’s own Publish button:

1. Click Publish in the top-right corner of the editor. Your app goes live at yourname.lovable.app on any plan, including Free (Lovable docs).
2. To use your own domain, add a custom domain. It needs a paid plan, from $25/month on Pro.

For an MVP or an internal tool, that’s often all you need.

Move to your own hosting when you need preview deployments, your own logs or a compliance setup:

1. Connect GitHub. Lovable creates a new repo and syncs both ways on one branch, usually main.
2. Point Lovable at a development branch. If your host auto-deploys main, every prompt ships straight to production.
3. Merge into main through pull requests.

Check which kind of Lovable app you have

Lovable changed its default stack this year, and most tutorials haven’t caught up. Projects created from May 13, 2026 are server-rendered TanStack Start apps. Older ones are React + Vite single-page apps. To check yours:

1. Open package.json in your repo.
2. If it lists TanStack Start, you have the newer setup. If not, you have an older React + Vite app.

Newer apps deploy to Vercel with zero configuration, or to any Node host with the commands above (Lovable hosting guide).

Older apps need a rewrite rule, or every page except the homepage returns a 404 when someone refreshes it or opens a shared link:

• Netlify: add this line to public/_redirects: /* /index.html 200
• Vercel: add a vercel.json file to the repo root:

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

Make sure you own the code

You own the code Lovable generates. Its terms say so directly. They also give Lovable a worldwide, perpetual license to use and process your project data, including to train AI models, and opting out of training only applies going forward. If that matters to you, decide early.

Either way:

• Keep the code in a GitHub repo you control, so you can change hosts or bring in other developers.
• Check who can see the project. Lovable removed public projects in April 2026, projects now default to workspace access, and limiting one to invited people needs a Business or Enterprise plan.

Know which keys the browser can see

Lovable apps read VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY from environment variables. Vite bundles anything that starts with VITE_ into the JavaScript it sends to the browser (Vite docs), so anyone can read it in dev tools. Putting a value in an environment variable doesn’t make it private.

That’s fine for the Supabase publishable key (sb_publishable_, the old anon key). It’s designed to be public, as long as Row Level Security is on. The secret key (sb_secret_, the old service_role key) skips every access rule and must never reach the frontend (Supabase docs). The same goes for Stripe secret keys and AI API keys: keep them in Supabase edge function secrets.

Turn on Supabase Row Level Security, then test it

This is the one that has burned real apps. In 2025, security researcher Matt Palmer scanned 1,645 Lovable-built apps and found 303 exposed endpoints across 170 of them, about 10%. Anyone could read or write user records, API keys and payment records, because the tables had no working Row Level Security. It was logged as CVE-2025-48757.

Lovable now runs a security scan when you open the publish dialog, flagging tables without Row Level Security and vulnerable packages. Use it, but it doesn’t block publishing by default, and it can’t tell whether your rules match how your app should work.

For that, run the two-user test:

1. Create two accounts.
2. As User A, create something private, like a project or a booking.
3. Log in as User B and try to view, edit or delete it, both through the app and by replaying a request from the browser’s network tab with User A’s record ID.
4. Check file storage and admin features the same way.

If any of it works, your policies are wrong, however the UI looks.

Fix the Supabase defaults that break launches

If you brought your own Supabase project, three defaults catch people out:

• Email. The built-in service sends 2 emails an hour, and only to your team’s addresses, so real users never get their confirmation emails. Set up custom SMTP (Resend, Postmark or Amazon SES) before launch.
• Redirect URLs. Under Authentication, then URL Configuration, set the Site URL to your real domain and add it to the redirect list, or confirmation and password-reset links send users back to the preview or localhost. Do the same in Google or any other sign-in provider.
• Backups. Free projects have no backups and pause after a week of inactivity. Pro includes daily backups kept for 7 days, and point-in-time recovery is an add-on from $100/month. If the app holds customer data, Free isn’t a production plan.

If your app handles health or financial data

This is where a lot of Lovable builds hit a wall. Lovable’s terms say not to put HIPAA-covered health information into the service, along with payment card data, financial account numbers and government IDs, unless your plan or a separate written agreement allows it. If your app runs on Lovable Cloud, that backend is part of the service.

For health data, every vendor that touches it needs to sign a business associate agreement (BAA):

• Supabase: HIPAA is a paid add-on on the Team and Enterprise plans, with a signed BAA. HIPAA projects also need point-in-time recovery, SSL enforcement and network restrictions turned on (Supabase HIPAA docs).
• Vercel: Pro teams can sign a BAA as a paid add-on (Vercel changelog).
• Everything else: email, analytics, error tracking and AI APIs. Keep patient details out of logs and analytics events entirely.

For payments, let Stripe or a similar provider collect card details, so card numbers never touch your database. And a BAA is the paperwork, not the protection. You still need a record of who accessed what, tested access rules and a clear answer on where the data lives. Confirm what applies to you with your compliance lead or a healthcare attorney.

Test on production before you announce it

A successful deploy only proves the app starts. Before launch:

1. On the production domain, with a fresh account and on your phone, run the main journey end to end.
2. Refresh inner pages, submit a form twice, and make a small real payment you then refund.
3. Break things on purpose: what does the user see when an API call fails, the session expires or a card is declined?
4. Set up error tracking (Sentry or similar) and an uptime check on an API route rather than just the homepage.
5. Write down a rollback plan. Rolling back code doesn’t roll back the database, so take a backup before any release that changes the schema.

The short checklist

• Row Level Security on every table, scan findings fixed, and the two-user test passes
• No secret keys in frontend code or VITE_ variables
• Code in a GitHub repo you control
• Custom SMTP, and Site URL and redirects on the production domain
• A Supabase plan with backups, and BAAs in place for any health data
• Error tracking, uptime checks and a rollback plan in place

How we take Lovable apps to production

Once an app holds customer data, takes payments or runs a workflow the business depends on, the harder question is what you’ve missed.

A healthcare founder came to us with an MVP built in Lovable. They weren’t a developer, but they’d thought through every screen and flow. The app was already live, but it wasn’t locked down, so that’s where our first call started: what to lock down that day, before any talk of a project. The Lovable build then became the starting point for the production app.

Nothing you build is wasted. Depending on the audit, we harden what’s there or use your Lovable app as the spec for the production build, so your screens, flows and decisions carry straight over. Our From Vibe to MVP work runs in three steps:

1. Audit. We review architecture, security and scalability: access rules, secrets, auth and AI risks like prompt injection. You get findings ranked by severity and a roadmap, and the audit is yours to keep.
2. Build. We harden your app or build the production version from it. Design comes back as working screens with real data, not mockups. The work runs through our AI Factory: agents build, humans review, and automated testing catches what humans miss.
3. Launch. You see progress from the work itself, not status decks, and test real builds as they land. At launch the code is in your own repo, monitoring is on, and the team stays through real traffic.

FAQ

Can Rocket Farm Studios take my Lovable app to production?

Yes. We work with apps built in Lovable, Replit, Bolt, Cursor and v0. Most start with an audit. From there we either harden what you built or use it as the spec for the production build, so nothing you’ve built is wasted.

Can I put patient data in a Lovable app?

Not on Lovable’s standard terms, which say not to submit HIPAA-covered health information unless your plan or a separate agreement allows it. For production, keep that data with vendors that sign a BAA, such as Supabase with its HIPAA add-on, and keep it out of logs and analytics.

How do I deploy a Lovable app to Vercel?

1. Connect the project to GitHub.
2. Import the repo in Vercel. TanStack Start projects, the default since May 2026, deploy with no extra setup.
3. For older Vite projects, add a rewrite rule in vercel.json so inner pages don’t return 404s.

Is Lovable’s security scan enough?

It’s a good first pass that catches missing Row Level Security and vulnerable packages. It doesn’t test your app’s logic, so run the two-user test as well.

Written by

Daniel Rondeau