Quickstart: from a fresh deploy through setup to a first backup you have proven

This is the shortest path from a new console to a first backup you have proven recoverable. It follows the console’s own setup, which asks one question at a time and ends when your first backup seals. After setup, you prove the backup with a restore drill.

Each step names the setup step it happens on and who can do it. Each step also says how the console checks the step for you, so you are not left guessing.

This page is for the Owner who does the first run. It starts after the software is deployed.

The deploy itself is a command-line job and there is no route around it. npm run deploy runs once in the engine checkout and once in the console checkout. They are separate Workers in separate repositories, and both must be running before this page begins. The first deploy page is that procedure.

From here on, the portal does every action. You will not run a terminal command anywhere below. The console does each privileged operation: it collects a scoped token in the browser, and the engine does the privileged work.

The steps at a glance

A new console opens on setup at /setup. Setup reads each step’s state from engine facts, so a deployment that already has some of it in place skips ahead. First run and setup explains each step in full.

Have the three credentials ready, or be ready to make them when setup asks: a read-only API token, an access key for your backup bucket and a deploy token. Prerequisites says how to make each one.

1. Check your engine (Welcome, Owner)

   Open your console. On a new console, the first load opens setup at Welcome.

   Welcome checks your engine for you. When it says “Your engine answers” and shows the engine version, press Start. If the check fails, Welcome names the cause and offers “Check again”.

2. Connect your account (Connect, Owner)

   Connect asks for one read-only Cloudflare API token. Choose how you made it: from the “Read all resources” template, or as the minimal token with five Read permissions. Set its expiry to 90 days or less. Your engine refuses a token with no expiry, or with a later one.

   Paste the token, then press Verify token. Your engine checks the token live with Cloudflare, stores it and audits who set it. It never shows the token again. The console sends it once over the authenticated same-origin channel and does not keep it in the browser.

   When the token sees more than one account, choose which accounts to list, and which account your engine runs in. Bindings cannot cross accounts, so the engine’s own account is where your keys and source bindings go.

3. Choose where backups go (Destination, Owner)

   Choose the provider: Cloudflare R2, S3-compatible, Google Cloud or Azure Blob. Destination providers compared gives one row for what each changes about the rest of the form.

   Pick or type the bucket. For R2, setup lists the R2 buckets in your engine’s account. Use a bucket that holds nothing else.

   For S3-compatible, Google Cloud and Azure Blob, setup then asks whether to lock each archive against deletion, and for how many days. R2 cannot lock objects, so R2 skips that question.

   Paste the access key, then press Verify and save. The order matters. Your engine checks that the bucket is reachable and that your key authenticates, then writes a test file and reads it back. If any check is refused, it shows the 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 key is sent once, never kept in the browser and never shown again.

4. Pick what to protect (Protect, Owner)

   Tick the namespaces, buckets, databases, secrets and account surfaces you want to protect. Each group has an All or None button.

   downpipes backs up eight source types. Four are reached through Workers bindings: Workers KV, R2, Secrets Store and D1. The engine reads the other four over the read-only API token: Cloudflare configuration, Worker scripts, Stream and Images. The four binding-backed sources need a binding on the engine, which Apply adds for you.

   For a resource your token does not list, use Add a resource by its id. It joins the list, ticked, and its binding attaches at Apply.

