First: missing does not necessarily mean deleted
Before restoring anything, confirm the signed-in account, workspace and project URL with the owner. Ask whether someone moved the project, changed access or unpublished the app. Preserve the error message and observation time. Do not create a replacement with the same address while you are still identifying the original.
This guide concerns apps built in Lovable. A separately deployed GitHub export has a different host and recovery owner. Do not apply a Lovable restore procedure to a Vercel deployment or an external database.
Choose the layer before choosing a button
| What happened? | Who reviews it? | Documented entry point | Before approval |
|---|---|---|---|
| One project disappeared | Project owner or workspace owner | Workspace settings → Workspace → Recently deleted projects | Check the deletion deadline and exact project before restoring. |
| The whole workspace disappeared | Workspace owner; Enterprise uses its account team | Account settings → Account → Recently deleted workspaces | Recover the workspace, not each project separately. |
| Project opens, but a code change broke it | An authorized project editor | Project History: preview a candidate before reverting | A code revert is not a database restore. |
If the project still exists and only needs to be taken offline, unpublishing is different from deletion. Likewise, selecting an old preview is not the same decision as reverting code or changing what visitors receive.
Restore one deleted project
The October 14 announcement describes recovery for 60 days, including code, version history and project chat. All plans support project restoration. Project owners can recover their own projects; workspace owners can recover other owners' deleted projects. Record who is authorized before proceeding.
- Locate the original. Use the project-restoration entry above. Match the project identity, deletion time and remaining days, rather than relying on a familiar display name.
- Review the impact. Confirm with the app owner that bringing the app back online is intended. Identify customer-facing jobs and integrations that need a separate review.
- Restore only the approved target. An authorized operator selects Restore and confirms. This article is not permission for an agent to operate your account.
- Verify before declaring recovery. Use the post-restore checks below; keep untested journeys UNVERIFIED.
The project guide counts 60 days from the first deletion, even after a restore and another deletion. Recovery is unavailable once the window ends or permanent removal starts. Preserve the displayed deadline, not a guessed new one.
The same guide says a Cloud backend paused by deletion resumes, but one paused manually or for insufficient credits stays paused. A taken URL subdomain can block restoration; ask its authorized owner or support to resolve it, rather than renaming an unrelated app. Projects removed with a workspace must be recovered with that workspace. A review restriction can also prevent restoration. Stop on an unexplained refusal instead of repeatedly retrying.
Restore a deleted workspace first
The workspace guide provides self-service recovery within 60 days for owners on Free, Pro and Business. Enterprise owners contact their Lovable account team. The account settings list appears only when the owner has an eligible deleted workspace. Its projects and members return with the workspace; individual project restores are not the first step.
Ask the owner to confirm the workspace identity and approve the scope before selecting Restore. Afterwards, check membership and the plan. A subscription that ended during deletion means the workspace returns on Free. Do not automatically resubscribe or assume restored membership proves that every app, integration and paid feature works.
If the project exists, consider version history instead
In History, inspect a snapshot and its code diff before choosing Revert. Lovable documents that a revert restores code and redeploys matching edge functions, while database data stays as it is. Later data edits and migrations are not undone. Very old snapshots may remain viewable while no longer being revertible.
Have the maintainer review schema, credential references and external API contracts before approving a revert. Previewing the right screen does not prove safe writes. If data recovery is required, pause and make a separate, explicitly approved plan.
For an app that uses Supabase, see the database backup checklist. It is not a universal restore recipe for Lovable Cloud or permission to overwrite production data.
A recovery message is the start of verification
ShipStackLab recommends a short acceptance record with a named owner. These are proposed checks, not guarantees made by Lovable. Avoid real charges, emails or destructive writes simply to prove that a button worked; agree on harmless test data and permitted actions first.
- Identity: Check the recovered account, workspace, project and expected code revision against the incident record.
- Public route: Check the intended domain and audience. A homepage response does not prove login, uploads or restricted pages work.
- Data and access: Review representative records and permitted user roles without exposing customer data. Keep uncertain backend state UNVERIFIED.
- Integrations and jobs: Have each owner review connection health and possible side effects before approving renewed processing.
- Exit decision: Record remaining failures, who will handle them, and whether the app is safe to reopen. Do not silently change billing or permissions.
Use the Lovable security checklist for the separate visitor/data-access review. Neither this guide nor an official restore receipt is a security audit.
Copyable recovery handoff
- Observation time / symptom / affected user journey: __________
- Account / workspace / project / approving owner: __________
- Recovery layer / deletion time / displayed deadline: __________
- Target version / current data compatibility / preserved source: __________
- Approved action / public-domain result / harmless checks: __________
- Access / backend / plan / integration unknowns: __________
- Owner acceptance / unresolved issue / next review: __________
Keep this record privately, without secret values. If recovery is no longer available, inventory preserved code and services with the export and migration guide. A surviving repository is a starting point, not proof that authentication, stored files or the original service can be rebuilt. Restoration success remains UNKNOWN until verified.