Back up your entire Cloudflare account: what a complete copy takes, and where partial exports stop

Cloudflare runs the platform, and runs it brilliantly. The configuration you put into it, your zones, WAF rules, Workers and secrets, is yours: you created it, and keeping a copy of it is your side of the line. Cloudflare gives you export tools and an API for exactly that reason.

This page is about actually doing that, for the whole account rather than a corner of it. It lays out what a complete Cloudflare estate contains, why the common partial exports cover less of it than they appear to, what the do-it-yourself routes genuinely give you, and how downpipes captures the estate inside your own account. If you want the prior question, why platform durability is not a backup at all, that case is made on why back up Cloudflare.

What a complete Cloudflare estate contains

An account that has been in production for a while holds far more than its DNS records. The estate spans four layers, and each fails differently when it is lost.

The configuration layer is the one teams most often discover they never had a copy of. It accretes over years of dashboard changes by many hands, it is the layer a bad change or a compromised account rewrites first, and almost none of it is in the exports people assume cover it.

Why partial exports miss things

None of the routes below is a bad tool. Each one is good at exactly what it says it does, and the trouble starts only when it is quietly promoted to being the account’s backup.

A BIND zone export is DNS, and only DNS

The dashboard’s zone file export gives you a BIND-format file of one zone’s DNS records. That is a genuinely useful artefact, and for plain DNS it is the standard interchange format. It is also the whole of what it is: one zone, records only. Your WAF rules, your Access policies, your Workers routes, your load balancers and everything account-scoped are outside it, and Cloudflare-specific attributes with no BIND representation need separate handling. A drawer of zone files is a DNS backup, not an account backup.

Terraform covers what was codified

If you manage Cloudflare through Terraform, your configuration lives in code and your state file describes the managed resources. That is a strong position, and if you are there, stay there. The gap is coverage: Terraform knows about the resources someone codified, and production accounts accumulate resources nobody did. A rule added in the dashboard during an incident, a tunnel created by a contractor, a widget an intern set up last year: none of it exists in state until someone imports it, and nothing warns you about the difference. Cloudflare’s own cf-terraforming tool exists precisely to close that gap by generating configuration and state from a live account, and it does that well for the resource types it supports. What neither Terraform nor cf-terraforming addresses is the data layer: state describes your KV namespace, not the keys and values in it, and your D1 database’s existence, not its rows.

Scripts capture what they enumerate

The small open-source Cloudflare backup scripts loop over API endpoints and save the JSON they return. They are honest tools, they are inspectable in an afternoon, and for a periodic snapshot of the endpoints they cover they work. Their boundary is that they capture exactly the endpoints someone taught them, so coverage silently lags the platform as it grows, and the operational questions around them are yours to answer: where the output lands and who can read it, how the long-lived API token they run on is stored, whether anything verifies the snapshot is complete and readable, and what the actual restore procedure is when you need one. A pile of JSON you have never restored from is in the same epistemic position as no backup: you find out whether it works on the day you need it.

The audit log is a record, not a rebuild

Cloudflare’s audit log will faithfully tell you what was deleted, when, and by whom. It records the deletion. It does not do the rebuild. Reconstructing a zone by hand from audit log entries is possible and slow, and having to do it once is the strongest argument on this page for keeping a real copy.

What a complete backup actually takes

Whichever route you choose, a copy of the estate that will hold up on a bad day has properties a folder of exports does not. It covers the configuration layer and the data layer, because losing either one takes production down. It runs on a schedule, because a copy taken once at migration time describes an account that no longer exists. It lands somewhere independent of the thing it protects, in storage you control. It is encrypted with keys that you hold rather than the tool’s operator. And it is proven restorable, on a rehearsal you can rerun, because an untested backup is a hope rather than a recovery plan.

How downpipes captures the estate

downpipes is a backup engine that runs as a Worker inside your own Cloudflare account and captures the estate from there. Eight source types cover the layers above: Workers KV, R2, D1 and Secrets Store are read through Workers bindings, and Cloudflare configuration, Worker scripts, Stream and Images are read through one read-only API token. The configuration source captures the 313 config surfaces from the table above, discovered from the engine’s own registry rather than a hand-kept list. The full capture and restore semantics per source are on what downpipes backs up.

Each run seals its archive with post-quantum hybrid encryption to keys generated on your side, signs it, and writes it to a bucket you own. The vendor holds no customer data, no keys and no Cloudflare token, which is the no-custody trust model in one sentence. Every archive is read back from the destination and verified before the run reports success, restore drills let you rehearse recovery on a schedule, and an offline reader recovers your data with no engine and no vendor in the loop. Restore for the configuration layer is deliberately honest about write-back: 60 of the 313 surfaces auto-restore in band, and the rest come back through preview and guided re-application, tiered per surface on config backup and restore.

Every feature is in the free Community edition; what is paid is support and procurement paperwork, per licensing.

One boundary, stated here so this page cannot be over-read: downpipes backs up the data and configuration layers, not the compute layer as a redeployable unit. Worker scripts are captured for reference and come back as a reprovision checklist rather than a one-click redeploy, Durable Object SQLite state is not captured at all, and queue messages, Vectorize index contents and Pages build outputs are captured only at the level of their configuration. The full boundary table is on why back up Cloudflare.

Choosing your route

These routes also compose. Terraform for change management and downpipes for recovery is a sensible pairing, not a contradiction: one governs how configuration changes, the other guarantees you can get all of it back.

Next steps

Last updated 9 August 2026.