Lovable app backup: what to save before a developer fixes it

A Lovable app backup needs more than a GitHub connection. Preserve the code you are about to change, the database, uploaded files and the settings needed to run them together. Supabase's backup documentation gives Pro projects access to 7 days of daily database backups, but explicitly excludes the actual files stored through its Storage API.

That distinction matters before you ask a developer to fix an app containing customer documents or product images. Restoring the rows that describe a file does not bring back the file. This guide covers preparing a recovery copy before repairs, not choosing a new framework or promising that every export can restore your app unchanged.

What belongs in a Lovable app backup?

A recovery copy is a preserved set of application code, data, uploaded files and configuration records that someone can use to rebuild a working environment without relying on the production environment remaining intact.

Start by writing down where each part lives. Lovable's hosting and ownership guide separates code, frontend hosting, and backend data. Your app might use Lovable Cloud or a separately managed Supabase project. Identify yours before applying any provider's backup instructions.

Ask the developer to show where the current deployment gets its database connection and files. Record the production domain, repository branch and backend project in a private handoff document. List required environment variable names and who controls them; keep secret values in an approved password manager, outside the document and repository.

The practical deliverable is a recovery inventory with an owner beside every item. A folder labelled "backup" says little if nobody knows which deployment it matches.

Why doesn't GitHub sync protect the whole app?

Lovable's GitHub documentation describes exporting and syncing project code. Changes can travel back into Lovable from the active GitHub branch, so a connected repository is also an editing route. Treat it as somewhere a repair can change things, rather than an untouched archive.

A code snapshot is a recorded version of an application's source files, identified by its saved commit or archive, which preserves the implementation but does not by itself preserve live customer records or uploaded documents.

Before work begins, record the commit that matches the deployed app and preserve a protected copy. Have the developer make repairs on a separate branch, with an agreed review step before production changes. Confirm which branch Lovable is syncing so a well-intended edit does not appear in the wrong environment.

If you already have an export, ask the developer to open it and identify the build instructions. A download completing successfully proves the archive exists. It does not prove the app can run, connect to its backend, or recover its files.

How much database history does Supabase keep?

For an app connected to managed Supabase, its documented daily backup access depends on the plan. These are provider retention policies, not measured recovery results or a guarantee about a Lovable Cloud backend.

Table: Daily backup access documented by Supabase; uploaded Storage files are excluded from these database backups.

Supabase documents 14 days of daily database backup access for Team projects. Supabase documents up to 30 days for Enterprise projects. Neither retention window removes the need to preserve uploads separately.

Retention answers how far back you can look, not how much recent activity you can afford to lose. Supabase warns that daily backups can still leave a day's worth of data at risk. If customers keep placing orders during repairs, a rollback plan needs to account for those new orders rather than overwrite them with an older copy.

For teams considering finer recovery, Supabase lists its 7-day point-in-time recovery option at approximately $100 per month, with separate plan and compute requirements. That is the recovery add-on price, not a complete hosting bill or a quote for fixing an app. Choose it based on acceptable data loss, not because a longer feature list sounds safer.

What gets missed when someone says the database is backed up?

Uploaded files are the clearest gap. Supabase says its database contains metadata about Storage objects, while the objects themselves sit outside the database backup. Have the developer preserve the files through an appropriate storage export and record the bucket names and paths needed to reconnect them.

Protect that export as customer data. Keep access limited, use protected storage, and agree when temporary copies will be deleted. Avoid giving a contractor an unrestricted dump when a smaller, sanitized test dataset can answer the debugging question.

Configuration needs attention too. Lovable's ownership guide says moving the database alone does not move authentication, storage, realtime or Edge Functions. Record the settings and deployment steps those services require, even when the immediate job is only a repair.

A recovered app can also act on the outside world. Keep outgoing email, billing actions and scheduled jobs disabled in the rehearsal environment. If the app uses business workflow automations, list their external destinations before letting a restored copy run them.

How do I know the backup will work before the repair starts?

Ask for a recovery rehearsal in an isolated environment. The developer should explain which parts can be restored there and which need separate configuration. Do not point the rehearsal app at production just to make the login screen work.

Use a short acceptance record tied to the actual business. Can an authorized test user sign in? Can they open a representative record and its uploaded attachment? Are access restrictions still enforced? Can the developer identify the saved code version without guessing?

Supabase says an in-place restoration makes the project inaccessible, with downtime depending on database size. A rehearsal therefore needs a deliberate destination and an agreed maintenance plan. Pressing Restore on the live project is not a harmless check.

Agree on the rollback trigger before work starts. A failed deployment may justify restoring code alone; a destructive database change needs a data recovery decision. Someone must own the decision about preserving customer activity that arrived after the chosen backup.

What we did not test

This is a review of Lovable and Supabase documentation, not a recovery benchmark. We did not export a customer's app, restore a production database or measure downtime. We also did not verify backup retention for Lovable Cloud; the plan values above apply to managed Supabase.

For the broader repair decision, use the guide to fixing or migrating a broken Lovable app. Before authorizing production work, ask the developer for the saved code reference, protected data and file copies, and a written recovery result. Resolve any missing item before the repair touches it.