Quickstart: connect a source, set a destination, run your first backup, and prove it

This is the shortest path from a freshly deployed console to a first backup you have proven recoverable. It follows the water-path order the console itself enforces: make your keys, choose where backups go, connect your account, pick what to protect, then prove it. Each step names the screen it happens on, the role it needs, and how the console verifies the step for you so you are not left guessing.

The page is written for the Owner doing the first run. You will not run a terminal command anywhere on the customer path. The console performs every privileged operation itself: it collects a scoped token in the browser and the engine does the privileged work. The single operator command in this whole journey is the deploy itself, npm run deploy, which you run once before any of this to put the engine and console in your account. After that, everything below happens in the portal.

The five steps at a glance

The console derives this same order from the engine’s facts, so a deployment that already has some of it in place skips ahead automatically. The five steps are the setup-progress model: keys, destination, connect, sources, then the first downpipe. The first incomplete step is where you land.

1. Make your keys (first-run carousel, Owner)

   Open the first-run carousel. It generates your keys in your browser, locally, and nothing is sent anywhere during generation. When you click generate, the ceremony runs runKeyCeremony in the tab and immediately offers the files for download.

   

   Before you generate, the carousel makes you choose a key posture: strict break-glass-only, which leads the fork and needs no further action to keep, or add an operational key as a deliberate opt-in. You must pick one and tick the acceptance statement for your choice before the card lets you continue. Keeping the break-glass-only posture downloads four files plus a recovery sheet; choosing to add an operational key downloads a fifth file, operational.pub. Two of them are yours to keep, for different reasons. identity.key is your break-glass private key, the only thing that can decrypt your backups: keep it offline and remove it from the machine. signer.pub is a public key that decrypts nothing, but the offline reader will not verify or restore a run without it, so keep a copy of it too. The rest is public material your engine needs and you do not have to hold:

   File	Role	What it is
   identity.key	Keep offline	Your break-glass private key. The only thing that can decrypt your backups. Never installed to the engine.
   recipient.pub	To engine	The public half of the break-glass key. It cannot read anything; the engine uses it to lock new backups.
   operational.pub (only if you chose to add an operational key)	To engine	The public half of the operational key. Absent under the default, break-glass-only posture.
   signer.pub	To engine, and keep a copy	The public half of your signing key. The engine needs it, and so do you: an offline recovery refuses to run without it, and no copy of it survives in the archive or on the sheet. It decrypts nothing, so keep it with the recovery sheet.
   signer.key	To engine	Your signing key. It proves each backup is genuine but cannot read your data.
   recovery-sheet.txt	Keep offline	A printable record of your public fingerprints, with no secret on it. Keep it with identity.key and signer.pub.

   Install the keys to the engine with one click. There is no terminal step. You paste a one-shot Cloudflare token, the engine uses it to write its own secrets, and then you revoke it. The break-glass private key is never installed: there is no field and no path that uploads it. The carousel will not let you continue until the engine reports the keys are present.

   An operational key is opt-in, not the default

   By default the engine holds nothing that can decrypt your backups: strict break-glass-only is the posture a new customer gets unless they deliberately choose otherwise at the tradeoff card. You can instead give the engine an operational key that lets it test-restore your backups on its own, which means it can decrypt them, and so could anyone who broke into your Cloudflare account; that is the trade you are accepting if you opt in. Switch posture later from the Keys screen at any time; adding an operational key afterwards needs no re-key, but removing one does not retroactively protect archives it could already read. The vendor holds nothing in either posture.

2. Choose where backups go (Destinations, Owner)

   Go to the Destinations screen and point downpipes at a bucket you own. The destination is the one piece of the pipeline you bring; everything else flows from bindings, and nothing can run without it, so it comes before you even connect a token. Setting it is Owner-only, enforced by the engine.

   The form is R2-first. The endpoint is derived from your account id and the region is fixed to auto, with an S3-compatible variant if you back up to an S3 endpoint instead. The single primary action is Verify and save, and the order matters: the console verifies the destination live before it stores anything. It verifies the destination is reachable and that the supplied credentials authenticate, then runs a real write probe; if any check is refused it returns the honest reason and stores nothing.

   Once saved, the destination is held in the scheduler Durable Object at runtime. There is no redeploy to change it, and a console-set destination always wins over the deploy-time configuration, which remains a fallback. The secret access key for an S3 destination is sent once, never persisted in the browser, and never re-displayed.

