Sign in Get started
← Blog

Lovable Preview Works but the Published Site Is Broken

By Yoni Ryabinski

When your lovable preview works but published site broken errors appear on your custom domain, the root cause is almost often an environment mismatch between Lovable's preview sandbox and your live production build. In preview mode, your app runs inside an authenticated, origin-tolerant container with mock or inherited credentials, but your published site runs as a standalone static bundle under an entirely distinct origin.

For non-technical founders and vibe-coders who build fast with natural language prompts, this discrepancy can feel like a phantom bug. You test every button inside the Lovable canvas, click publish with total confidence, and immediately discover a blank white screen, failing login buttons, or missing data on your actual domain. You do not need to rewrite your application to solve this; you simply need to verify the four connection points that decouple during the publishing step.

Why Lovable Previews Differ from Published Builds

To fix the issue permanently, it helps to understand what happens under the hood when Lovable switches from editor preview to live deployment. The Lovable editor does not merely show a replica of your site; it runs your app inside a managed web container. This container injects runtime configuration, manages local state, and often runs under an internal origin like *.lovable.app or *.lovableproject.com.

When you hit "Publish", Lovable triggers a complete production build. This build compiles your React or Vite frontend code into static assets (minified JavaScript, CSS, and HTML) and serves them from a content delivery network (CDN) to your live URL. This separation introduces four structural differences:

  • Distinct Web Origins: Your preview URL lives at a sub-domain managed by Lovable, while your published site serves from your custom apex domain or subdomain (such as app.yourdomain.com). Browsers enforce security boundaries based on origins.
  • Environment Variable Injection: Variables bundled at build time (like VITE_SUPABASE_URL and public keys) must be explicitly present in the production deployment settings, not just in local preview session memory.
  • Third-Party Allow-Lists: External APIs, database providers (such as Supabase), and OAuth identity providers (such as Google or GitHub) authenticate incoming requests based on pre-registered domain lists. If your live domain is missing, requests are denied immediately.
  • CDN Edge Caching: Browsers and edge networks cache published JavaScript files aggressively. If a new deployment references old script hashes or missing assets, clients will load broken code.

If you find yourself frequently troubleshooting production deploy bugs across generated codebases, see our comprehensive walkthrough on how to troubleshoot a broken Lovable app for platform-specific diagnostics.

The Usual Four: Why Published Sites Fail When Previews Succeed

In almost every case where an app functions inside the builder but fails on the public web, the culprit is one of four common configuration pitfalls.

1. Missing or Preview-Only Supabase Keys and Environment Variables

Most Lovable applications rely on Supabase for authentication, database storage, and edge functions. During preview generation, Lovable often shares credentials automatically behind the scenes or uses default workspace values. However, production client builds require public environment variables—specifically VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY—to be statically baked into the JavaScript bundle at deploy time.

If these environment variables are missing from your production publish configuration, your app boots up in the user's browser, attempts to instantiate the backend client with undefined values, and crashes before the first screen finishes rendering. This frequently manifests as an intractable blank white screen.

2. CORS Rules That Permit the Preview Origin but Block Your Domain

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that forbids a website running on one origin from making API requests to a server on another origin unless that server explicitly permits it. For a technical deep dive into this browser protection model, read the official MDN Web Docs guide to Cross-Origin Resource Sharing.

