Backup and restore an AI-built app (2026)

Who this is for

You shipped from Lovable, Bolt, Replit, v0, Cursor, or another AI builder. A live host answers. People who are not you can create an account. Rows live in Supabase, Firebase, or another hosted store. You want a restore you can run without asking the builder chat to “fix production.”

You are not this page if the app still lives only on a laptop, if only the founder can log in, or if you cannot take the live URL down tonight. Those are harden and people jobs. Open the production-ready page for the operating contract. Open the hire page if the people list is blank. Open GitHub handoff after an AI builder if the repo still sits on a personal login.

You are also not this page if you only want a prettier host badge. A green “Backups on” tile is not a plan. A plan is a copy you have opened, a second place it lives, and a person who can put it back.

What “backup” means

Backup is six copies you can name on one card. If any copy has no clock and no owner, you are hoping. The host will tell you after the row is gone. That is late.

• The database. The tables that hold orders, seats, and notes.
• User uploads. Photos, PDFs, and other files in a bucket. A table restore does not bring a deleted file back.
• Sign-in users. The list that lets a person come back. A schema dump is not that list.
• The secrets list. Host keys, payment keys, and mail keys. A repo clone does not hold them.
• The code repo. A mirror you can push to a new remote.
• Domain name records. The phone book of the internet (DNS): where the name points, and the mail proofs.

The database

The database is the first copy most founders think they already have. Host plans disagree. Supabase’s backup guide backs up Pro, Team, and Enterprise projects every day. Pro keeps 7 days. Team keeps 14 days. Enterprise keeps up to 30 days. Free projects do not get those daily copies. Supabase tells free projects to export with the CLI `db dump` command and keep an off-site file.

A default CLI dump is not the whole product. Supabase’s `db dump` page says the command runs `pg_dump` and skips managed schemas, including `auth` and `storage`. The default dump also skips data and custom roles. You get table shapes, not seats. If you need data, you must ask for it. If you need sign-in users, the default dump will not give them to you.

Postgres itself is plainer. The Postgres dump guide says `pg_dump` writes a file of SQL that can recreate the database as it was when the dump began. Restore is a second command: create an empty database, then feed the file to `psql`. Users who own objects must already exist, or the restore fails the ownership lines.

Amazon Relational Database Service (RDS) keeps a rolling window you set. RDS backup retention lets you keep automated copies from 0 to 35 days. Zero turns them off. The console default is 7 days. The API default is 1 day. If you delete the instance and do not keep automated copies, those copies go with it. Manual snapshots stay.

Firebase is a different store. Firestore scheduled backups need the Blaze plan. You can set one daily schedule and one weekly schedule. Retention can go up to 14 weeks. A restore writes into a new database. Time-to-live rules are not in the backup. You must put them back. Firestore export and import is a second path: a paid export into a Cloud Storage bucket you control.

Point-in-time recovery is a shorter clock. Supabase PITR is an add-on on Pro, Team, and Enterprise, and it needs at least Small compute. Write-ahead log files upload every two minutes. In the worst case, the recovery point objective is two minutes. Daily copies stop once PITR is on. A restore takes the project offline. Plan that halt.

User uploads and storage

Files are not rows. Supabase’s backup guide is blunt: database copies do not include objects you stored through the Storage API. The database only holds metadata. Restoring an old database does not restore a file you deleted after that copy. A bucket you never copied is a hole the size of every photo your users sent.

If the files live on Amazon S3, versioning is the host tool. S3 Versioning keeps more than one variant of an object in the same bucket. It starts off. You must turn it on. After it is on, a delete writes a delete marker instead of wiping the object. An overwrite writes a new version. You can restore the old one. Each version is a full object. You pay for each one. A bucket that was never versioned has no prior copy to open.

Write the bucket name and whether versioning is on. Write whether a second copy leaves that account. A folder on the founder laptop that also runs the builder is not a second place.

Sign-in users

A restored app with no users is a brochure. People paid. They cannot come back. Treat the sign-in list as its own copy.

On Firebase, auth:export writes user accounts to JSON or CSV. Password hashes go with the file only when the caller has Editor or Owner. Firebase shows the hash settings under Authentication → Users. Store that block with the export. Import needs those same settings.

