Snapshots, undo and backups

Safety nets

LazyFrog's safety nets: automatic snapshots, undoing the last change, restoring code or data, and off-site backups on paid plans.

What they are: copies kept with the project, so a restore loses at most the hour since the last automatic one. On a paid plan LazyFrog also keeps separate encrypted off-site backups for disaster recovery (Free keeps the snapshots only); they aren't something you restore from. For a business taking payments, still keep the records it can't lose (orders, payments) also in the provider (Stripe).
Logs: logs_tail reads the last lines (search back with grep and since); a production app has no request log of its own, so log what you'll need (errors with the tenant and route).
Every change is recorded and can be undone. fs_write, fs_edit and an exec that isn't read_only take an undo point of their own just before the change (a snapshot; the result ends "Undo point … was taken just before this change"; a command that changed no files usually keeps none). fs_edit and fs_write answer with the lines they changed, and exec with the files it changed ("Changed 2 files: …"): read them back rather than assume. To take back the last change, snapshot undo: it reverts that change alone, lists the files it reverts (more than 20 need confirm: true) and keeps the state it replaces; undo again goes one more change back (past the last 50 changes and the last hour, ten minutes at a time). The owner sees the same changes in Activity and can undo them there. After a run of changes the result says once to commit: a git commit of work that works is the clean undo point.
Snapshots: hourly automatic ones, plus one before every risky action (database writes, migrations, restores). snapshot create makes one now; snapshot restore goes back and keeps the state it replaces, so a restore can be undone. Its scope is code unless you say otherwise: after a bad database write use database, for lost files data, or all. Snapshots are kept for the plan's undo history (a day on Free, a week on Hobby, 30 days on Pro, 90 days on Business); the ones each publish takes (pre-deploy-<n>, which hold the live database) go with their release: the last 10 releases younger than 90 days and one a day within the undo history are kept, plus always the live release and the one before it; the rest are removed every hour. So data deleted from the live site lingers in those copies for up to 90 days (longer only in the live release's and the previous one's, until the next publishes), and on a paid plan in the encrypted off-site backups for up to 62 days. Neither can be purged early; say so when an owner deletes someone's data, and that a database rollback or restore brings deleted records back: keep a log of erasures outside the data that's restored (a table of ids, re-applied after any restore). A code restore changes the preview only: the live site runs its published version, which deploy rollback changes (with_database: true also brings back the live data from before the later deployments changed the schema). Restoring the live site's database or files from a snapshot needs the owner's approval when you ask, like a destructive publish.
A publish whose migrations delete or rewrite live data needs the owner's approval when you ask for it: the first try (with or without confirm) puts the request in their portal; tell the user what the change does to their data, and publish again with confirm: true once approved.
Destructive actions ask for confirm: true. Deleting a project asks the user to approve it; it then stays in the Trash for 7 days, and project unarchive brings it back.
Archiving (project archive) parks a project: its data is kept and it stops counting toward the plan's projects, but its live site goes offline too (preview and production stop; every address, custom domains included, shows "This site is archived by its owner"). It is not a way to keep a site online for free; ask the user first, and say so. project unarchive brings it back (it counts again, and a published site goes live from its current release). On Free a project archived that was never live lets its name go at once (anyone may take it); unarchiving gives it back if it's still free, and otherwise the project gets a close one (the result's slug; say so). Archiving or deleting a project lets a read-only one (kept after a downgrade) take the place it frees.
Mutating tools accept idempotency_key: if a call might not have arrived, repeat it with the same key and it will not run twice.
If another AI client is working in the same project you get workspace_busy; wait and retry.