Lovable app won't deploy: find your case, then fix it

What you're seeing

You click Publish in Lovable and the app doesn't go live. The button may be replaced by Try to fix, it may not let you click it, the publish may fail with a message, or it may succeed and your live site still shows the old version. Each of these has a different cause, and Lovable's publish dialog usually tells you which one you have.

Find the line that matches your screen, then go to that section.

If the app is live and works, but parts of it break for real users (logins, payments, data), that's a different problem: see Lovable app not working.

1. Build or configuration error: Try to fix

Publishing builds your app before it serves it. Lovable shows Try to fix in two different places, depending on what went wrong:

• In place of the Publish button: the build failed because of an error in your app's code.
• In a banner saying publishing failed because of a configuration issue in your project: something in the project's setup is wrong. Click Try to fix in the banner; Lovable resolves the configuration problem, and you can publish again when it's done.

For a build error:

1. Click Try to fix once or twice, not more. Your account has 10 free fixes, shared with fixes from the Security view, and each one comes back 24 hours after you use it. After all 10 are used, Try to fix uses credits like any other build (see section 7).
2. If the same error comes back, stop clicking. Switch to Chat or Plan mode and ask Lovable to investigate the build error and explain the cause before it changes any code.
3. If the build broke after a recent change, revert. Open History in the top bar, find the last version that published, and click Revert in its row. The version currently live carries a Published badge, which is a good place to start. Then publish again.

One warning about reverting: it restores your project's code only. Data changes and database migrations made after that version stay in place, so if the breaking change was a schema change, a code revert can leave code and database out of step. Ask Lovable to check the schema against the restored code before you publish.

2. Blocked by permission or policy

The build is fine; you're not allowed to publish.

• No permission. By default, editors and above can publish. If hovering the button shows You don't have permission to publish this project, ask a workspace admin or owner to raise your role, or to publish it for you.
• Workspace policy (Enterprise). A policy can require an admin's approval before publishing, or block publishing completely. Submit the request with a note; you're told when it's approved or denied. A request with no decision expires after 30 days, so if yours went quiet, send a new one.
• Critical security findings. Lovable runs a security scan when you publish. Findings don't block publishing by default, but a workspace admin can turn on Block publishing with critical issues (Workspace settings → Security → Privacy & security). With it on, you can't publish until the critical findings are resolved. Open the findings and fix those first.

3. Temporary or Lovable-side failure

If the failure was a timeout or a rate limit, click Try again. Lovable's docs say retries usually succeed.

If it says it's an internal error, the problem is on Lovable's side. Check status.lovable.dev, which tracks Hosting, Published customer sites and Preview links separately. Retry later, and contact Lovable support if it keeps failing. Don't change your code to work around an internal error.

4. External connection or secret

If publishing fails because a connected service can't be reached, for example an expired Supabase connection, the code isn't the problem. Reconnect the service, or update the secret it needs, then click Try again.

Related: a backend function that depends on a secret you never added won't work until you add it. Secrets go in Lovable's Secrets, not in .env. VITE_ values in .env are built into the browser code and are visible to anyone, so never put a private key there.

5. Database conflict

If the failure says your changes conflict with data in the live database, use Ask the assistant to help. Lovable's docs say it will confirm with you before it changes anything, so read what it proposes before you agree.

6. Published, but changes aren't live

Publishing deploys the version you had at that moment. Later edits don't go live on their own.

• Republish. A dot on the Publish button means there are unpublished changes. Open Publish and click Publish changes.
• Accepting a draft isn't publishing. It changes the project, not the live site. Publish after you accept.
• Changes made in GitHub. Lovable syncs one branch, by default the repository's default branch (usually main). Commits on any other branch don't sync. Lovable only pulls when GitHub notifies it of a push, so if a push didn't arrive, pushing a new commit to the synced branch can fix it. If both sides had different commits, Lovable pushes its version to a branch called lovable-sync instead; if the synced branch was deleted, the project moves to lovable-fallback. Once the change is in the project, publish it.
• Check the exact URL. Confirm the publish finished and that you're opening the exact published address. If you're adding a custom domain, the Publish dialog shows it with a note that it's still being set up. Until that domain shows Live, Lovable publishes your app to the lovable.app address, so check that address first.

7. Out of credits

A live site doesn't use credits just by being up, and running out of credits doesn't remove a published site. But building stops, so you can't publish a new version until credits are available again. Apps that use the backend or AI features can also pause.

After adding credits, if the backend is still paused, go to More → Database and click Wake up on the paused card. Then publish.

8. The site was live and now isn't

• Unpublished for inactivity (Free plan). Lovable may unpublish a Free-workspace project when the app has had no visits for 12 months or more, the workspace owner hasn't logged in for 12 months or more, and the project has no connected custom domain. Your project, code and data are kept. Check your email for Lovable's notice, then publish again.
• App temporarily unavailable (Free plan, newer apps). Free-plan apps created from 13 May 2026 (TanStack Start apps) are limited to 1,000 server requests per project per 10 seconds. Older React + Vite apps aren't covered by this limit. Visitors over the limit see App temporarily unavailable and can retry after a minute. Images and scripts don't count. Paid plans don't have this cap.
• Someone unpublished it. Check Project settings → Publishing. Anyone who can publish can also unpublish.

Lovable's own site-down checklist, in order:

1. Check status.lovable.dev for a platform incident.
2. Open the Publish dialog: is the project still published?
3. If it isn't and you're on Free, check your email for an inactivity notice.
4. If you use a custom domain, open Project → Settings → Domains and confirm its status is Live.
5. Ask Lovable in the project chat about your domain. It reports the domain's current state and whether the project is published.
6. Still down: contact Lovable support with your project URL and what you see.

9. Deploying outside Lovable (Vercel, Netlify, Cloudflare Pages)

If the build or the site fails on another host, first check which kind of project you have:

• @tanstack/react-start in package.json: a TanStack Start app. It needs a host that runs a server, not static file hosting.
• Otherwise, an older React + Vite app. It builds to static files in dist/.

Settings Lovable's docs give: build command npm run build, Node 22, output directory dist on Netlify and Cloudflare Pages (Vercel doesn't need it).

Get the app working on the new host's own address before you move your custom domain to it. Lovable's docs say it can't debug infrastructure it doesn't control.

When it's more than one of these

If you've been through the section that matches and the publish still fails, or every fix brings a new build error, the project usually needs someone to read the code rather than another prompt. That's what our Production Readiness Audit is for: we go through the project, find why it won't ship, and tell you what it takes to get it to production.

Sources

All read on 24 October 2026. Lovable docs pages carry no dates.

1. Lovable, "Publish"
2. Lovable, "Hosting"
3. Lovable, "History"
4. Lovable, "FAQ"
5. Lovable, "GitHub"
6. Lovable, "Secrets"
7. Lovable, "Deploying outside Lovable"
8. Lovable status page