Verify your installation: the post-deploy checks in one ordered list
Every check on this page already exists elsewhere in these docs: the first deploy walkthrough ends on status and preflight, and the quickstart ends on a restore drill. This page adds nothing new. It consolidates those checks into one ordered list, so a fresh deployer has a single place to run down, top to bottom, and a definite point at which the installation counts as verified. Each item links to the page that covers it in full rather than repeating it.
Run the list in order. The early items are cheap and the later ones depend on them: a drill cannot pass before a first run has sealed, and a first run cannot start before the engine is ready.
The checklist at a glance
| # | Check | What proves it | Covered in full on |
|---|---|---|---|
| 1 | The engine is ready | GET /admin/status reports ready: true |
First deploy |
| 2 | The live prerequisites hold | GET /admin/preflight shows no red required item |
First deploy |
| 3 | The recovery kit is offline | identity.key and signer.pub are held offline, off the deploy machine |
The key ceremony and recovery kit |
| 4 | The bootstrap credentials are gone | The deploy token is revoked and the admin token is retired | Identity and access |
| 5 | A first run sealed clean | The run shows a clean verify-at-seal verdict on the Runs screen | Runs and history |
| 6 | The backup is proven recoverable | A restore drill passed | Prove recoverability |
1. The engine reports ready
Check GET /admin/status, or let the console’s onboarding read it for you. The engine reports ready: true once the signer is present, the break-glass public key is present, and a destination resolves. Status is a presence check, not a probe: a malformed key still reads present here, which is why the next item exists. The field-by-field meaning of the response is on the first deploy page.
2. Preflight shows no red required item
Where status reports presence, GET /admin/preflight probes the runtime prerequisites live: a real Durable Object round-trip, confirmation that the cron has genuinely ticked recently, a read-only existence check against the destination, a parse-check of the keys, and an enumeration of every configured source binding. Each item comes back verified, configured, unconfigured or failed, with the observed evidence and a remediation. Do not consider the deploy finished over a red required item. The probe, and the one item it honestly cannot observe from inside a Worker, are described on the first deploy page.
3. The recovery kit is offline
Confirm the recovery-kit/ folder is in offline storage and removed from the deploy machine. Two of its files are must-keeps for different reasons: identity.key is the only universal unwrap for your archives, and signer.pub is the only thing the offline reader will verify one against. Neither can be regenerated from the engine. The custody reasoning is on the key ceremony and recovery kit, and the offline recovery path that depends on this step is break-glass offline recovery.
4. The bootstrap credentials are revoked and retired
Two credentials exist only to stand the system up, and a verified installation holds neither. Revoke the scoped deploy token from the Cloudflare dashboard as soon as the engine is confirmed healthy; after that the system holds no Cloudflare API token that can write to or deploy your account (at most the optional read-only discovery token remains). Then, once your Owner passkey works (or Cloudflare Access is wired) and your recovery codes are saved, retire the one-time admin token from the Security Centre. The engine refuses to retire it until a way back in exists, so this step can never strand you. The procedure is on identity and access, and the token’s exact scopes are on deploy token scopes.
5. A first backup run completed clean
Create your first downpipe if you have not already; the quickstart walks the whole path from keys to a first run in the console’s own order. Then read the run on the Runs screen. A run is reported a clean success only after the engine reads the just-written archive back from your destination and verifies it, so a clean first run is already evidence the archive is whole, not just that an upload returned success. What the verdict means, and how to read the run detail, is on runs and history and verify at seal.
6. A restore drill passed
A backup you have not tested is a hope, not a recovery plan. Run a drill from the restore flow: an engine-side completeness check plus an anti-rollback attestation, confirming the run is whole and has not been silently wound back to an older state. Which recovery-assurance verb fits your key posture, and what each one does and does not prove, is set out on prove recoverability; an actual restore is the restore flow.
When the list is green
At this point the installation is verified: the engine is ready and probed, the only keys that matter are offline, no bootstrap credential is left standing, a real archive has sealed and been read back clean, and a drill has proven it recoverable. From here the work is routine operation rather than setup.
Schedule and retention
Set how long copies are kept and how older runs are pruned without losing your safety floor.
More destinations for 3-2-1
Add destinations so a copy survives the loss of any one of them.
Monitoring and notifications
Wire the day-2 signals so a failed run is loud rather than discovered late.
Verify a release
The separate, deeper exercise of verifying a downpipes release itself against the signed channel.
Last updated .