Why back up Cloudflare: durability is not backup, and what downpipes does and does not cover
Cloudflare keeps your data highly durable. It does not keep you a backup. Those are different guarantees, and conflating them is how a team discovers, on a bad afternoon, that the redundancy it was relying on never protected against the thing that actually went wrong.
This page makes the coverage case explicit before you reach the trust model. It states why durability is not a backup, what downpipes captures today, and, just as plainly, what it does not capture, so no reader over-reads the scope. It is written for an evaluator who needs the boundary drawn honestly rather than implied.
The short version is that a backup is an independent, recoverable copy that you control, taken on a schedule and provable to restore. Platform durability is not that. The two protect against different failures, and you want both.
Durability is not backup
Cloudflare’s own redundancy keeps your data alive across hardware faults, disk failures and data-centre loss. That is real and valuable, and it is exactly what durability is for. What it does not do is undo a change you did not want.
Consider the failures that actually cause data loss in practice. A key deleted by mistake is still deleted on every durable replica. A bad deploy that overwrites a record is faithfully replicated in its corrupted form. A compromised account can erase or alter resources with full credentials, and the platform will dutifully keep the damage durable. Operator error, a fat-fingered bulk delete or a wrong-environment apply, lands the same way. None of these are hardware faults, so durability does nothing about any of them.
A backup is the independent copy that survives all of these, because it is held apart from the live account, taken before the damaging change, and recoverable on your terms. That independence is the whole point, and it is why downpipes runs the copy and its keys on your side rather than the vendor’s: a vendor outage or a vendor compromise can never cost you recoverability when the recoverable copy and the only key that universally unwraps it are yours. The custody argument behind that claim is set out in full in the no-custody trust model.
What downpipes covers today
downpipes backs up the Cloudflare data and configuration layer. It does not back up the compute layer, and the next section is exact about that line. What is covered today is the following.
| Covered | What it is | How it restores |
|---|---|---|
| Workers KV | Namespaces, keys and values, with each record’s metadata and expiration preserved | In-account restore, by the newest good run |
| R2 | Buckets and objects, with HTTP and custom metadata preserved | In-account restore, by the newest good run |
| D1 | A whole-database dump per database | Restore the dump into a fresh, empty database |
| Secrets Store | The value, sealed encrypted, plus its wiring (the store, the scope, the binding and the comment); the plaintext is never logged | The value is re-applied out of band, since the binding is read-only at runtime: downpipes recovers it and you put it back through the API |
| Workers | Captured for reference | Reprovision with guidance, not a one-click redeploy (see the boundary below) |
| Stream | Per-video metadata inventory, with the video file and caption tracks captured when content capture is enabled | Reprovision; with content capture, additive re-upload via the engine API (video gets a new uid) |
| Images | Per-image metadata inventory and the delivery variants, with the original bytes captured when content capture is enabled | Reprovision; with content capture, additive re-upload via the engine API, keeping the original id |
| Cloudflare configuration | 313 Cloudflare config surfaces across the zone and the account | Mixed, by surface (see the config backup and restore page) |
The configuration coverage is broad: those 313 surfaces span DNS records, the WAF and rulesets, page and firewall rules, Access and Zero-Trust apps and groups, load balancers, Email Routing, Logpush jobs, Turnstile widgets, and account members and roles, among others. The full per-surface list is in the Cloudflare config surface reference.
Two honest limits travel with this list and are worth stating here rather than in a footnote. D1 is exported by streaming, so peak memory is one row page of roughly two thousand rows plus the current sealed chunk rather than the whole database, bounded per page by a 96 MiB in-memory guard, with the streamed total bounded by the run’s segment and subrequest budget rather than a fixed database-size cap. The export reads through a single first-primary D1 session bookmark, which captures a torn-free, sequentially-consistent snapshot even under concurrent write load; the restore target is still a fresh, empty database, because the SQL-level dump is replayed into a clean one. And of the 313 configuration surfaces, only 60 carry an automatic in-band restore. The other 253 are backup-and-preview only: downpipes captures them in full and verifies they are recoverable, then an operator re-applies them out of band, following tier-specific guidance (dependency order, or a re-provision checklist) rather than the engine blind-writing them to production. A live diff against your account is specific to the 60 in-band surfaces. The deeper detail below states that split on both axes it can be read on.
The config restore path is built and wired in the console on the main branch, but it is not yet enabled on the live demo, which is supervised-first. The account scope is guarded: an apply into an account that is not provably the archive’s recorded origin is refused unless you type the target account id back. Treat config restore as a reviewed, operator-driven path, not an unattended one.
What downpipes does not cover today
This is the part to read slowly, because it is the boundary that stops a reader over-reading the scope. Everything in the table below is on the roadmap and is not current capability. None of it is imminent, and nothing here should be planned around as if it ships today. It is authored from the engine’s own coverage boundary, not from any marketing.
| Not covered today | Status |
|---|---|
| Workers script code, versions and bindings as a restorable redeploy | Captured for reference, but reprovision-with-guidance only, not a redeploy. Roadmap |
| Durable Object SQLite state | Roadmap |
| Queues | Roadmap |
| Vectorize | Roadmap |
| Hyperdrive | Roadmap |
| Pages projects | Roadmap |
| The downpipes Workers themselves | Roadmap |
Two points deserve emphasis. First, the compute layer is the headline gap: your Workers code and their bindings are not recoverable through downpipes as a redeploy yet, and neither is Durable Object SQLite state. Workers are captured, so you have the record, but a restore emits a reprovision checklist with guidance rather than redeploying the code. Second, the downpipes Workers are themselves part of the not-covered compute layer, which is consistent with the design: recovery never depends on downpipes’ own infrastructure being intact, because the offline reader and the open archive format recover your data regardless of whether the engine is running.
Why no-custody and self-hosted matter to the backup case
The reason downpipes is built no-custody and self-hosted is not a feature preference. It is what makes the backup do its job in the worst case.
A backup exists to survive failures of the systems around it, so a backup that depends on a vendor’s continued goodwill and uptime is weaker than one that does not. With downpipes the recoverable copy lives in a destination bucket you own, and the single key that universally unwraps an archive, the offline break-glass private key, is generated on your side and never transmitted anywhere. The vendor holds no customer data, no keys and no Cloudflare token, and there is no inbound path from the vendor into your account. So a vendor outage cannot make your data unreadable, and a vendor compromise cannot reach into your account or read your archives. The strongest thing a hostile vendor could do is withdraw the assurance layer, and that fails open: backups and recovery continue.
There is one honest caveat to state in the same breath, because the rest of the documentation states it plainly rather than burying it. In the two-recipient posture the engine also holds a decryption-capable operational private key, in your account, to support an in-account read-back path. That key is what lets a full compromise of your own Cloudflare account decrypt past archives through the operational path. The vendor still holds nothing, and break-glass recovery is unaffected because its private key is offline. If you want to remove the operational path entirely, the break-glass-only high-assurance posture omits the operational recipient, at the cost of in-account read-back. The full posture choice is set out in recovery postures, and the worst-case account-compromise analysis is in the threat model.
Deeper detail: the config restore split, and how a surface knows its own restore tier
The 313 surfaces, on two axes. The headline figure is exactly 313 Cloudflare config surfaces. On the coverage axis, 60 of them carry an automatic in-band restore (the engine reads the live config, diffs it against the snapshot, and applies only the differing items, additively, never a blind wholesale overwrite), and the remaining 253 are backup-and-preview only. On a separate classification axis, each surface declares a restore tier that explains why: 176 surfaces are idempotent (a setting PATCH, a ruleset PUT or a list create replays cleanly), 76 are ordered (they need dependency-ordered creation and id remapping, such as Access apps depending on groups and identity providers, or load balancers depending on pools), and 61 are reprovision (they carry write-only values such as certificate private keys, service-token secrets, identity-provider client secrets or tunnel secrets, so a restore can only emit a re-provision checklist). The 176-idempotent figure is the tier axis and is not the same number as the 60 that ship an automatic in-band write today. Idempotent describes how cleanly a surface replays when it is applied; it does not mean downpipes applies it for you.
Why the in-band writes are safe. The surfaces that do auto-restore in-band follow a strict contract. They never PUT a whole collection: each item is created or updated on its own, so one item the API rejects skips itself and never fails the rest. They are additive by default, so a live item the snapshot does not mention is left alone rather than pruned, because deleting live records the backup happens not to contain is destructive and is deliberately not the default. And they match items by a natural key rather than only the server id, so a re-run against a fresh zone converges instead of duplicating.
Secrets carry their value, encrypted, plus their wiring. A Secrets Store record’s restore descriptor carries the store, the scope, an optional comment, and for a per-Worker secret the Worker and the binding variable, while the value itself is sealed encrypted into the archive as the record’s value. A secrets restore is out of band not because the value is missing but because Secrets Store bindings are read-only at runtime: there is no in-account write path, so downpipes recovers the value and leaves you to re-apply it. The same descriptor mechanism is what preserves KV metadata and expiration, and R2 HTTP and custom metadata, so a restored record comes back with its metadata and TTL intact rather than value-only.
Where this fits
This page draws the coverage boundary. The proof of the custody claim it rests on, what is held where and why the engine seals to an offline break-glass key it can never unwrap, is the no-custody trust model. The adversary-by-adversary analysis, including the default-posture account-compromise residual named above, is the threat model. For how every claim on this page is held to precise wording, read precise claims and honesty.
Next steps
For the full list of source types and the capture and restore semantics of each, read what downpipes backs up. For the detail on the two sources with the most caveats, read D1 in depth and secrets and Workers. To see the whole product framed in a paragraph, return to the documentation home.
Last updated .