On Supabase, sign-in users live in the `auth` schema. A Pro daily backup of the project includes that schema. A default `db dump` does not. If you are on Free, or if you only ever ran the default dump, you do not have a user file. Do not learn that on a Sunday restore.

After any user restore, prove one stranger path: create a seat, sign out, sign in, reset the password. A count that matches is good. A person who can still open the app is the test.

The secrets list

Secrets are the keys the app needs to talk to mail, payments, and the database. They do not live in Git unless someone pasted them there. That paste is a leak, not a backup.

Vercel environment variables sit outside the source. Values are encrypted at rest. A Config value stays readable to people with project access. A Secret value is write-only after you save it. You cannot open it later to copy it down. If the only copy of a Stripe key is a Vercel Secret, a new host has nothing to paste. Keep a sealed list off the host: name, which environment it belongs to, and the value.

`vercel env pull` writes Development values into a local file. That file is for a laptop. It is not a production restore kit. Production and Preview values can differ. Write which environment the live app actually uses.

Supabase daily copies skip passwords for custom roles. After a restore that uses those roles, you reset the passwords. Put that reset on the card next to the secrets list. A restore that comes up with locked roles is a half restore.

The code repo

The builder project is not a repo you control. A green GitHub connector is a start. It is not the off-site copy.

GitHub’s backup guide says a Git repo is the files plus the history. A mirror clone (`git clone --mirror`) copies that. If you use Git Large File Storage, also run `git lfs fetch --all`. Zip the folder and put it somewhere that is not GitHub. Restore is unzip, then push to a new remote. GitHub’s migration archive is for moving between GitHub products. It skips Large File Storage objects, and GitHub documents no supported restore of that archive onto GitHub. Use a mirror clone to stand the app back up.

A clone does not hold host env values, store certificates, or the database. Prove a cold boot once: builder closed, clone opened, placeholders replaced from the secrets list, first journey completes. This page only asks whether a second copy of the tree exists outside the builder login.

Domain name records

The name is how people find you. The records are how the name finds the host. If the registrar login is gone, the copy of the app does not matter. People type the old name and land nowhere.

Cloudflare’s import and export page lets you export the zone as a BIND file from the dashboard or the API. The file size cap is 256 KiB. Export also writes tags such as `cf-proxied:true` so you know which records were proxied. Keep that file with the secrets list. A screenshot of the DNS tab is not a file you can import at 11 p.m.

Write the registrar, the account inbox, and the renewal date. The hire checklist already covers seat moves. This page asks: can you rebuild the records from a file you hold?

How often

How often follows the host window, not a vibe. A daily host copy that keeps 7 days is a 7-day memory. A free project with no dump is a memory of zero. NIST does not pick your day count. It asks you to write one.

NIST SP 800-34 Rev. 1 is the US guide for recovering a system after a break. The full text says backup policy should name the least often you copy, what you copy, and where the copy lives — on-site or off-site. Off-site storage is good practice. A plan is not done until you test it, train the people, and keep the plan current. You do not need a federal binder. You do need those lines on a card.

Treat those bars as host memory, not a quote. The short bar is the gap you can still lose even with point-in-time on. The long bars are how long the host will remember if you never export. Deleting a Supabase project wipes the S3 copies too. That is in the same backup guide. A host keep is not an off-site keep.

A working default, using those windows: dump or export the database at least as often as the shortest host keep you actually have. On Free Supabase, that means a dump you run. Copy new uploads on the same clock, or turn on versioning and prove one file restore. Export sign-in users when the host dump skips them. Refresh the secrets list the day a key changes. Mirror the repo after each production merge. Export domain records the day they change.

Where the second copy lives

NIST wants a place that is not the same room as the live system. For a founder that means: not only the builder, not only the host dashboard, and not only the laptop that also holds the founder password.

GitHub tells you to put a mirror archive on an external drive or another cloud. Firestore export writes into a Cloud Storage bucket you name. Postgres writes a file you can move. Cloudflare writes a zone file you can keep next to the secrets list. None of those second places should share the same login as the live host Owner.

Name the second place in writing. A company drive, a second cloud account, or a sealed vault a backup person can open. Encrypt the dump. Do not mail a raw user file to a personal inbox.

How to test a restore

A copy you have never opened is a rumor. NIST’s sixth step is the test. Supabase takes the project offline during a restore. Firestore restore creates a new database. Postgres restore needs an empty target. Firebase auth import needs the hash settings. None of that is a guess you want to make on incident night.

