Recovering downpipes itself

There are two different things people mean by “losing downpipes”, and they recover in different ways. Your backed-up data is ciphertext in your own destination bucket, and it comes back with your offline break-glass key and the open reader, with neither the engine nor the vendor in the loop. This page is about the other thing: the downpipes environment, meaning the downpipe definitions, schedules, destinations, operator roles and policy that drive the backups. That state lives in one Durable Object inside your Cloudflare account, and if it is lost the backups stop even though the data survives.

The honest framing first, because it decides which case below you are in. downpipes writes a signed export of its own control plane into your destination bucket, so the configuration is recoverable, but the recovery is in-account, and some state is re-established rather than restored. What follows is what is backed up, then the two recovery cases, then what to keep offline so either case is possible.

What is backed up, and where

On a change, the engine writes a signed export of its control plane to every destination, under the reserved prefix _RECOVERY/CONTROL-PLANE/, as a timestamped object with a detached signature beside it. By default the export is sealed: its body is encrypted to the same recipients your backups are sealed to (the break-glass key, and the operational key when you run the two-recipient posture), so a destination-bucket reader sees only recipient fingerprints and a small header, never the operator roster or the topology. A sealed generation has a .sealed.json suffix. Each export is a new immutable object rather than an overwrite, so older generations survive alongside the newest. The archive reader never parses this namespace; it is a separate artefact from your backups.

The export is no-custody by construction. It carries your configuration and non-secret metadata, and it never carries a plaintext secret: an account credential rides only as an envelope encrypted to a key that survives the wipe, or as a marker that the secret must be re-entered. A stored export that carried any plaintext secret is refused on the way in.

What returns, and what you re-establish

The distinction matters when you plan a recovery, so it is set out plainly rather than implied.

Nothing in the export is a decryption key for your data, and the session signing key, the recovery-code hashes and passkeys are deliberately never exported, so a recovered environment always re-authenticates its operators.

Case 1: the scheduler was wiped, the account survived

This is a lost Durable Object with the Worker and its secrets intact, for example after a storage fault. The engine detects it (the configuration is empty but the bucket holds runs), latches a recovery-required state so the first caller is never silently promoted to owner, and raises a standing banner in the console. Its scheduled health pass also stages the latest signed export and resumes the backups automatically, while holding operator authority behind a break-glass confirmation.

To complete the recovery, an owner opens the console recovery form, pastes the export JSON and its detached signature pulled from the destination bucket, and authorises with the break-glass ADMIN_TOKEN. The engine verifies the signature against its own pinned signer before it touches any state, re-asserts the no-custody check, and rebuilds. Because it is the same engine, the signer that wrote the export is the signer that verifies it. The break-glass ADMIN_TOKEN it asks for is the bearer you set as the engine’s own Worker secret at deploy time; a scheduler wipe leaves the Worker and its secrets intact, so it is still configured, and it authorises the rebuild because the wiped role table can promote no one to owner in the meantime.

One dependency is worth knowing in advance. The automatic resume needs a destination it can find, which means a destination declared at deploy time, not one that existed only in the console. A console-only destination lived in the state that was wiped, so there is nothing to read the export from until you re-enter it. If you want the hands-off resume, declare at least one destination in your deploy configuration.

Case 2: the whole Cloudflare account is gone

This is the worst case, and it is honest about where the time goes. Your data is recoverable throughout, because it never depended on the account: with the offline kit you can verify and restore from the surviving bucket at any point, independent of everything below.

Recovering the environment means rebuilding the engine in a fresh account and re-entering the configuration. That rebuild begins with the one deliberate command-line step downpipes has, so it is a developer task, not a console task, and its prerequisites are the slow part:

• A fresh Cloudflare account on the Workers paid plan, with R2 and Durable Objects enabled. Account and plan activation is not instant.
• A custom domain for the console, with DNS you provision and let propagate. The console is not served on a shared hostname.
• A trusted machine with Node.js and wrangler authenticated, to clone the repository and run the deploy.
• The offline reader, built from source, only if you also need to restore the archived data itself on that machine rather than through the rebuilt console. Recovering the configuration below, plaintext or sealed, stays in the console; the reader is not needed for it.

Be precise about when the sealed generation matters at all, because it is easy to over-read. The sealed export is opened by a dedicated config-recipient key that opens that export and nothing else, and your engine holds it in either posture, so an engine that lost its Durable Object storage but kept its own secrets auto-recovers its configuration on its own. That is true whether or not you hold an operational key. What matters below is the case where those secrets are gone too: recovering into a fresh account, where the new engine’s keys were never recipients of the old export and your offline break-glass identity is the way in.

With the engine rebuilt and the first Owner signed in, open Settings, Backup configuration, “Recover an estate from a signed export”. Paste the signed export you pulled from _RECOVERY/CONTROL-PLANE/ in your surviving bucket and its detached signature. If the export is plaintext, also paste the signer.pub from your recovery kit and the console sends it to the engine to verify. If it is sealed (the default, a .sealed.json file), paste it as-is: the console verifies the signature and unseals it in your browser using identity.key, or a reassembled M-of-N quorum of it, entered into the same form. Either way your break-glass key never leaves the browser, and only the recovered, verified definition is sent on to the engine. The engine trusts the export against your own signer key, so a fresh engine accepts it without the old account, and imports the definition: your downpipes, destinations and discovery selection. It imports no operator access. Because the export came from a different Cloudflare account, the imported downpipes arrive disabled, since every native resource identifier in the export belongs to the old account and must be re-pointed first.

If you hold the break-glass key as M-of-N shares, the same console form reassembles a quorum of them in your browser rather than asking you to write a complete key to disk first. See split custody.

Then re-establish what the import deliberately leaves to you, using the export’s re-establishment list as the checklist: re-grant operator roles by hand, reconnect identity providers, re-enter the credentials the export marked for re-establishment, re-enrol passkeys, re-point and re-enable each source, and re-activate the licence. The import rebuilds the shape of the estate; you restore its authority and its secrets deliberately, so a stale or hostile export can never hand back access or a credential on its own.

The honest recovery time is hours, not minutes, and it is dominated by standing up the fresh Cloudflare account and its DNS rather than by downpipes. Plan the drill and the expectation around that.

What to keep offline so either case is possible

Keep the recovery kit from the key ceremony offline and intact: the break-glass identity.key, the signer.pub that verifies your archives and your exports, and the recovery sheet. That kit is what recovers your data with no account at all, and it is the material a rebuilt engine needs to trust old artefacts. Treat it as the crown jewels, because after a full loss it is the only thing that was never in the account.

It is also worth keeping a recent copy of the control-plane export itself, so your configuration inventory travels with the kit rather than depending on later access to the bucket. A drill from the console is how you confirm, on a calm day, that the kit and the export are both current and both work.

Last updated 3 August 2026.