Skip to content
downpipes docs

Core concepts: the downpipes mental model

downpipes is a self-hosted backup and recovery engine that runs inside your own Cloudflare account. It backs up your Cloudflare data and configuration layer, encrypts every archive before it leaves your account, and writes the result to a destination bucket you own. The vendor holds no data, no keys and no Cloudflare token, and there is no inbound path from the vendor into your account.

This section is for an evaluator who wants to understand why downpipes is built the way it is before reading how to operate it. It explains the ideas; the procedures live in the Backing up, Recovery and Operations sections, and each page below links across to them.

The one idea everything hangs from

Most backup products ask you to trust that the vendor holds your data safely. downpipes is built so there is nothing to trust them with. Confidentiality, integrity and recovery each rest on something the vendor does not hold.

Confidentiality rests on keys the vendor never has. The running engine seals each archive to public recipient keys and can never unwrap one it wrote. The single key that universally unwraps an archive, the break-glass private key, is generated on your side and is never transmitted anywhere.

Integrity rests on a signature the reader pins to your own signer, not the vendor’s. A reader recomputes every hash and checks the hybrid signature against the signer you pinned, so a forged or altered run is detectable.

Recovery rests on an open on-disk format plus your offline break-glass key, with neither Cloudflare nor the vendor required. The open-source reader recovers an archive from the destination bytes and that key alone, regardless of what the engine is running.

Every assurance feature in downpipes is designed so its loss degrades assurance only, and never the backups and never the recovery. That single property is what the rest of this section unpacks.

The decision to make first

There is one choice that shapes your recovery story more than any other, and it is worth settling early: the recovery posture.

The default posture is strict break-glass-only: the engine holds no standing key that opens an archive, so a full account compromise yields no key that opens one. It does not cost you in-account read-back. Verify-at-seal still decrypts a sample of every run from the per-run master the seal path hands it, and the hourly canary still opens its own cell back the same way, neither of which needs a standing key. What stops is the unattended proof over past runs, which does need one: the drill, the scheduled restore test and the retention prune all defer with a reason telling you to rehearse offline.

You can instead opt into the two-recipient posture, which wraps every archive to your offline break-glass key and an operational key whose private half lives in the engine. The operational key lets the engine read its own backups back and prove they restore, without a person present. The cost is honest and disclosed: a full compromise of your own Cloudflare account would expose that operational key, and an attacker holding the destination bytes could then read past archives through it.

Both postures protect your data with the same break-glass key, so both are equally recoverable offline. They differ only in what the engine itself can read. Moving to break-glass-only never puts your data at risk, and it is the direction you can walk back: the Keys screen offers a targeted add that installs an operational key on its own, touching neither your break-glass key nor your signer, so returning is not a re-key. Adding an operational key is the direction that does not fully undo, because each archive is wrapped to the keys in force when it was written. That also sets the limit on the return: a later operational key opens only the runs sealed after it, so re-adding one does not restore unattended proof over your older archives. The full trade-off is set out in recovery postures.

The pages in this section

Read these in any order. Each is the canonical home for its idea and links out to the operational how-to.

No-custody trust model

What is held where, who can read an archive in the worst case, and why the engine can seal a run but never unwrap one it wrote. Includes the one honest caveat about the optional operational key.

Recovery postures

The two postures and their exact trade-off, why tightening to strict break-glass-only is data-loss-safe and reversible from the console with a targeted add, and why adding an operational key is the direction that does not fully undo.

The threat model

What each adversary can and cannot do, from a destination-bucket-alone leak to a full account compromise to a malicious update, with the residual risks stated plainly.

The key ceremony and recovery kit

The three keypairs the ceremony produces, where it runs, and what lands in your recovery kit, including the offline-custody duty that no automated step can do for you.

Anatomy of a backup run

How a backup happens end to end, from a cron tick through destination selection to a sealed, signed archive and the append-only run index.

The cryptography in one breath

You do not need the cryptographic detail to evaluate downpipes, but it is worth knowing the shape. The suite is post-quantum hybrid on both axes. Confidentiality uses a hybrid key encapsulation, X25519 paired with ML-KEM-1024, that stays secure if either half holds. Integrity uses a hybrid signature, Ed25519 paired with ML-DSA-87, where both halves must verify, so a forgery would have to defeat a classical and a post-quantum scheme at once and neither half can be stripped to downgrade an archive. Bulk encryption is AES-256-GCM, and the whole key tree derives from a fresh 256-bit per-run master through SHA-384.

What the engine can do with those primitives depends on the posture you choose, the same split the page below turns on. In strict break-glass-only the engine never decapsulates and cannot open any archive: it wraps a master to a recipient but holds no key to open the result, which is the cleanest cryptographic statement of no-custody. In the two-recipient posture the engine also holds a decryption-capable operational private key and uses it in-account to read its own backups back (the seal-time read-back check, the hourly canary, scheduled restore tests, in-console restores and the retention-prune pass), so the bound there is that it is the engine’s own key on your own account, never a key the vendor holds. The full primitive inventory, the key formats and the honest gaps live in the engine’s cryptographic inventory document, which the no-custody trust model summarises.

What this section does not claim

So that the ideas are not oversold, two clarifications belong here rather than buried.

The integrity guarantees are tamper-evident, not absolute. A reader detects a forged, swapped or rolled-back run; nothing prevents an attacker who can write to your bucket from deleting objects, which the completeness check surfaces loudly rather than letting pass silently.

downpipes does not make you compliant, and it carries no third-party certification. There is no SOC 2 and no ISO 27001 here; both are demand-gated, and any compliance material is a mapping of what the engine does, not an attestation. A backup product earns trust by being legible and recoverable, which is what this section is for.

Where this fits

When you have the mental model, move on to the doing.

Last updated .