Who downpipes is for: personas, the four-role model, and how to pick your path
downpipes is for the Cloudflare-native team that wants its own backup and recovery, held in its own account, with no vendor in custody of the data or the keys. If you run KV, R2, D1, Secrets Store wiring and a body of Cloudflare configuration, and you want an independent recoverable copy that a vendor outage or a vendor compromise can never cost you, you are the reader this product is built for.
This page maps the people who use downpipes onto the role model the engine actually enforces, so that later pages can say “an operator does this, an approver does that” without re-explaining the model each time. It is written for an evaluator deciding whether the product fits a team, and for anyone working out which role they will hold and therefore where to start reading.
The one thing to fix at the outset is what a role actually means, because the rest of the page leans on it: a server-enforced floor on what the engine will let an identity do, not a label on a screen. A person can wear several of the persona hats below, and the role they hold is simply the highest floor any of those hats requires.
The cumulative four-role floor
The engine resolves every authenticated caller to one of four roles, and the roles are cumulative: an owner includes an approver, an approver includes an operator, and an operator includes a viewer. Each step up adds power without taking any away. The engine decides every write against this floor, server-side, and the console only mirrors that decision so a control a role cannot use renders disabled with a stated reason rather than hidden then refused.
| Role | The floor it sets | Cannot do |
|---|---|---|
| Viewer | Read everything: posture, runs, the audit log, recovery state, costs | Make any change; raise or approve a restore |
| Operator | Everything a viewer can, plus run the day to day: create and edit downpipes, trigger runs, run drills, raise a restore request | Approve a restore (maker is not checker); set or replace a destination; install a key |
| Approver | Everything an operator can, plus approve a restore raised by someone else, and apply it | Approve their own request; the owner-reserved actions below |
| Owner | Everything an approver can, plus the destructive and custody actions: set or replace a destination, run the key ceremony, administer roles, switch posture | n/a (the highest floor) |
The destructive and custody-shaped actions sit at the top of this gradient by design. Setting or replacing the destination, for example, is owner-exclusive server-side, so the destination screen renders Verify now, Replace and Remove disabled-with-reason for any caller who is not an owner, and the engine refuses the write regardless of what the console shows. Owner is also the one role that can never be conferred by an identity-provider group: a group may confer any role except owner (viewer, operator, restore-operator, approver or access-admin), owner is always an explicit per-email grant, and a planted owner mapping is clamped down to approver.
The full built-in role set is six, not four. Two narrow roles, restore-operator and access-admin, hold a subset of owner rather than sitting on the cumulative ladder, and two capabilities stay owner-reserved. The four-role floor is the model to carry through the personas below; the exact six-role capability matrix is in roles and capabilities.
The six personas, and the role each maps to
There are six canonical personas. Each one maps to a role floor plus a job it is trying to get done. The mapping is one to one with the role model above, with two viewer-flavoured personas distinguished by what they read rather than by any extra power.
| Persona | Role floor | What they care about |
|---|---|---|
| Owner / break-glass holder | owner | A clean first run, the no-custody guarantee being real, role administration with a last-owner guard, posture and rotation |
| Recovery approver | approver | A clear pending-approval inbox, the exact blast radius of what they approve (the plan hash, the target, the record and byte counts), and a durable receipt naming both identities |
| Operator / SRE on-call | operator | Fast configuration, honest freshness and failure signals, a guided restore request, drills that produce evidence, and a topology view of what is protected |
| Auditor / CISO | viewer, reads everything | The tamper-evident audit log with chain verify and export, the honest audit boundary, and that no control is cosmetic |
| Finance / FinOps | viewer, plus the cost calculator | The throughput-based cost calculator, projected storage growth, the effect of retention and churn, and the zero-egress fact for R2 |
| Security reviewer / procurement | viewer or unauthenticated | The Access verifier reading the real verdict (never a hardcoded green), a demonstrable no-custody story, the strict content security policy, and precise claims |
The owner is the highest-trust, smallest group: they stand the platform up, run the key ceremony, hold the offline break-glass key, and wire secrets out of band. The auditor and the two finance-and-security personas all sit at the viewer floor and never write; what separates them is the lens they read through. A security reviewer is often looking at a fresh, unconfigured instance before any adoption decision, which is why the product is built to be honest before it is even configured.
Who it is not for
downpipes is a poor fit where the assumptions above do not hold. It is not for a team that wants a vendor to hold the data and the keys and take operational custody, because the no-custody design deliberately keeps the vendor out of that loop. It is not a general multi-cloud or on-premises backup tool: the source types are Cloudflare resources, captured in the customer’s own Cloudflare account. And it is not a compliance shortcut. No product on its own makes an organisation compliant, and downpipes does not claim to; what it provides is evidence and honest controls that an auditor can read, set out in compliance and evidence.
Roles gate controls, not the rail, and never access itself
The role model gates the write itself, not the navigation rail and not the router, and it is worth being precise about that because a casual reading of the console could mislead.
The navigation rail is not an authority boundary. A viewer sees every rail item, because a viewer genuinely needs to read the audit log, access status, run health and recovery posture. The rail can be curated for a custom role, so a screen that role hides drops out of the rail as a convenience, and a small number of action-only destinations (the config change inbox, for one) are shown only to a role that could act on them. That curation is presentation only. A hidden or locked item stays reachable by deep link and by the command palette for any authenticated role the engine permits, and the engine still enforces every action behind it.
The console router does not enforce access either. It resolves which screen renders and nothing more; it never checks auth or roles. Authentication is handled at the Cloudflare Access edge, and authorisation is decided by the engine against the role floor. So the two real enforcement points are the edge, which establishes who you are, and the engine, which decides what your role lets you do. Treat any rail hiding or screen locking you see as a tidiness affordance, not a security control.
Start here for your role
Pick the row that matches the role you will hold and follow it. Every reader benefits from the orientation pages first: why back up Cloudflare for the coverage case, then how it works for the shape of a run.
| If you are | Start with | Then read |
|---|---|---|
| An owner standing the platform up | Prerequisites and the quickstart | First run and setup, then the key ceremony and recovery kit |
| An operator running the day to day | Connect a source and connect a destination | Runs and history and the restore flow |
| An approver in dual control | Dual control | What restore can and cannot write back |
| An auditor or CISO | The audit log | Reports and compliance and evidence |
| Finance or FinOps | Cost prediction | Retention and pruning |
| A security reviewer or procurement | The no-custody trust model | The threat model and precise claims and honesty |
Where this fits
This page is the orientation that the rest of the documentation assumes. For the proof behind the property the owner and the security reviewer both care about, read the no-custody trust model, which sets out what is held where: the engine can never unwrap the offline break-glass key, and in the two-recipient posture it also holds a decryption-capable operational key. The posture choice is in recovery postures. For the exact power each of the six built-in roles carries, including the two narrow roles this page only names, read roles and capabilities.
Next steps
If the coverage boundary is your first question, read why back up Cloudflare for what is and is not in scope. To see the full list of source types downpipes captures and how each one restores, read what downpipes backs up. To return to the start, the documentation home frames the product in one paragraph.
Last updated .