Why your Lovable app shows a blank page after deploy

A blank page after deploy almost always means your JavaScript never ran, or it threw an error before it could draw anything. The page is not empty. The container it draws into is empty, because the code that fills it stopped.

Open your browser’s developer tools, press F12, and look at the Console tab. Whatever red text is there is your actual problem. These are the four causes behind most of these, in the order worth checking.

1. Your environment variables never made it to production

Preview runs with the keys the builder holds for you. Your own hosting does not have them unless you put them there. When your app starts up, asks for its Supabase URL, and gets nothing, it throws before the first screen renders.

How to tell: the console mentions an undefined URL, an invalid key, or a failed fetch to a URL that looks malformed.

The fix: add every variable to your host’s environment settings, then redeploy. A redeploy is required. Hosts bake these values in at build time, so changing them without rebuilding changes nothing.

The trap: only variables with the right prefix reach the browser. In a Vite build that prefix is VITE_. Rename a variable and it silently becomes undefined.

2. Your routing is not configured for a single-page app

Your app has one real file, index.html, and the JavaScript decides what to show based on the URL. Your host does not know that. Someone asks for /dashboard, the host looks for a folder called dashboard, finds nothing, and returns its own empty response.

How to tell: the homepage works and every other URL fails, or a refresh on any page breaks it.

The fix: tell your host to serve index.html for any path it cannot find. On Netlify that is a _redirects file with /* /index.html 200. On Vercel it is a rewrite in vercel.json. On Cloudflare Pages it is a _routes.json or a single-page-app setting.

3. Your asset paths are wrong for where the site lives

If your app is deployed into a subfolder, or built with the wrong base path, the HTML loads but asks for its JavaScript from a path that does not exist.

How to tell: the Network tab shows 404s for files ending in .js or .css, or the console says a module failed to load.

The fix: set the base path in your build config to match where the site actually lives. At the domain root that is /.

4. Something is only defined in preview

This is the one that wastes the most time. Managed platforms sometimes hold pieces of your app that never appear in your code repository, particularly server functions. Your app calls one, gets a 404, and stops.

How to tell: the console shows a failed request to a function endpoint rather than a code error.

The fix: check what is actually deployed on your backend, not what your repository says. On a Supabase project, list the deployed functions and compare that list against your code. Anything present in one and missing from the other is a candidate.

We hit exactly this on a recruiting platform: six edge functions existed only in the deployed project and not in the repository at all. Every diagnosis after that ran against the deployed state, never the local code.

The two-minute version

1. Open the console. Read the first red error, not the last one.
2. Check the Network tab for 404s on .js files.
3. Confirm your environment variables exist in production and redeploy.
4. Add the single-page-app redirect rule.

If the console is clean and the page is still blank, the problem is usually an error thrown during startup that the app swallowed silently. That takes a code trace, not a settings change.