Lovable Works in Preview but Breaks on the Live URL

Why does my app work in Lovable preview but break on the live URL?

The Lovable editor preview runs in a sandboxed environment with your editor environment variables pre-loaded. Your live deployment runs on a hosting provider — Lovable Cloud, Vercel, Netlify, Cloudflare Pages — with only the environment variables you explicitly added there. If a variable exists in the editor but not in the production host, the deployed app will fail at any code path that depends on it, while the preview continues to work perfectly.

This is the **Vanishing Env-Var** — the most common cause of the preview-works-live-breaks failure pattern. The moment you publish to a custom domain or a separate hosting provider, the editor environment variables disappear. Every variable your app needs must be manually added in the hosting provider's settings panel.

The second most common cause is a stale deployment — the hosting provider is serving a build from an earlier commit while the editor preview reflects the current state. Check your deployment logs to confirm when the last production build ran and which commit it deployed.

How do vanishing environment variables break a live deployment?

Environment variables configured in the Lovable editor are not automatically propagated to your hosting provider. Every variable your app needs — Supabase URL and anon key, Stripe publishable and secret keys, any API endpoint URLs — must be added manually in the hosting provider's settings panel. The symptom is a runtime error on first load: the Supabase client fails to initialize, or the Stripe checkout throws an undefined key error.

1. Open your hosting provider's dashboard and navigate to Environment Variables settings.
2. Compare the list against the variables in your Lovable editor (Settings → Environment).
3. Add any that are missing, being careful to use the production values — not development or test values.
4. Trigger a new deployment after adding variables — most providers require a redeploy for changes to take effect.
5. Check the deployment logs for any startup errors that reference undefined environment variables.

Why does login redirect to localhost in production?

Lovable-generated apps often configure the auth callback URL as `http://localhost:3000` during development. When you deploy to a real domain, the auth provider — Supabase, OAuth providers, or Stripe — redirects the user back to localhost after sign-in, which fails in production. This must be updated in both the auth provider settings and the app's environment variables.

1. In your Supabase project, go to Authentication → URL Configuration.
2. Update Site URL to your production domain (e.g. https://yourapp.com).
3. Add your production domain to the Redirect URLs allow-list.
4. Update the NEXT_PUBLIC_SITE_URL or equivalent environment variable in your hosting provider.
5. For OAuth providers (Google, GitHub), update the authorized redirect URIs in their developer consoles.
6. Redeploy and test the full sign-in flow on the live URL.

Why do I get 404 errors when I refresh a page on the live URL?

A 404 on page refresh is a classic single-page app deployment problem. The hosting provider tries to serve a file at the URL path — for example `/dashboard` — but that file does not exist on disk because the app uses client-side routing. The solution is to configure your hosting provider to serve the root index.html for all paths and let the JavaScript router handle the URL.

1. For Netlify: add a _redirects file to your public folder with the line: /* /index.html 200
2. For Vercel: add a vercel.json with rewrites that map all routes to /index.html.
3. For Cloudflare Pages: enable the 'Single-page application' option in the Pages project settings.
4. For Lovable Cloud: this should be handled automatically — if you see 404s, contact support.
5. After adding the config file, redeploy and test navigation and refresh on a deep route.

What if the deployment is stuck serving an old commit?

Sometimes the deployment pipeline appears to succeed but the live site continues to serve an old version. This is the **Stale-Commit Deploy** — the build cache is stale, a deployment hook did not fire, or the CDN is serving a cached version of the old build. The fastest fix is to trigger a forced redeploy from scratch.

1. In your hosting provider dashboard, find the Deployments list and check the most recent deployment's commit SHA.
2. Compare it to the latest commit in your GitHub repository — they should match.
3. If they do not match, check whether the GitHub integration is still connected and whether the deployment hook fired.
4. Trigger a manual redeploy from the current HEAD commit, clearing the build cache if the option is available.
5. After the new deployment completes, hard-refresh the live URL to bypass CDN caching.

How do I confirm the deployment fix is actually working?

After fixing a deployment issue, confirm the fix at the deployment and infrastructure level — not just the browser view. CDN edge caching and local browser caching can both show you a stale version of the site for minutes or hours after a successful redeploy, masking whether the underlying issue is resolved. These steps confirm the fix is genuine and the new build is actually live.

1. Check the hosting provider's deployment log to confirm the new build used the latest commit SHA.
2. Open the live URL in a private/incognito browser window to bypass local browser cache.
3. Open DevTools (F12 → Console) on the live URL and confirm no red errors on load.
4. Check the Supabase dashboard to confirm any data operations from the live URL are succeeding.
5. Test the full auth flow on the live URL — sign up, sign in, and confirm no localhost redirects.
6. Refresh a deep route directly (e.g. /dashboard) and confirm the app loads rather than returning 404.