Run the first drill on a spare project, not the live origin. Supabase can restore a daily copy onto the same project, and that project goes dark while it runs. Firestore restore already lands on a new database. After the spare project is up, compare counts. Open one uploaded file. Sign in. If any of those three fail, the copy is not a restore.

Write the downtime you will accept on the live project. Supabase says downtime scales with database size. A drill that only lists backups in the dashboard is not a drill. A drill that opened a file and signed in is a drill.

Who owns it

Six copies with no owner is a drawer. One owner with no backup person is a single point of luck. Write the name. Write the inbox. Write the backup person. Write the restore click.

The owner must be able to open the host, the second place, and the registrar without the builder chat. On Supabase, Read-Only cannot download a backup — that fact already lives on the hire checklist. This page adds: the restore owner has already pressed restore on a spare project. Firestore restore needs a restore-admin role. Firebase auth export needs Editor or Owner for hash fields. If that person is on a plane, name a backup.

Route the restore card to the same company inbox that already gets the watch mail. The watch page names the halt click. This page names the restore click. They can be the same person. They must be a named person.

What to do this week

Keep the week small. You do not need a full operations team. You need six copies and one name.

1. Name the database copy. If you are on Supabase Pro or above, open Database → Backups and write the keep window. If you are on Free, run a dump that includes data and put the file off-site. Do not trust the default schema-only dump.
2. Name the file copy. Confirm Storage objects are not in the database backup. Turn on S3 versioning if that is the bucket, or export the bucket you control.
3. Export sign-in users if the dump skips `auth`. On Firebase, run `auth:export` as Owner or Editor.
4. Write the secrets list. Pull readable Config values. For write-only Secrets, copy the value from the vault that created them before you lose it.
5. Mirror the repo. `git clone --mirror`, zip it, park it off GitHub. Confirm the remote is a company org.
6. Export the domain records. Cloudflare Export is enough. Write the registrar inbox and the renewal date.
7. Restore onto a spare project once. Count rows. Open one file. Sign in. Write the dated note.

If a door is still red — no second Owner, no repo you control, no spare project — stop adding features and finish the people list. A dump cannot invent an Account Holder on Monday.

Next steps

Write the six copies. Park the second set. Prove one restore on a spare project. Name the owner. Keep the host badge as a clock, not the only copy. Customers should not be the first people who notice the rows are gone.

CodeCross is a product studio. The week after launch is a live host, a watch list, and a restore card that already passed one drill. If a copy is still only a host tile and you want a second pair of eyes, book a conversation.

FAQ

Does a daily host backup also copy the files users uploaded?

No. Supabase says database copies do not include Storage objects. The database only stores metadata. Restoring an old copy does not bring back a file you deleted later. Keep a second copy of the bucket, or turn on S3 Versioning if the files live there.

If I am on the Supabase free plan, do I still have daily backups?

No. Supabase runs daily copies on Pro, Team, and Enterprise only. Free projects should export with `db dump` and keep an off-site file. The CLI dump skips `auth` and `storage` by default and skips data unless you ask for it. A default dump is not your users.

Is a GitHub clone enough to restore the live app?

No. GitHub says a mirror clone holds files and history. It does not hold host secrets, database rows, or uploaded files. A migration archive also skips Git Large File Storage, and GitHub documents no supported restore of that archive onto GitHub. Clone the repo. Keep the other five copies too.

Can I read a Vercel secret back after I save it?

No. Vercel keeps Secret values write-only after save. Config values stay readable to people with project access. If the live key exists only as a Secret, write it into a sealed list the day you set it. `vercel env pull` fills a local Development file. That is not a production restore kit.

What does a restore test actually prove?

That a spare project can open with matching row counts, one real file, and one working sign-in. NIST SP 800-34 treats testing as a required step, not a badge. Supabase takes the project offline during a restore. Firestore restore writes a new database. Run the first drill off the live URL.

Who should hold the restore click?

One named person on a company inbox, with a named backup, who can open the host and the second place without the builder chat. Firestore restore needs a restore-admin role. Firebase auth export needs Editor or Owner for password hashes. A founder Gmail that also pays the host is not a path. A twelve-person Slack with no name is not a path.