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

1. The engine reports ready

Check GET /admin/status, or let the console’s setup 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 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 what the offline reader verifies one against. The engine cannot regenerate identity.key. From engine 0.3.6 and reader 0.3.4, the signer fingerprint on your recovery sheet can stand in for signer.pub for a run the current signer sealed. 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 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 Connect 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. The engine opens the run with its operational key, verifies its signatures and fails the drill if the destination’s RUNLOG has rolled back. It then decrypts up to eight sampled records in memory and checks the hash of each one. The result also says whether the run is still the latest for its downpipe. In the break-glass-only posture the engine holds no operational key, so the drill refuses and names attended verification instead.

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.

7. A restore can actually be completed by the people you have

A passed drill proves the archive is recoverable. It does not prove you can complete a restore, and for a deployment with one person in it those are different questions worth checking separately.

An in-console restore apply is dual control only if you have turned that on: it is an Owner-opt-in setting, off by default, and see dual control for restores for the full mechanic. Off, the engine gates the apply on your capability, a fresh passkey step-up and its own integrity verify, and a solo operator applies alone. On, the engine refuses the apply unless a usable approval exists for that exact plan hash, recorded by a subject other than the requester, and arming it in the first place needs two distinct Owner identities, which the engine also checks: a solo estate is refused when it tries, unless the caller is the bare break-glass token. The Security Centre’s two-owners finding is not this check either way; it is a general administration-continuity check (whether a second Owner exists to run the account), not evidence about restore specifically.

The offline reader is the route that needs nobody’s approval regardless of that setting. go install github.com/downpipes-io/downpipe/cmd/downpipe@latest resolves against the public module proxy, and a plain git clone of the public repository also works, but do not treat that as something to reach for on the day: the copy you recover with should be one you took in advance, so the route does not depend on the module proxy or GitHub being reachable during a real incident. Build it once, confirm the command set with downpipe --help, and keep it with identity.key and signer.pub. See getting the reader.

Tick this item once you hold the offline reader. A solo deployment can already complete an in-console restore under the default; the offline reader is what covers you if the console itself is not the route you can use on the day.

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, a drill has proven it recoverable, and there is a route by which someone can actually complete a restore. From here the work is routine operation rather than setup.

Last updated 25 September 2026.