What to expect: your first restore
A restore is the recovery journey walked end to end: you pick a sealed run to recover to, choose how wide the write goes, and read a dry-run plan the engine verifies before anything is written. Everything up to the apply is read-only. The apply is the one act that writes archived data back into your live account, and the engine does not roll it back. This page walks you through what each screen shows, so the day you actually need it holds no surprises.
The whole flow follows one rule: nothing is written until you have read exactly what would be written and a distinct second person has approved it. The dry-run preview is open to any role, so you can read the full plan without holding the authority to apply it. That property is the reason the flow has the shape it does, so it is worth keeping in mind as you go.
What you will do, in one line
You open the restore screen, pick the run to recover to and choose the blast radius, then build a dry-run plan the engine verifies read-only. Applying that plan is a separate, gated act that a distinct approver must sign, so reading the plan never risks a write.
Start the restore and choose the blast radius
The screen opens on a form that is pure input: it makes no engine call and writes nothing on its own. You name the run to recover from and choose how wide the restore reaches.
What it means. The blast radius is the key choice here. Restore to original bindings is the calm default, where each record returns to the source it was captured from. Redirect the whole run to one binding is the deliberate wider option, and choosing it escalates the later confirmation to type-to-confirm. The collapsed sections beneath narrow the scope instead of widening it: a single named record, key prefixes with a record cap, a D1 table-subset restored into a fresh database, and optional Cloudflare-config or media legs.
What to do. Leave the target on original bindings unless you specifically need a redirect. If you already know the run id, type it; otherwise pick one with Browse runs to pick one or Browse by date, described next.
Pick the point in time to recover to
Selecting a run is how you choose the moment you are recovering to. The picker lists your recent sealed runs, newest first, drawn from the bounded run-history ring.
What it means. Each row is one point in time, with its sealed status and how long ago it ran. Choosing a run starts nothing: it deep-links to that run’s dry-run plan, which is still read-only. Browse by date is the same history arranged as a calendar for when you are recovering to a particular day. You are never restoring to an arbitrary moment; every choice resolves to one specific run.
What to do. Pick the run that holds the state you want back. If the run you need has rolled off the recent ring, type its run id on the form instead, since a restore works from any run id, not only the ones listed here.
Confirm which sealed run you are recovering from
Opening a run shows its detail beside the flow, so you can confirm you have the right point in time before you build a plan.
What it means. The card names which downpipe the run belongs to and when it sealed, with the record and byte counts it holds. These are the run’s own figures, read from your history, so the size and freshness on screen are the real run, not an estimate. The status reads Sealed, ok for a clean run; a failed run is labelled as such and can still be drilled, or restored from a prior good run.
What to do. Check the run detail matches the run you had in mind, its downpipe and its age, then build the plan.
The dry-run plan: read before anything is written
Building the plan asks the engine for the restore with its write flag off, so the engine verifies the run without writing. It opens every in-scope record read-only and checks each record’s plaintext hash against the signed manifest, then reports what it found: how many records it verified, how many it would write on apply, an upper bound on the bytes, and whether this is the latest run or an older one. A sample of the resolved destinations shows where each record would land. Anything the engine cannot write back in account, such as a Secrets Store value or a Workers script, is listed as skipped with guidance rather than dropped silently. The plan closes on a precise statement rather than a reassurance: every record was opened read-only and its hash verified, and nothing has been written yet.
Because the dry-run writes nothing, the engine offers it to any authenticated role. You can read the entire preview on a view-only role and still be unable to apply it, which is the whole point of separating the reading from the writing.
The apply is the one gated act
The apply is the only step that writes archived data back, and it is never available on your role alone. The console mirrors the engine’s gate exactly: an apply needs the restore-apply capability and a dual-control approval bound to the exact plan, signed by a distinct person from the one who requested it. On a view-only role the confirm panel states this plainly, that you can preview the plan but cannot request or apply a restore. On a role that can apply, the button stays locked until a separate approver signs that same plan, and the engine verifies integrity in two phases before any byte lands, aborting the whole apply on a single failure rather than half-overwriting a live resource. The receipt then records how much was written and names both the applier and the approver who signed.
A restore cannot be undone
Once an apply begins writing there is no rollback. A cancel stops further writes but does not undo records already written. Read the dry-run plan carefully before you arm an apply, and prefer restoring into a fresh empty target where you can. This walkthrough stops at the preview and applies nothing.
Where this fits
The restore flow, end to end walks the same journey through to the receipt, including the dual-control request and approval. The mechanic that approval depends on, with the maker-is-not-checker rule, is dual control. For what a restore will and will not put back, in the in-account and out-of-band data classes, see what restore can and cannot write back.
About this example
This page is generated from a live run, so its screenshots cannot drift from what the console actually renders.
- Read live, as a least-privilege viewer. The three screenshots were taken from the real restore screen on a synthetic harness estate that is not any customer or public environment, using a disposable viewer identity granted for the capture and torn down afterwards. The read side of the restore flow is viewer-open, so a viewer is enough; no owner session and no key ceremony were involved. The run ids, source bindings and counts on screen are real values from that synthetic estate, shown in full just as your own console would show yours.
- The plan and the apply gate are described, not shown as a live figure. The dry-run plan and the confirm panel only exist after a request to the engine, which this capture deliberately never sends against real data. To describe them faithfully they were rendered once over a synthetic, redaction-safe plan fixture that never reached the engine, and that stub render is not shown here as a screenshot. What the plan verifies and what the apply gate requires are grounded in the deployed engine route and the restore flow page.
- Net-zero, and it was checked. The walkthrough only viewed the screens. No restore was executed, no request was raised, and nothing was written. A request spy on the browser session aborted and recorded every non-GET to the admin API and caught none. The posture score, every check’s status and the estate roster were read before and after the capture and were byte-identical. The disposable viewer’s role grant and passkey were removed at the end, and no recovery code was spent.
- Redaction replaces a value, it does not blank a box, and it was checked. These estates are synthetic, so the ids, key fingerprints, run values and counts you see are fake test data, shown in full just as your own console shows yours. Only two things are ever sensitive: a real hostname and a real credential. When one appears the capture replaces it in place before the shot, a hostname becoming example.downpipes.io and a credential becoming REDACTED, then scans the result and refuses to write any shot that still shows a real one. As a control, the shell engine host was captured with that replacement turned off: the scan refused it on the infra-hostname pattern and wrote nothing, which is the gate working as intended.
Last updated .