5. Make your keys (Keys, Owner)

   This step is for an engine that has no keys yet. When your deploy made your keys, Keys says “Your engine already holds keys”. Press Use these keys and go on to Apply.

   Keys first asks who can decrypt your backups. The two postures sit side by side with no default, and “Offline key only” comes first. An operational key is a deliberate opt-in.

   Choose one, read its statement, and tick “I have read the implications and understand my choice.” Press Confirm offline key only or Confirm operational key. Your engine records the statement. Choosing your key posture quotes both statements in full.

   Next, choose where your offline key will live: a corporate password manager, an encrypted USB drive plus a paper companion, or an M-of-N custodian split. Your first recovery sheet records this choice.

   Press Make my keys. The keys are made in your browser, and nothing leaves it while they are made. The key ceremony runs runKeyCeremony in the tab and downloads every key file at once, identity.key first.

   A browser can block part of a burst of downloads. The file list marks any file your browser did not save, and offers each one again. Continue waits for any file your browser refused.

   Read the next sentence before you close that tab, because this is where the step goes wrong. Check that every file, identity.key above all, arrived before you go on. Leaving setup or reloading the page clears the keys from the tab. The only way back is then to make a new key set.

   Two of the files are yours to keep, for different reasons. identity.key is your break-glass private key. It decrypts your backups, even without your engine. Keep it offline and remove it from the machine. signer.pub is a public key and decrypts nothing, but the offline reader will not verify or restore a run without a pinned signer. Keep a copy with your recovery sheet.

   From engine 0.3.6, your bucket also holds a copy of the current signer’s signer.pub. From reader 0.3.4, the signer fingerprint on your recovery sheet can pin that copy. Every run overwrites the copy. A bucket from an older engine has none, and after a re-key the copy is the new signer’s. In those cases, identity.key alone leaves you unable to restore, and nothing tells you so until the recovery you needed it for. 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. It decrypts your backups, even without your engine. 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 an operational key)	To engine	The public half of the operational key. Absent under the offline-key-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 a pinned signer. From engine 0.3.6 the bucket holds a copy of the current signer’s key that the sheet’s signer fingerprint can pin. A bucket from an older engine has none, and after a re-key the copy is the new signer’s. It decrypts nothing, so keep it with the recovery sheet.
   recovery-sheet.txt	Keep offline	A printable record of your public fingerprints and your custody choice, with no secret on it. Keep it with identity.key and signer.pub.

   Move identity.key off this computer, the way your custody choice says. Tick “I moved identity.key off this computer.” and press Continue. With the split, setup asks you to make the custodian shares first. Check identity.key is optional: it reads the file in your browser, compares it with the key made here, and uploads nothing.

   Some keys are not files, because Apply installs them straight to the engine. SIGNER_PRIVATE is your signing key. It proves each backup is genuine but cannot read your data.

   Two configuration keys go with it. CONFIG_RECIPIENT_PRIVATE lets your engine rebuild its settings from its sealed configuration export. CONFIG_WRAP_KEY encrypts the credentials you save in this console. Neither can read a backup.

   An operational key is opt-in, not the default

   The posture question has no default, and the offline-key-only posture comes first. Under it, the engine holds nothing that can decrypt your backups.

   You can instead give the engine an operational key. It then test-restores 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 accept if you opt in.

   Switch posture later from the Keys screen at any time. Adding an operational key afterwards needs no re-key. Removing one does not retroactively protect archives it could already read.

   npm run deploy asks the same question before it generates any key, and keeps break-glass-only on a bare Enter or when no terminal is attached. On either path, an engine reaches the two-recipient posture only when someone chooses it.

6. Apply your keys and sources (Apply, Owner)

   Apply installs your keys and attaches the binding sources you picked, with one deploy token. There is no terminal step.

   Make the token in the Cloudflare dashboard from the “Edit Cloudflare Workers” template, limited to this account. Add D1 Edit if you picked a D1 database, and Secrets Store Edit if you picked a Secrets Store secret. Set the shortest expiry.

   Paste the token and press Install and attach. A passkey check may follow. A live checklist shows each stage with its time: your engine installs the keys, loads them, attaches your picks, then confirms each binding is live.

   The engine proves the attach drops none of its existing bindings, applies the change, then re-reads to verify the result. Any doubt makes it refuse rather than write. Your engine never installs the break-glass private key; no field and no path uploads it.

   Attaching sources is Owner-only. The engine gates the attach call on the owner-exclusive keys.ceremony capability, which the Operator role does not have.

   You can use your own wrangler login or CI instead, with no token. Choose My own wrangler or CI on the same step. It lists the secret commands, the binding stanzas and the deploy command. After you deploy, press Check my engine.

   Revoke the token next. Your engine did not keep it. Delete it in the Cloudflare dashboard, tick “I revoked the deploy token.” and press Continue. If you choose Remind me at the end instead, the reminder stays on the receipt and on Overview until you tick it.

   Connect and Destination saved two credentials before your keys existed. When the key install puts CONFIG_WRAP_KEY in place, your engine encrypts them, and the receipt says so. On the own-wrangler route, or when the engine’s answer carries no report, the receipt asks you to save them again. First run and setup has the detail.

