Lovable App Works in Preview but Not After Publishing

A Lovable app that works in preview but not after publishing is not unusual. Preview can hide deployment differences because it may use a different snapshot, different configuration, different redirects or a development path that the live site does not share.

Why preview and live versions can behave differently

Preview proves that one build can run inside the builder environment. It does not prove that the published build has the same variables, functions, domains, redirects, API access or cache state. Treat live as its own environment and test it directly.

Check whether the latest version was published

First confirm that the change you are testing actually reached the live app. Republish once, wait for the deployment to finish, then hard-refresh the live URL in a private browser window. If the live app still shows old behaviour, you may be dealing with a stale build or cached assets rather than a code issue.

Check environment variables and secrets

Preview may have access to variables that the live build does not. Missing Supabase keys, API URLs, function secrets or third-party tokens can produce failures that only appear after publishing. Check variable names carefully; one typo is enough to break production while preview seems fine.

Check Supabase site URLs and authentication redirects

Authentication often fails after publishing because the production domain is not listed in Supabase settings. Check Site URL, redirect URLs, OAuth callback URLs and password reset links. A preview URL and a live domain are not interchangeable.

Check deployed Edge Functions

If the app depends on Supabase Edge Functions, confirm the functions are deployed to the project used by the live app. Function-not-found, 404 and 500 errors usually point to deployment, environment or request handling problems. The dedicated Lovable Edge Function errors guide covers this in more detail.

Check live API domains and CORS settings

Third-party APIs may allow preview domains but reject production domains. Check CORS rules, allowed origins, API key restrictions and service dashboards. If a request is blocked before it reaches the API, the browser network tab will usually show it.

Check cached files and stale builds

A stale JavaScript bundle can make the live app behave as though your latest fix never happened. Test in a private window, clear local storage if authentication is involved and compare the live source assets where possible. Avoid repeatedly republishing without first confirming whether the live build is actually changing.

Check routing and deep links

Live hosting needs to route deep links back to the app. If the homepage works but direct URLs fail, the issue may be hosting rewrite configuration rather than Lovable logic. Test dashboard routes, account links, reset links and any URL sent by email.

Safe troubleshooting order

• Confirm the latest build is live.
• Check browser console and network errors on the live URL.
• Verify environment variables and secrets.
• Check Supabase redirects and function deployment.
• Test APIs, CORS and production domains.
• Only then change code.

When professional diagnosis is faster

If publishing the same project repeatedly creates different failures, stop and get a root-cause diagnosis. A live deployment issue can quickly become a launch problem, especially if customers are already trying to use the app. Start with technical diagnosis, then stabilise the code through AI code repair if the deployment exposed deeper problems.

Conclusion and soft CTA

Preview/live differences are usually fixable, but the repair depends on knowing which environment is lying to you. If the published version is blocking a launch or affecting real users, use emergency website fixes. If you are preparing the app for wider use, review how to make a Lovable app production ready and request Lovable app repair when the cause is unclear.

Why production URLs expose hidden assumptions

Preview environments are forgiving because they are designed for building. Production URLs are less forgiving because they depend on published assets, configured domains, deployed functions and live third-party rules. A feature can work in preview because the builder session has the right context, while the live app has to recreate that context from URL, storage, environment variables and deployed services.

This is especially important for authentication. A preview URL, temporary build URL and custom domain may all behave differently unless every redirect and callback is explicitly allowed. The same applies to APIs that restrict origins. If an external service only trusts one domain, the live app may fail even though the code is identical.

How to compare preview and live safely

Open preview in one browser window and the live app in a private window. Use the same test account where possible. Perform the same journey step by step and note the first difference. Do not keep clicking through after the first failure, because later errors may only be consequences of that earlier break.

Compare the network requests. Are they going to the same API domain? Do they include the same path? Is the live app missing a header or token? Is a function returning a different status? These comparisons are more useful than visual impressions because they show where the environments diverge.

Deployment checks that are easy to miss

Confirm the published app uses the intended Supabase project, not an older project or test project. Confirm the latest function version is deployed. Confirm any custom domain has finished DNS and SSL setup. Confirm the app is not loading an old bundle from cache. Confirm that environment variables are set in the deployment environment and not only in the builder or local notes.