3. Connect your account (Sources, Owner)

   Go to the Sources screen. Until a token is set and nothing is bound, this screen is the connect form, because every later step reads through it: picking sources to protect, and browsing every account the token can see.

   Paste one read-only Cloudflare API token. That single token makes everything you own browsable. The token is stored in the engine’s Durable Object, verified live against your account, audited by who and when, and never re-shown after you submit it. It is sent once over the authenticated same-origin channel and is never persisted in the browser.

   One honest boundary the screen states plainly: bindings cannot cross accounts. The engine’s own account gets the full attach flow. Other accounts the token can see are listed read-only, by name, because a binding can only be added within the account the engine runs in.

4. Pick what to protect, then create your first downpipe (Sources, then Downpipes)

   Back on the Sources screen, tick the namespaces, buckets or databases you want to protect. downpipes backs up eight source types. Four are reached through Workers bindings: Workers KV, R2, Secrets Store and D1. The other four are read over the read-only API token: Cloudflare configuration, Worker scripts, Stream and Images. This step attaches the four binding-backed sources, which are the ones that need the copy-paste deploy below. Attaching them is one copy-paste deploy: the console generates the binding stanzas, you apply them, and the screen detects when the deploy lands through a bounded wait-for-the-deploy poll. When the engine adds the bindings it proves none of its own are dropped, applies the change, then re-reads to verify, and any doubt makes it refuse rather than write.

   Attaching sources stays Owner-only: the engine gates the attach call on the owner-exclusive keys.ceremony capability, absent from the Operator role, and the console disables the attach controls and shows “an Owner attaches sources” for anyone else. Creating the downpipe itself is the first action in this journey a non-Owner can drive: an Operator or higher can create a downpipe once the sources it needs are attached; the engine enforces the role on every call.

   Then create your first downpipe on the Downpipes screen. A downpipe is the route: a source, the destination you just set, and a schedule. Once it exists, the first backup runs.

   The effective schedule floor

   The console floors the schedule at Hourly, so the fastest cadence you can pick from the console is hourly. The engine dispatches due runs on a roughly fifteen-minute */15 cron tick, which is the effective floor on how often a run can start and is dispatch granularity rather than a cadence you set. So plan your recovery point around the hourly cadence you can schedule, and expect a due run to land within about fifteen minutes of its scheduled time. The floor is covered in full on engine architecture.

5. Prove it (Restore flow, Operator or higher)

   A backup you have not tested is a hope, not a recovery plan. Prove the first one by running a drill, also called a restore test, from the restore flow. The drill is an engine-side completeness check plus an anti-rollback attestation: the engine confirms the run is whole and that it has not been silently wound back to an older state.

   Be precise about what this proves and what it does not. The drill runs on the engine, in your account. It is not a client-side check, and it is not a Cloudflare-side check. The signed reports you can produce afterward are tamper-evident, signed with the post-quantum hybrid scheme, but they are not verified in your browser: the verifying public key is not shipped to the browser, so full verification is out of band. To verify a report or an archive end to end against your own signer, away from any live system, use the offline Go reader. See proving recoverability for the drill in full and the restore flow for an actual restore.

   What this quickstart does not cover

   Two things sit outside the first backup-and-restore flow on purpose. Point-in-time recovery, the restore screen’s calendar that marks the days holding a retained run, is not part of this first walkthrough: show your recovery point as the newest good run rather than picking a particular day. And Cloudflare configuration restore is a separate, out-of-band path: only 60 of 313 config surfaces auto-restore in-band, and it is not part of this flow.

What just happened

When that first downpipe ran, the engine did the same four things it does on every run. It read the source records through your read-only token. It encrypted them with post-quantum hybrid sealing, a hybrid KEM combining X25519 and ML-KEM-1024. It signed the run with the hybrid signing scheme so the archive proves genuine. Then it wrote the result to your own bucket as a downpipe/0.1.0 archive. The vendor saw none of it, because the engine never sends data or a Cloudflare token to the vendor.

The run master is always wrapped to your offline break-glass key, the one the engine can never unwrap. In the two-recipient posture the engine also holds a decryption-capable operational key, so a full compromise of your live account can read past archives until you switch to the strict break-glass-only posture. The drill in the last step is what lets you confirm recoverability rather than take it on trust.

Next steps

Last updated 4 August 2026.