Backups
Your whole site is saved once a day, and the last seven days are always one click away — so undoing a change you regret takes a moment, not an evening.
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 change you publish — from the editor, a Git push, a dragged-in folder or the CLI — behaves exactly as it did before the restore.
The last seven days, always there. Every day's copy joins a rolling week of history, so at any moment you can open the site and see it as it stood yesterday, three days ago, or last Tuesday. Almost every mistake gets spotted inside that window — the morning after a change, or the week someone finally mentions it — and a restore from any of those days takes moments.
A concrete example
Say a change goes out on a Tuesday and quietly breaks the layout on phones — nobody notices until a customer mentions it on Friday. Nothing about that is unusual, and it's exactly the day daily copies exist for.
Open the site's history and Monday's copy is still sitting there, from before Tuesday's change went out. Pick it, restore it, and the site is back to the last version that looked right, in moments — nothing has to be tracked down or hand-fixed under pressure. Once things are calm again, you can go and find what actually broke, fix it properly, and publish 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.
The daily copy works underneath that and doesn't care how you publish. Press publish in the editor, push through Git, drag a folder in, run the CLI, or let an assistant publish through the MCP server — the copy happens the same way regardless, which matters most when the editor or a dragged-in folder is how you work, because then the daily copy is your history. Git tells you what changed and why, if your commit messages are honest. A daily copy just gets you back to a day that looked right, fast, without needing to remember which commit that was.
Worth knowing
Restoring brings back the site itself — every page, image and style exactly as it stood on the day you picked. Everything around it stays put: your domain keeps pointing where it points, your DNS records are untouched, your billing carries on unchanged, and the padlock never lapses. That's the part people worry about, and it's the part a restore can't disturb.
Worth knowing
Every file in the site, captured once a day automatically — no setting to turn on, nothing to configure.
No. Your domain settings, DNS and billing sit outside the daily copy, so restoring an earlier version of the site leaves all of them exactly as they are.
Yes — pick any of the last seven days, as many times as you need.
Seven days, which covers the window where almost every mistake actually gets noticed — the morning after a change, or the week someone finally mentions it. Longer history is on the list as an add-on, and it'll be priced the same flat, small way everything else here is.
Push again with Git, a zip, the CLI, or your assistant — included on every site at every price point.