Lovable app works in preview but breaks in production: 9 causes and fixes

Your Lovable app works perfectly in the editor preview. Then you publish it, open the live link, and something breaks: sign-in loops back to the login page, a page shows a 404 on refresh, data does not load, or your new domain shows an old version. This is one of the most common moments of panic for founders building with AI tools.

The reassuring part is that the causes are few and well known. Preview and production are different environments with different addresses, settings and caches, and most breakages come from one of those differences. Below are nine causes, roughly in the order we check them, with a fix for each.

First, collect three facts

Before changing anything, write down:

1. The exact live URL where it breaks (the lovable.app address, your custom domain, or another host). 2. What breaks: sign-in, a specific page, data loading, payments or emails. 3. What the browser says. Open the browser's developer tools, reload, and look at the Console and Network tabs for red errors. A failing request with a status code (401, 403, 404, 500) points straight at the cause.

Test in a private or incognito window too. Old cookies and cached files from earlier attempts can make a fixed problem look broken.

The nine causes

1. The project was not published again after your last change

Edits in the editor do not reach the live site until you publish. Lovable's publish docs describe the Publish button in the top-right corner of the project. If the preview shows a fix but the live site does not, publish again and recheck.

2. Sign-in fails because the live address is not an allowed redirect

This is the most common one. After a user signs in, the auth service sends them back to an allowed address. If your live domain is not on that list, the login silently fails or bounces.

• On Lovable's built-in backend, Lovable's custom domain docs say the domain is added to redirect URLs automatically once it is Live. If sign-in still fails, you can ask Lovable in the project chat to add it.
• On your own Supabase project, you add it yourself: set the Site URL and add every live address to the Redirect URLs list, as described in Supabase's redirect URL guide.
• With Google sign-in on your own credentials, the new domain's redirect URL also has to be added in Google Cloud Console.

3. The live app points at a different database

If your app talks to your own Supabase project, the live build needs the right project URL and public key. Lovable apps are built with Vite, and Vite only exposes variables that start with VITE_ to the browser, baking them in at build time (Vite env docs). If you move hosting, set those variables on the new host *before* building, using the exact names from your project's .env file, then redeploy.

A quick check: if the live app loads but shows no data, or different data from the preview, compare the Supabase project ID in its network requests with the one you expect.

4. Row Level Security blocks real users

In the editor you are often signed in as yourself, sometimes with data you created by hand. Real users hit the database through Row Level Security (RLS) policies. A policy that is missing or too strict shows up as empty lists or "permission denied" errors in production.

Lovable runs a quick scan of access rules when you open the Publish dialog. Treat its findings as a starting point, then sign up as a brand-new test user and walk through every screen. The opposite problem, policies that are too loose, is worse: it means anyone can read data they should not.

5. Routes return 404 when you refresh

Lovable apps use client-side routing, so a direct visit to a nested page such as /dashboard/settings needs the host to serve the main page and let the app handle the route. This is usually handled on Lovable's own hosting. If you moved to another host, add the host's single-page app rewrite rule. Netlify's guide to deploying a Lovable app shows the _redirects rule for that platform, and other hosts have an equivalent setting.

6. The custom domain never becomes Live

Lovable publishes to the lovable.app address until a custom domain is Live, and DNS changes can take up to 72 hours to propagate. If it stays stuck, check that your DNS records match exactly what Lovable expects under the project's domain settings, and use a public DNS lookup tool to confirm what the world sees.

7. SSL fails because of CAA records

If your domain has CAA records, they limit which certificate authorities may issue certificates for it. Lovable's docs list the authorities it uses (Google Trust Services, Let's Encrypt and SSL.com) and recommend allowing all three. A subdomain inherits CAA records from its parent domain unless it has its own, so check the parent too.

8. The domain shows the wrong site or an old version

Lovable's docs call out a specific cause: a leftover IPv6 (AAAA) record can route traffic somewhere else. Remove stale AAAA records from your DNS, then retry the domain. A browser or CDN cache can cause the same symptom, so test in incognito after the change.

9. Emails do not arrive in production

Sign-up confirmations and password resets depend on email sending. If your app uses your own Supabase project, its built-in email service is meant for testing, not real traffic. Supabase recommends setting up custom SMTP for production. Without it, new users can get stuck waiting for a confirmation that never comes.

A pre-launch checklist

Run this every time you publish something important:

• Publish, then open the live URL in an incognito window.
• Sign up as a brand-new user, confirm the email, sign out and sign back in.
• Visit two or three deep links directly and refresh them.
• Create, edit and delete one real record as that new user.
• Try to view another user's data by changing an ID in the URL. You should be refused.
• Check the browser console for errors on the main pages.
• Confirm the domain shows the latest version and a valid padlock.

When it is not a settings problem

If you have worked through all nine and things still break, the issue is usually in the app itself: an API key that only works from the editor, a server function that times out under real data, or logic that assumed a single user. That is the point where a code-level review saves time over more prompting.

Key takeaways

• Preview and production differ in address, settings and cache, and most breakages come from those differences.
• Auth redirect URLs and environment variables cause the majority of sign-in and data problems.
• RLS should be tested as a new user, not as yourself.
• DNS, SSL and stale records explain most custom-domain issues.

---

Still stuck between "works in preview" and "works for customers"? Our launch check is built for this moment. Book a free technical assessment, and we'll find what's breaking and tell you what to fix first.