Skip to content
downpipes docs

What to expect: installing your first keys

Before downpipes can seal a single backup, your engine needs a set of keys. Installing them is a one-time ceremony you run once per engine. This page walks you through what each screen shows, what it means, and what to do, so nothing on the day is a surprise.

The whole ceremony runs in your browser. The one key that can recover your backups is generated on your side and is never sent to the engine or to us. That property is the reason the install has the shape it does, so it is worth keeping in mind as you go.

What you will do, in one line

You generate the keys in this browser, save the one recovery file the ceremony hands you, record the public fingerprints, then paste a one-shot Cloudflare token so your engine writes its own secrets. There is no terminal and no command to type.

  1. Generate your keys in the browser

    The Keys screen opens on the ceremony card. It states the one rule that governs everything else before you commit to anything: the private half of the break-glass key is the only way to recover your backups, and it never leaves your browser for the engine or the vendor.

    The Key ceremony card, with a collapsed key-posture custody disclosure and a primary Generate keys button.

    What it means. Leaving the posture disclosure closed keeps the default, which is now strict break-glass-only: your engine holds no key that can read an archive at rest. Open it and untick the box to add an operational key as well, which lets your engine prove your backups restore with nobody present. Either way the break-glass key generated here is what recovers your data, and you can add an operational key later from the Keys screen without re-keying.

    What to do. Select Generate keys. The key pair is minted in this browser tab; nothing is sent anywhere yet.

  2. Save your recovery key

    Generating the keys immediately downloads one file, identity.key, and swaps the card for a result view. That view is honest about where every file goes, laid out in three columns.

    A three-column custody legend: files that stay in this browser, files that go to your engine, and a vendor column that reads nothing.

    What it means. The Stays in this browser column holds identity.key, the break-glass private key. It is the sole recovery path, and there is no server-side copy: its loss is irrecoverable by design. The Goes to your engine column is the material your engine needs to do its day job, including the operational read-back key in the default posture. The Goes to the vendor column reads nothing, which is the whole point of the no-custody model.

    What to do. Move identity.key off this machine and store it offline, and keep the printable recovery sheet with it. That standing duty is the one thing no automated step can do for you. If you want to split the key across several holders so no single loss is fatal, do it now from the same screen.

  3. Record the public fingerprints

    The result view carries a Public key fingerprints section. The fingerprints identify which key is present on your engine, so you can confirm the right keys landed after the install without revealing any private material.

    Three public fingerprint rows labelled break-glass, operational and signer, each showing its full public fingerprint in plain text.

    What it means. These rows show the full fingerprints in plain text. They are public values, safe to record and share, so the capture shows them exactly as your own console does; only a real hostname or credential is ever replaced, and a fingerprint is neither.

    What to do. In your own session, copy each fingerprint onto the recovery sheet and into your runbook. You use them to verify the correct key is present on the engine once the install completes.

  4. Install to your engine, with no terminal

    The last section of the result view is the install. You paste a one-shot Cloudflare token, and your engine writes its own secrets: the signer private, the break-glass public, and the operational pair only if you asked for one. The break-glass private is never part of this step.

    A one-shot deploy-token field, an Install keys to your engine button, and a helper link on how to mint the token.

    What it means. The token is scoped to the Edit Cloudflare Workers template on the engine’s own account and is used once, never stored. Your engine performs the privileged write itself, so the key material does not pass through the vendor. Because the token grants real access, you revoke it straight afterwards on the Cloudflare API Tokens page.

    What to do. Follow How do I create the token? if you need to mint one, paste it, then select Install keys to your engine.

  5. Confirm the install landed

    The install writes engine secrets that settle over a few seconds. When it is done, the same section can re-check presence and report the signer and break-glass keys present on your engine.

    What it means. A completed install is observable, not just claimed. In the proving run the engine’s status settled to the expected shape for the chosen posture, with the signer and break-glass keys present, and the audit log recorded exactly one keys-installed event whose actor was you, the owner. That is the state a healthy first install leaves behind.

    What to do. Confirm the presence check reports both keys present, then match the fingerprints on screen against the ones you recorded. Once you have confirmed identity.key is stored offline, clear the in-memory key material from the browser tab.

After the ceremony

Your engine now holds the keys it needs, and you hold the one key it does not. Set where backups go on the Destinations screen, which is a separate no-terminal task. Keep identity.key offline and keep the recovery sheet with it; everything the platform can prove about recovery rests on that file being safe and on you being able to find it.

About this example

This page is generated from a live run, so its screenshots cannot drift from what the console actually renders.

  • Grounded in a proven behaviour. The walkthrough follows the first key install, tracked as G-P0-001 and recorded LIVE-PROVEN in the harness closure ledger: the recovery key is banked before the irreversible install, the install returns success, the engine status settles to the installed shape, and exactly one keys-installed audit event is written with the owner as actor.
  • Captured on a synthetic estate, net-zero. The four screenshots were taken during a real ceremony on a synthetic harness estate that is not any customer or public environment, using a disposable owner identity granted for the capture and torn down afterwards. The capture stops before the irreversible install: the keys are minted in the browser only, the downloaded identity.key is discarded, and no install is performed, so the estate stays keyless and unchanged by the capture.
  • Redaction replaces a value, it does not blank a box. These estates are synthetic, and a public key fingerprint is a value the console is built to show, so the fingerprints above appear in full just as your own console shows yours. Only a real hostname or credential is ever replaced, a hostname becoming example.downpipes.io and a credential becoming REDACTED, and the scan refuses to write any shot that still shows a real one.
  • And the redaction was checked, with a deliberate negative control. As a control, the fingerprint section was captured under the strict artefact policy, which does treat a fingerprint shape as sensitive: the scan refused it and wrote nothing, proving the gate is live rather than vacuous.

Last updated .