What Cloudflare configuration is captured: surface reference

This is the reference list of every Cloudflare configuration surface the cf-config source captures. It is for an auditor or a self-hoster who needs the exact inventory rather than the narrative: which surfaces are in scope, whether each is zone-scoped or account-scoped, how each one restores, and which 60 re-apply in-band. For the credential model, the backup behaviour and the full restore workflow, read backing up and restoring your Cloudflare configuration.

The table below lists the same surfaces the backup adapter and the restore sink use.

The registry holds one set of 313 Cloudflare config surfaces. Of those, 60 auto-restore in-band, 228 have no write path and are backup-and-preview only, and 25 carry a writer that is off by default, so a default restore leaves them alone and reaches one only when the request names it. A default restore therefore writes back the 60 and none of the other 253. The restore tiers cut a different axis: idempotent 176, ordered 76 and re-provision 61. A surface auto-restores in-band only when it is one of the idempotent surfaces that also carries an in-band write path, so the 60 in-band surfaces are a subset of the 176 idempotent ones. The idempotent count is not a restore count: it is the number of surfaces that replay cleanly when applied, not the number downpipes applies.

How to read the table

Three columns carry the meaning, so here is what each one tells you.

The full surface list

These are the 313 surfaces, grouped by the same categories the console uses for its per-surface selection screen. The In-band column marks the 60 surfaces that re-apply on a restore apply that names no scope. Of the other 253, 228 are backup-and-preview only and 25 carry an off-by-default writer that a request has to name before it runs.

DNS & core

Security & WAF

Traffic & delivery

TLS & certificates

Email & logs

Account settings & rules

Account access

Account network

Alerting & Turnstile

Zero Trust

Data pipelines

Storage & data

The surfaces that auto-restore in-band

In-band re-apply means the engine writes the surface straight back into your live account through the console during a restore apply. That is 60 of the 313 surfaces. Each is an idempotent surface with a diff-driven write path, and a re-run of the restore converges rather than creating duplicates. The table below describes 13 of them, and the In-band column above marks all 60.

The in-band write is additive by design. It creates or updates only the items that differ, one at a time, and it never replaces a whole collection. It also never deletes a live item the snapshot happens to omit, so a live-only record is reported as left in place rather than removed. 228 surfaces are captured in full and verified recoverable, but restoring them is out of band and does not carry a diff preview, because they hold no write path at all: ordered surfaces re-created in dependency order, and re-provision surfaces rebuilt from their checklist, both from the verified snapshot. The 25 with an off-by-default writer do carry a diff preview once a request names them, and stay untouched until it does.

A further 25 surfaces carry a write path that is not in that 60. Those writers were generated from Cloudflare’s published API schema, which fixes the endpoint and the method but says nothing about which field identifies an item or which fields an update refuses, and both of those decide whether a restore writes to the right object. They are off by default: a restore that does not name a scope will not touch them. An operator who wants one names it explicitly. The named set is bound into the approval hash so an approver sees exactly which off-by-default surface they are authorising. They are counted separately here and never folded into the in-band number, because a default restore does not run them.

What is not captured

The scope is configuration, the settings of an account and its zones, not data and not runtime or analytics. The following are deliberately out of scope for the cf-config source.

How surface selection works

A downpipe stores the surface ids it captures in the source selector. Selection matches by exact surface id, not by a prefix, so the per-surface tick-boxes in the console capture exactly what was ticked. Two rules govern the rest.

An empty include list means all surfaces, so a downpipe that selects nothing is selecting everything in scope. And an account-only downpipe, one configured with no zone id, skips every zone-scoped surface and reads only the account-scoped ones; the zone-scoped rows above simply do not apply to it. From engine 0.3.6, the run’s coverage record names each skipped zone-scoped surface under the reason no-zone.

The backup is fail-open per surface. A surface the discovery token cannot read, because of a missing scope, a deprecated endpoint, or an endpoint that refuses the token’s kind, becomes an explicit unavailable marker rather than failing the run. A surface that a run reads and finds not on the plan also becomes a marker, flagged as plan-gated.

In Auto mode the daily discovery finds unused and plan-gated surfaces before the run, so the run does not read them. From engine 0.3.6, the run’s coverage record names each of them with its reason. The archive stays complete, with one record per attempted surface, and a marker is distinguished from a genuinely empty surface. Only if every attempted surface fails does the run fail loudly, because that means a broken token or the wrong account rather than a per-surface gap.

Two surfaces depend on the kind of Cloudflare token, not on its permissions. Page rules (page-rules) and zone device-policy certificates (zone-device-policy-certificates) are refused outright to an account token, whatever permissions it carries. Both read normally under a user token created from My Profile. Cloudflare answers the first with error 1011, “Page Rules endpoint does not support account owned tokens”, and the second with error 1039, “malformed actor email claim”, because an account token carries no user identity. No other surface in this table is decided by the kind; every other row turns on the token’s permissions, which a token of either kind can hold or lack. The credential model has the check that tells you which kind you hold.

Where this fits

• Backing up and restoring your Cloudflare configuration is the narrative home for the cf-config source: the credential model, the backup behaviour and the dual-control restore.
• What restore can and cannot write back covers the same tiered and out-of-band split across every source type.
• Cloudflare token scopes is the credential model: the read-only discovery token the backup reads with, and the separate edit-scoped token you supply per restore. The per-surface edit permissions themselves are enumerated on which permissions the edit token needs.
• The sources overview places cf-config alongside the KV, R2, D1, Secrets Store and Workers sources.
• Selectors and scope explains how include and exclude selectors work across all source types.

Last updated 25 September 2026.