Before you start: Cloudflare account prerequisites and what you will need
downpipes runs inside your own Cloudflare account. Before the guided first run can finish, two things have to be true in that account, and only you can confirm them, because the engine cannot observe its own billing plan or whether R2 is enabled. Everything else that has to be in place, the scheduler, the reconciliation cron, the keys and sliced runs, the wizard verifies for you and shows you on the Ready step.
This page is for the Owner who is about to deploy and run setup. It separates the small set of manual checks you make in the Cloudflare dashboard from the larger set the console proves automatically, so the first run is a confirmation rather than a hunt. You do not run any terminal command to satisfy these prerequisites. You toggle two settings in the dashboard and then tick them off on the first card of the carousel.
The two required prerequisites
These two items gate the first card of the onboarding carousel. The carousel will not let you continue past them until both are ticked, because nothing downstream works without them. You enable each one once, in the Cloudflare dashboard, not from inside the console.
| Prerequisite | Why it is required | Where you turn it on |
|---|---|---|
| Workers Paid plan is active | Durable Objects and scheduled runs need it. The scheduler is a Durable Object and the reconciliation cron does not run on the free plan. About $5 a month. | Cloudflare dashboard: Workers and Pages, then Plans, then Workers Paid. |
| R2 object storage is turned on | Your backups are written to R2. Without R2 enabled there is nowhere for a run to land. | Cloudflare dashboard: R2, then Enable. |
A note on the second one, because it is the most common point of confusion. Enabling R2 is not the same as choosing where backups go. You do not create a bucket here. Enabling R2 simply switches the product on for your account. You pick the actual destination bucket later, on the Destinations screen, as part of the quickstart. Keep these two steps separate in your head and the rest of setup stays simple.
Why these two cannot be auto-checked
The console derives every other setup step from facts the engine reports about itself through GET /admin/setup-state. It deliberately cannot read your account’s billing plan or your R2 entitlement, so it asks you to confirm them rather than guessing. That is the whole reason the prerequisites card exists, and the only part of setup the engine cannot prove on your behalf.
Cloudflare charges you for what this uses
downpipes is free software and we take nothing from you, but it runs in your own Cloudflare account, so Cloudflare bills you directly. The Workers Paid plan above is a floor, not the whole cost: on top of it you pay Cloudflare’s ordinary rates for the Workers requests and Durable Objects the engine runs on, and for the archive storage itself, including the operations each run performs against it. Backing up more data, more often, and keeping it for longer all cost more, and a verify or restore reads those objects back.
We add no markup and see none of it. What downpipes itself costs is a separate and much shorter answer, on licensing and editions: Community is free forever, and a paid plan is quoted and invoiced rather than sold through a checkout. Work out what this will cost against Cloudflare’s own current rates, for the data you intend to back up, at the frequency and retention you intend to keep. Only you know your volumes, and Cloudflare’s rates are theirs to change, so we do not restate them here.
The console does project storage and read cost, but do not lean on it as your budget. It can only project once you have sources and a schedule configured, so it cannot answer this question before you commit, and it is a planning estimate rather than a spend cap. What it is genuinely good for, once you are running, is spotting read amplification and the cost of a retention change, which is covered in predicting storage cost.
The two optional add-ons that never block
The carousel lists two more items on the same card, and neither of them gates anything. They are there to acknowledge so you make a deliberate choice, not because setup stalls without them. You can tick them now, set them up later, or leave them off entirely.
| Optional add-on | What it gives you | When you would set it up |
|---|---|---|
| Cloudflare Access | Single sign-on or IP gating in front of the console. Free for up to 50 users. | When you want your identity provider, or an IP allowlist, in front of the console. In Zero Trust, create an Access application for the console’s address, then set the Access variables at deploy. |
| Outbound email | Lets the engine send alert, expiry and invite emails. | When you want notifications. Onboard your sender domain in the dashboard under Compute, Email Service, Email Sending, then set EMAIL_FROM at deploy. The walkthrough is on outbound email. Without it the console still works; it just cannot send notifications. |
Passkeys are a complete alternative to Access
You do not need Cloudflare Access to protect the console. Passkeys need no setup at all and are a full alternative for guarding access to the console. If you would rather not stand up an Access application, sign in with a passkey instead and skip Access entirely. Access and passkeys both protect the front door; you choose one, both, or, during evaluation, neither. The engine still enforces roles on every privileged call regardless of which front-door control you pick.
Optional means optional
The two optional items never stop the carousel. Only the Workers Paid plan and R2 gate the prerequisites card. If you are evaluating downpipes and want the shortest path to a first backup, tick the two required items, leave Access and email for later, and protect the console with a passkey.
What the wizard verifies so you do not have to
The manual checks above are the exception. The rule is that the console proves setup for you against the engine’s own reported facts, and shows you the result on the Ready step near the end of the carousel. You confirm the plan and R2 once, up front; the Ready step never repeats them, because they are not things the engine can observe.
The Ready step reads the engine status and its preflight, then lists the checks the engine can verify for itself. The five below are the ones you will always see; the engine also surfaces any other preflight item it has already verified or found failing, most commonly the run signer key and the recipient public keys as their own rows alongside the “Keys” line below.
| Auto-verified check | What it confirms |
|---|---|
| Durable Objects | The scheduler Durable Object is present and owns the schedule and the run lock, re-arming its own wakeup alarm with jitter. |
| The reconciliation cron | The coarse */15 cron is the dispatcher that starts due runs. The scheduler Durable Object’s alarm only re-arms the next wakeup; it does not dispatch. |
| The keys | The engine reports the signer and break-glass recipient keys present. |
| Sliced runs | The run pipeline can segment and pack a run, so a backup is constructible. |
| Sign-in | Whether you arrived through Cloudflare Access, a passkey, or the token fallback, named honestly rather than assumed. |
Where the engine has not yet observed one of these, the Ready step shows it as not-yet-done with a short reason, never as a false green. Coverage and posture follow the same honesty rule across the console: an unknown is shown as unknown, not painted green.
You are deployed into your own account
One framing that matters before you start: downpipes is deployed into your own Cloudflare account, and you reach the console on a custom domain you control. There is no shared service and no vendor-hosted address. The console talks only to the engine that sits in the same account, on the same origin, so during setup there is no separate host and no credential to enter to reach the engine itself.
Because the address is yours, examples in this documentation use a custom domain such as console.example.com. Your real console address is whatever custom domain you map at deploy time. You will never reach a working console at a workers.dev address; that is a build artefact, not a customer endpoint.
What to have on hand
When you sit down to run the quickstart, have these ready:
- Dashboard access to toggle two settings. The ability to turn on the Workers Paid plan and enable R2 in the Cloudflare dashboard. This is the only manual account work.
- A read-only API token to paste during Connect. The first thing the quickstart asks for is one read-only Cloudflare API token, pasted into the console on the Sources screen, so everything you own becomes browsable. See Cloudflare token scopes for exactly what to scope it to.
- A bucket you own, for later. You do not configure it now, but the destination step expects a bucket you control. You choose it on the Destinations screen during the quickstart.
- Somewhere offline to keep one file. The key ceremony produces a break-glass private key,
identity.key, that you keep offline. Have a safe place for it ready before you generate keys.
That last point is the one piece of preparation people skip and regret. The break-glass key is the only thing that can recover your backups on its own, the engine never holds it, and it is generated in your browser. Decide where it will live before you start, not after.
Where this fits
Run the quickstart
The hands-on task ladder from a fresh deploy to a proven first backup, in the console’s own order.
How the first run works
How the onboarding carousel gates and resumes, and how setup progress is derived from facts so it never locks a working console out.
Token scopes
What to scope the read-only discovery token to, and the separate one-shot token used to install keys.
The key ceremony
What the in-browser ceremony generates, the files it produces, and why the break-glass key stays offline.
What it costs
The commercial side of the same question: what downpipes itself costs, why there is no checkout, and how a paid plan is quoted and invoiced.
Last updated .