7. Run your first backup (First backup, Operator or higher)

   Each pick becomes a downpipe. A downpipe is the route: a source, the destination you just saved, and a schedule. You can rename a downpipe that backs up one resource.

   Choose the schedule. Setup selects Daily, and recommends it. Check the retention and the restore tests. Under the offline-key-only posture, your engine keeps every run until you prune it yourself, in the console or with the offline reader. You run restore tests yourself, with your key.

   Press Create and run now. The run view shows each stage your engine reports. It ends on “Sealed and verified”, or on “Sealed, seal not verified” when your engine has verify-at-seal switched off. A failed run shows the engine’s reason and Run it again.

   Creating the downpipe is the first action in setup that a role below Owner can drive. An Operator or higher can create and run a downpipe once the sources it needs are attached. The engine enforces the role on every call.

   The effective schedule floor

   The interval presets start at Hourly. A cron expression in each downpipe’s editor can ask for more often, for example */15 * * * *.

   The engine dispatches due runs on a */15 cron tick of about fifteen minutes. That is the effective floor on how often a run can start. It is dispatch granularity rather than a cadence you set.

   Plan your recovery point around the cadence you schedule. Expect a due run to land within about fifteen minutes of its scheduled time. Engine architecture covers the floor in full.

8. Read your receipt (Finish, any role)

   Press See your receipt. Finish shows every decision you made, with its final value: posture, custody, destination, sources, schedule, the deploy token and the first run.

   The headline says “You are protected” only when your engine has sealed and verified your first run and no item is still open. An open item, such as a deploy token not confirmed revoked, sits on the receipt with the action that closes it. Finish also says that a sealed backup is not yet a proven restore: Overview lists it as not proven until a restore test passes. Print receipt prints it.

   Three optional steps follow: invite your team, choose restore approval, and review hardening suggestions. Each says what happens if you skip it. Press Open the console to go to Overview.

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

   A backup you have not tested is a hope, not a recovery plan. Prove the first one with 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 that the run is whole. The engine also confirms that nothing has silently wound the run back to an older state.

   Know 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 make afterwards are tamper-evident, signed with the post-quantum hybrid scheme. Your browser does not verify them. The verifying public key is not shipped to the browser, so full verification happens 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.

   The verify your installation checklist gathers this drill and the operator-side deploy checks into one ordered list. Use it if you want a single page to close out a new deployment.

   If you are the only person on this deployment, one thing has to be arranged now

   A passing drill is not the same as a restore you can complete. The product’s own default already closes most of that gap for a solo deployment. One real prerequisite remains.

   An in-console restore does not need a second identity by default. Dual control over a restore apply is an Owner opt-in. It is off until you turn it on. See dual control for restores.

   With it off, the apply route checks your capability, then a fresh passkey step-up, then the engine’s own integrity verify. The first is a capability check and the second is a cryptographic one. A solo operator applies on their own identity throughout.

   If you switch dual control on later, arming it needs two distinct Owner identities. The engine refuses to arm it while the estate holds only one, so you cannot lock yourself out of your own restore by accident.

   Do not read the Security Centre’s two-owners finding as a restore blocker. It is a general administration-continuity check: could someone else operate the account if you were unavailable? It is not a signal that restore needs a second person.

   The offline reader needs nobody’s approval, and you should not fetch it during a recovery. go install github.com/downpipes-io/downpipe/cmd/downpipe@latest resolves against the public module proxy. A plain git clone of the repository also works. Take your copy beforehand. The route then does not depend on the module proxy or on GitHub being reachable at the time.

   Get it now, build it once, confirm downpipe --help lists the full command set, and store it with identity.key and signer.pub. See getting the reader.

   Arrange the offline reader now. Under the default, the in-console route is already open to you alone. Either way, your archives stay intact and sealed to a key you hold.

   What this quickstart does not cover

   Two things sit outside the first backup-and-restore flow on purpose.

   Point-in-time recovery is the restore screen’s calendar that marks the days holding a retained run. It is not part of this first walkthrough. Show your recovery point as the newest good run rather than a particular day.

   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 the Worker’s bindings, and through your read-only token for the sources that have no binding. It encrypted them with post-quantum hybrid sealing, a hybrid KEM that combines X25519 and ML-KEM-1024. It signed the run with the hybrid signing scheme, so the archive proves genuine. Last, 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, and the engine can never unwrap that one. In the two-recipient posture the engine also holds an operational key that can decrypt. A full compromise of your live account can then read past archives, until you switch to the strict break-glass-only posture.

The drill in the last step lets you confirm recoverability rather than take it on trust.

Next steps

Last updated 26 September 2026.