When your backend or edge functions are created, they may be configured to permit requests from Lovable preview domains (such as https://*.lovable.app) or local development hosts. When you launch on https://www.yourdomain.com, the browser sends an Origin header matching your custom domain. If your API server does not explicitly return your domain in its Access-Control-Allow-Origin header, the browser intercepts the response and blocks it completely. We explore the symptoms and remedies for this exact failure mode in our guide to the CORS error only in production pattern.

3. OAuth Redirect and Site URL Mismatches

Authentication failures are another leading reason why a lovable preview works but published site broken complaints surface immediately from new users. If you use social sign-in (Google, Apple, GitHub) or magic links via Supabase Auth, the identity provider checks the incoming redirect URL against a strict whitelist.

When you set up authentication in preview, your callback URL was likely set to your Lovable preview URL. If your Supabase "Site URL" or "Redirect URLs" settings do not include your production custom domain, one of two things happens:

  • The user signs in on production, but after authenticating at Google, they are redirected back to the Lovable preview screen instead of your live website.
  • The authentication provider rejects the request outright with an invalid_redirect_uri or 400 Bad Request error before the user can even enter their password.

4. Stale Builds and CDN Asset Caching

When you update your Lovable project and hit publish, the hosting provider compiles modern JavaScript modules with unique cache-busting hashes in their filenames (for example, index-B9a4c1.js). However, content delivery networks and aggressive browser caches often store the top-level index.html page.

If an end user's browser requests an older, cached version of your index.html file, that HTML may request old JavaScript chunks that the CDN has already deleted or replaced. The result is a cascade of 404 Not Found errors for script tags, leaving your interface frozen. Learn more about preventing this race condition in our reference on the stale build served after deploy pattern.

How to Diagnose the Issue in the Browser (No Engineering Degree Required)

You do not need to guess which of these four issues is breaking your app. Your browser's built-in developer tools tell you the exact failure point within ten seconds if you know where to look.

Opening Developer Tools

Open your published, broken website in Google Chrome, Brave, or Edge. Right-click anywhere on the blank or broken page and select Inspect, or press F12 (Windows) or Cmd + Option + I (Mac). Look at the navigation panel at the top of the drawer that opens; you only need two tabs: Console and Network.

Reading the Console Tab

Click the Console tab. This is where your web application logs runtime status messages and uncaught exceptions. If your published site is broken, you will almost certainly see red error text:

  • Uncaught Error: supabaseUrl is required: This confirms that your environment variables were omitted during the production build. The JavaScript bundle loaded, but it has no API endpoint to connect to.
  • Access to fetch at '...' from origin 'https://yourdomain.com' has been blocked by CORS policy: This message explicitly confirms reason number two. Your backend received the request, but refused to share data with your live domain.
  • Failed to load resource: the server responded with a status of 404: Look at the file name ending in .js or .css. If a core script failed to load, you are dealing with a stale CDN deployment or an interrupted publish sync.

Reading the Network Tab

Click the Network tab, check the box labeled Disable cache, and refresh the page while keeping the panel open. The Network tab lists every file, image, and database query your app initiates.

Click the Fetch/XHR filter button near the top to eliminate images and stylesheets so you only see API traffic. Pay close attention to the Status column:

  • Status 401 Unauthorized: This indicates that an API request reached your backend, but the API key passed by your app was missing, expired, or invalid. For context on this standard HTTP response, consult the MDN documentation on HTTP 401 Unauthorized.
  • Status 403 Forbidden: Common when database Row Level Security (RLS) rules or edge function permissions reject the request.
  • Status (failed) / net::ERR_FAILED: When accompanied by a red row, this is the classic visual footprint of a CORS rejection. The network engine halted the request before your application logic could inspect the payload.

Step-by-Step Fixes for Your Production Lovable App

Once your Console or Network inspection points you toward the culprit, follow these precise steps to restore your live site.

Fix 1: Re-Sync Supabase Environment Variables

If your browser console complains of undefined keys or missing backend configurations, navigate to your Lovable project dashboard:

  1. Open your project in Lovable and navigate to the project settings or integration panel.
  2. Check your Supabase integration status. If Lovable manages your Supabase project directly, click Reconnect or trigger a manual sync to ensure secrets propagate to the deployment pipeline.
  3. If you manually connected Supabase using custom environment variables, verify that both VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY are populated in the production environment settings, not merely in development drafts.
  4. Trigger a clean re-publish of the application to compile the keys into the static production bundle.

Fix 2: Configure Supabase Auth and Allowed Redirect URLs

If your users cannot log in, get stuck on login loops, or see authentication error screens, you must register your live domain inside Supabase. Review the official instructions in the Supabase Auth Redirect URLs documentation for platform-specific syntax.

  1. Log in to your Supabase Dashboard and select your project.
  2. In the left-hand sidebar, navigate to Authentication → URL Configuration.
  3. Find the Site URL field. Set this to your canonical production URL (for example, https://www.yourdomain.com). This serves as the default landing address when authentication flows complete.
  4. Scroll down to the Redirect URLs section. Click Add URL and register your custom production domain patterns:
https://yourdomain.com/**
https://www.yourdomain.com/**
https://*.lovable.app/**

Adding the wildcard pattern (/**) ensures that password resets, email verification clicks, and OAuth callbacks are accepted regardless of which specific subpage or routing path initiates the authentication request. Keeping the lovable.app pattern in the list ensures your preview environment continues to function alongside production.

Fix 3: Resolve Backend CORS Policies

If your browser network inspector displays CORS errors on calls to custom APIs, Python services, or external microservices, you must adjust the backend's allowed origins header:

  • For Custom Backends: Add your production custom domain (both apex and www variants) to the list of allowed origins in your server middleware (such as Express CORS, FastAPI CORSMiddleware, or Django CORS headers).
  • For Supabase Edge Functions: Ensure your function responses return the proper headers. Your edge function should include:
const corsHeaders = {
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
};

While an asterisk (*) permits all origins for public edge functions, sensitive APIs should explicitly match your domain or dynamically reflect the incoming Origin header when it matches your production domain.

Fix 4: Busting Stale CDN and Local Caches

If your console indicates missing script chunks (404 Not Found on .js files) right after a deployment, clear local and intermediate caches to confirm whether the issue is transient:

  1. Perform a hard refresh in your browser. On Mac, press Cmd + Shift + R; on Windows, press Ctrl + F5 or Ctrl + Shift + R.
  2. Test the live URL inside a private or Incognito window with browser extensions disabled.
  3. Test the website from a mobile device connected over cellular data (disconnect from the local Wi-Fi to bypass any local router or DNS caching).
  4. If you manage custom DNS through Cloudflare or a similar reverse proxy, navigate to your Cloudflare dashboard and execute a Purge Everything cache command to ensure no outdated index.html files linger at edge points of presence.

Testing and Verifying the Published Site

rarely rely solely on your own development browser to confirm that a fix succeeded. Browsers store persistent tokens, session cookies, local storage items, and service workers that can trick you into believing a site is operating normally when it remains broken for all first-time visitors.

Follow this checklist after executing any fix on your live domain:

  • Cross-Device Check: Open the published site on an iPhone or Android phone using a cellular carrier network. Verify that the homepage renders without freezing.
  • The Incognito Flow: In an incognito window, test an unauthenticated landing page, click to register a fresh test account, and confirm that registration emails arrive and route back to the live domain.
  • The Network Inspect Verification: Re-open the Network tab in your desktop browser. Confirm that every Fetch/XHR call returns an HTTP status code of 200 OK or 201 Created, with zero failed network preflight requests.

Stop Finding Out from Customers: Real-Time App Monitoring

Resolving an issue when your lovable preview works but published site broken scenario happens in development is manageable. Experiencing that same failure on a random Tuesday morning while running marketing ads is catastrophic. For non-technical founders, finding out your live application is dead because an angry customer emails support or cancels a subscription is stressful and avoidable.

Standard ping monitors are insufficient for vibe-coded and low-code applications. A CDN will happily return a 200 OK HTTP status code for an empty index.html wrapper file even while the underlying React application crashes on a missing Supabase key or a CORS rejection. To protect your revenue, you need continuous visibility into whether your real user flows actually operate.

Nightlamp is managed monitoring and diagnostics for your app's availability and delivery. Rather than simply pinging a homepage URL, Nightlamp runs synthetic checks, including magic-link and email-delivery flow monitoring via AgentDraft, to confirm that database connections, API calls, and authentication handshakes function properly on your live production domain.

Crucially, you do not have to parse cryptic stack traces or decipher minified JavaScript errors on your own. Human engineers diagnose incidents for you; Nightlamp does not just fire alerts. When a build breaks or an API key expires, App Care evaluates the failure and delivers clear instructions explaining what went wrong and how to fix it in plain English. Nightlamp does not auto-remediate infrastructure on its own; a real engineer diagnoses each incident and tells you exactly what to fix.

Frequently Asked Questions

Why does my Lovable app show a blank white screen only after publishing?

A blank white screen on a published site almost often indicates an unhandled JavaScript error that halted execution before components could mount. The most frequent causes are missing environment variables (such as VITE_SUPABASE_URL ) that were available in preview but omitted during the production build, or a failed asset request (404) caused by a stale CDN cache serving an outdated HTML file.

How do I fix Supabase redirect errors on my custom domain?

Log in to your Supabase project dashboard, navigate to Authentication → URL Configuration, and update your Site URL to match your live custom domain (e.g., https://www.yourdomain.com). Then, add your custom domain with a wildcard path (https://www.yourdomain.com/**) to the Redirect URLs list. This ensures login links and OAuth redirects are accepted by Supabase.

What does a CORS error mean in my Lovable production console?

A CORS (Cross-Origin Resource Sharing) error means your frontend website running on your live domain attempted to fetch data from an API or backend server that does not recognize or authorize your domain. While the backend may have allowed requests from the Lovable preview URL, you must update your API or backend headers to permit requests originating from your custom live domain.

Will clearing my browser cache fix the problem for all users?

Clearing your local browser cache will only fix the problem on your own computer if your local browser was holding onto an outdated build file. If the underlying cause is an incorrect Supabase URL, a missing redirect domain, or a misconfigured CORS rule on your backend, every user who visits your site will experience the failure regardless of their local cache status.

How do I know if my published Lovable site is down for everyone?

You can check if your site is globally unavailable by opening the URL in an incognito window, testing on a mobile phone disconnected from your local Wi-Fi, or running a check through external uptime monitoring tools. To diagnose platform-wide outages, you can also check real-time platform statuses on the Lovable status overview page.

Protect Your Live Application with Nightlamp

Do not wait for your paying users to report that your published site has crashed. With Nightlamp, you get comprehensive managed monitoring for your production endpoints, SSL certificates, and critical email authentication journeys. Start catching production deployment issues the second they happen—sign up for a 14-day free trial on Nightlamp, with plans starting at $79/mo.