Also check whether the live app is using absolute URLs that still point to preview, localhost or a temporary domain. AI-generated code may hard-code a URL during prototyping. That can remain invisible until the app is published and real users land on the production domain.

How failed launches usually present

A failed launch is not always a total outage. Sometimes the homepage loads, but signup fails. Sometimes existing users can log in, but password reset links use the wrong domain. Sometimes admin screens work, but public forms do not save. Sometimes desktop works, but mobile users cannot complete the final step.

That is why live validation should focus on the business-critical journeys, not just whether the first page loads. Test the path that creates value: enquiry, booking, purchase, signup, dashboard update, report generation or whatever the app exists to do. If that journey fails live, treat it as a production issue even if the rest of the interface looks polished.

What to avoid while troubleshooting live problems

Avoid repeatedly republishing without changing the diagnosis. Avoid changing environment variables without recording what changed. Avoid deleting and recreating Supabase settings unless you understand which URLs and keys are in use. Avoid asking for a full rewrite when the failure may be one missing redirect or function secret.

A good live repair preserves working behaviour. If the app is partly functioning, protect that functioning path while investigating the broken one. Keep notes, test one change at a time, and use rollback if a repair makes the live app worse.

Example live failure walkthrough

Suppose the preview app lets users sign up, but the live app sends them back to the homepage after email confirmation. The likely problem is not the visual page. It is more likely an authentication redirect, Site URL, callback URL or route handling issue. Check the confirmation link destination. Does it point to the preview domain, the live domain, or an old temporary URL? Then check whether the live route can process the token.

Suppose a dashboard loads in preview but shows an empty state live. Compare the Supabase project and environment variables used by each environment. The live app may be connected to a different project, or row-level security may allow the preview account but not the live test account. Check the network request and the table policies before changing the dashboard UI.

Suppose an API-powered feature works in preview but returns a CORS error live. The API may not allow the production origin. The repair is not to hide the error or move the feature elsewhere. The repair is to configure the allowed origin, route the request through a secure function if needed, and test the production domain again.

What a stable publishing process looks like

A stable publishing process has a checklist. Confirm the change in preview. Publish once. Confirm the build finished. Test the live URL in a private window. Test the main user journey. Check the console and network tab. If anything fails, record the failure before changing code. This discipline matters because live issues are often environment issues, and environment issues are easy to obscure with unnecessary code edits.

For a business launch, test more than the homepage. Test signup, password reset, form submission, any payment or booking step, mobile navigation, and the confirmation state. If the project has a dashboard, test a direct dashboard link after login and after refresh. If the project uses email links, test them from a real inbox on the live domain.

Do not make publishing the only quality gate. Preview is useful, but production-readiness also needs configured services, secure data access, tested user journeys and a rollback plan. If your app will be used by customers, treat preview as a draft and live as a separate environment that must earn trust.

Questions to answer before changing code

Before editing the app, answer a few deployment questions. Which exact URL did you test? Was it preview, the default published URL or a custom domain? When was the last successful publish? Did the failure start after a domain change, Supabase change, API key change, OAuth setup or function deployment? These questions often reveal that the code is not the first suspect.

Next, list every outside service involved in the failing journey. A login journey may involve Supabase Auth, an OAuth provider, browser storage and route guards. A form journey may involve a frontend component, Supabase table, Edge Function and email provider. A payment journey may involve a payment API, webhook and database update. Live failures often happen at the boundaries between those services.

Finally, decide what proof would show the issue is fixed. “It works now” is too vague for production. Better proof is specific: a new user can sign up on the live domain, confirm their email, log in after refresh, submit the form, and see the saved result on mobile and desktop. That proof gives you confidence that the live app is actually repaired, not just quieter.

What to include in a handover note

If you ask for help, send a short handover note that covers the live URL, preview URL, when the issue started, the last successful publish, the exact failing journey, browser console errors, network status codes, Supabase project involved, functions involved and any recent domain or redirect changes. This saves time because the repair can begin at the likely boundary between preview and live rather than re-discovering the whole project history.

Include what still works. If the homepage loads, login works but reset fails, or desktop works but mobile does not, say so. Knowing the working area protects it during repair. The aim is to stabilise the live app, not to disturb functioning parts while searching for the failure.