Enviera

lovable export code won't run

If your Lovable export code won't run, start with the exported project's package.json, not a double-click on index.html. Identify its framework, install its dependencies with the matching package manager, then run the development script the project defines. Opening source files is not the same as starting the app.

Lovable's GitHub integration gives you code you can work on locally. Its export documentation distinguishes source code from database records and stored files, which are separate. A source download is not a self-contained copy of every service your app uses. [1][2]

Check the project before choosing commands

Extract the download, or use your local repository copy. Open the folder containing the app's package.json. Read these files before running an installation:

If these instructions disagree, resolve that mismatch before upgrading dependencies or rewriting scripts. Keep troubleshooting changes in a local copy or feature branch.

Stop opening the source with file://

A browser address beginning with file:// means you opened a file on disk. It does not install packages, run the development server or build the project.

Vite treats index.html as source and processes its module references through the dev server. MDN also documents browser restrictions on loading JavaScript modules through file://. Use the HTTP address printed by the project's development command. Do not disable browser security to make the source file open. [4][5]

This distinction matters even when an export contains an HTML file: its script can still point at TypeScript or other source that the build tool must process.

Install, then start the script that exists

For an npm project with a matching package-lock.json, run from the app folder:

npm ci
npm run
npm run dev

The final command applies only if the project defines a dev script. If it uses another name, run that script instead. Keep the terminal open and visit the address it prints.

npm ci requires an existing npm lockfile and fails when that lockfile disagrees with package.json. If the project uses Bun, use its documented Bun install and run commands. If an npm project has no lockfile, npm install can create one; review that change rather than deleting a different package manager's lockfile. [2][3][6]

Use the first failure to choose the next check:

Local resultNext check
No package.json in the current folderLocate the actual app root inside the extracted download.
The requested script is missingRead the scripts instead of inventing a start command.
The script calls Vite, but reports vite: command not foundConfirm dependency installation succeeded in that app folder, including development dependencies.
Installation reports a lockfile mismatchRestore the matching manifest/lockfile pair or resolve the dependency change deliberately.
A local URL opens, but sign-in or data requests failKeep the frontend result and investigate the separate backend branch below.

The missing-Vite case was reproduced in the synthetic check below. Lockfile behavior comes from npm documentation; backend behavior comes from Lovable's local-development documentation. [3][6]

Verify source, development output and build output separately

We made a tiny synthetic Vite project for this check. It was not an actual Lovable export and had no backend.

Its source HTML referenced /src/main.ts. That file contained:

const message: string = 'Synthetic app running';
document.querySelector('#app')!.textContent = message;

The scripts were dev: vite, build: vite build and preview: vite preview, with the local servers bound to the loopback interface.

Observed on 1 November 2026 using Node 22.16.0 and npm 10.9.2. The installed Vite version for the successful checks was 8.3.5:

CheckObserved evidence
Start before dependency installationExit 127: sh: vite: command not found.
Install with a generated npm lockfilenpm ci completed successfully.
Start the dev serverThe local page and /src/main.ts returned HTTP 200. The served module had its TypeScript annotation removed.
Run npm run buildExit 0; generated dist/index.html and a JavaScript asset.
Run the preview scriptThe local page and its generated JavaScript asset returned HTTP 200. The HTML referenced the bundled asset instead of /src/main.ts.

These checks verified installation, transformation, building and HTTP serving. They did not verify browser rendering, login, a database or an actual Lovable project.

For your app, open the printed local address in a browser and check that the intended screen renders. Inspect the console and failed network requests, then run its build command. For a static Vite project with a preview script, run:

npm run build
npm run preview

Open the preview URL and check the built app too. Vite's default static output is dist, but configuration can change it. Its preview server is for local checking, not production hosting. A successful build alone does not prove the screen or its integrations work. [7]

If the project uses TanStack Start

Keep its server runtime in the check. Follow the project's build and start scripts and inspect the output they actually produce. Do not treat a folder of client assets as the whole application.

For the Vite/Nitro Node-server setup, TanStack documents building and starting the generated server; Lovable's corresponding example uses node .output/server/index.mjs. That path is conditional on the build configuration and target. Confirm the file exists before using it, and follow another adapter's instructions when your project uses one. These are vendor-documented steps, not part of our synthetic reproduction. [2][8]

A running frontend does not prove the backend is configured

Inspect the environment configuration privately before testing actions that write data. Lovable documents that a local clone can still point at the published app's backend. A feature branch does not create an isolated database. [3]

For this diagnosis:

A redirect error after the screen loads is a different result from a failed dependency install. Check the local callback URL against the development auth provider's allowed redirect URLs; leave the production Site URL and production database unchanged.

Lovable also documents service credentials that do not travel with a repository. In newer TanStack Start apps, managed connector and AI calls can fail locally because their server code is running on your machine. Do not “fix” that by copying privileged keys into browser configuration. Record the failing service and follow its supported development setup. These integration branches were not reproduced here. [3]

Local run succeeds, but the deployed site fails?

Move to Lovable app not deploying for hosted build and deployment diagnosis. Keep the successful local command, runtime version and first host error for comparison.

Only if the deployed app works and your own domain has a certificate problem, use the custom-domain SSL checker. It cannot inspect exported code, install dependencies or tell you why a local script failed.

Still unable to isolate the failure? Send your project for a Production Readiness Audit.

How we checked this

Sources below were read on 1 November 2026. The synthetic Vite test reproduced a missing-dependency start failure, followed by successful installation, development serving, build and build-preview serving. It was not a client incident or a Lovable export. Browser rendering and backend integrations were not tested. The TanStack Start, environment and authentication branches are based on vendor documentation.

Sources

All read 1 November 2026; publication dates are not stated here because they were not established.

  1. Lovable, Sync your Lovable project with GitHub.
  2. Lovable, Deploying outside Lovable.
  3. Lovable, Git sync overview.
  4. Vite, Getting started.
  5. MDN Web Docs, JavaScript modules.
  6. npm, npm ci.
  7. Vite, Deploying a static site.
  8. TanStack, Hosting.
  9. Vite, Env variables and modes.