Restoring
Every file in the site is captured once a day, without you asking. No setting to turn on, nothing to configure.
Once a day, automatically, every file in your site is snapshotted — whether you deployed that day or not.
History stretches back seven days. See exactly what changed since any of those snapshots before you commit to anything.
The site is back to that day's files, served again through the same edge network — not a rebuild from memory or from whatever you happened to save locally.
The next Git push, zip upload, or CLI deploy behaves exactly as it did before the restore.
Seven days, not seven months. Daily backups are kept on a rolling seven-day window — the eighth day's snapshot replaces the first, so the window always covers the most recent week. Notice a problem within that window and a restore takes moments; notice later and that particular day's copy has already rolled off, though whatever you deployed after it is still there to restore from instead.
A concrete example
Say a CSS change goes out on a Tuesday and quietly breaks the layout on mobile — nobody notices until a visitor mentions it on Friday. Nothing about that is unusual, and it's exactly the case daily backups exist for.
Open the site's history and Thursday's snapshot is still sitting there, from before Tuesday's change went out. Pick it, restore it, and the site is back to the last known-good version in moments — the broken CSS never has to be tracked down or hand-fixed under pressure. Once things are calm again, you can go find what actually broke and fix it properly, then redeploy the corrected version the normal way.
Not the same thing
If you deploy through a Git repo, you already have a form of history — every commit is a version you can check out again, and you can see exactly what changed between any two of them. That's genuinely useful, and it's not what this replaces.
Daily backups work underneath that, at the hosting layer, and they don't care how you publish. Push through Git, drag up a zip, run the CLI, or let an assistant deploy through the MCP server — a snapshot happens the same way regardless, which matters most for the zip and CLI routes that don't keep a history of their own at all. Git tells you what changed and why, if your commit messages are honest. A daily backup just gets you back to a known-good day, fast, without needing to remember which commit that was.
Being honest about it
A daily backup restores files — the HTML, CSS, JS and images that make up your site. It doesn't restore a domain you let expire, undo a DNS record you changed at your registrar, or recover a closed account; none of those live inside the file snapshot at all. And because the window is seven days, a mistake that goes unnoticed for longer than a week has already rolled the last good copy off the end — the honest tradeoff of a backup window this size, not a hidden asterisk.
Worth knowing
Every file in the site, captured once a day automatically — no setting to turn on, nothing to configure.
Domain settings, billing, and DNS don't move when a deploy does, so a restore can't lose them either.
Yes — pick any of the last seven snapshots, as many times as you need.
Seven days covers the window where almost every mistake actually gets noticed — the day after a bad deploy, or the week someone finally looks. Storing snapshots indefinitely is real storage cost across every site on the plan, and passing that cost to everyone to cover a rare month-old mistake didn't make sense at 99¢. Longer retention is a reasonable add-on for the future; it's just not what the base price funds today.
Push again with Git, a zip, the CLI, or your assistant — included on every site at every price point.