How downpipe relates to the source-available engine
This page draws the line between what is open source and what is source-available in downpipes, so an evaluator can reason about durability and independence. The short version: the open-source repository is the reader plus the archive format it reads, the writing engine that schedules and seals archives is a separately licensed component, and recovery depends on nothing you cannot read, keep or rebuild yourself.
Two licences apply to the software you run, and the distinction between them is about what you may redistribute, not about what you may read. The open core is the downpipe repository, MIT-licensed and held by Maelstrom AI Pty Ltd. It contains two things and only those two: the offline reader, and the downpipe/0.1.0 archive format it reads.
The engine and the console are the paid platform that writes archives from a live Cloudflare account. They are source-available under the Elastic License 2.0, and nothing in the MIT repository depends on them to read, verify, or restore. If your security review needs to read what will run in your account before you deploy it, that is the licence that permits it, and deploying the engine and console is where that review starts. The control-plane that mints licences is neither: it is a vendor service, and the vendor provides its source to no one. Nothing on the backup or recovery path calls it.
This is the basis of the no-custody and durability story elsewhere in these docs. For how the licence and editions work, see licensing and the control-plane. For the limits on the security properties on this page, see security properties and their limits.
The boundary
| Component | Status | What it is |
|---|---|---|
The downpipe reader | Open source, MIT | The offline command-line tool that inspects, verifies, attests, and restores archives from destination bytes plus your own keys. From reader 0.3.4, it also verifies the signature on an assurance report that the engine generated. |
The downpipe/0.1.0 format | Open, fully specified | The on-disk archive format, normatively specified with conformance vectors in the MIT repository. Every archive carries a signed pointer to that specification and recovery instructions next to the data, not the full specification. |
| The writing engine | Source-available, Elastic License 2.0 | The in-account component that schedules runs, captures sources, and seals archives. A separate repository from the MIT open core, readable under its own licence rather than redistributable under MIT. |
| The console | Source-available, Elastic License 2.0 | The portal that drives the engine. A separate repository from the MIT open core, and not on any recovery path. |
The format is the part that matters most for independence. It is documented in full in the MIT repository, and every archive carries recovery instructions next to the data. A holder of the destination bytes, the offline break-glass key and a conformant reader can always recover. That holds even if the vendor disappears and even if the Cloudflare account is gone. The writing engine can wrap the run master to the break-glass recipient, but it never holds the break-glass private key, so it cannot unwrap that wrap. That is what keeps recovery in the customer’s hands.
Recovery depends on nothing the vendor controls
The reader on the recovery path imports no vendor SDK or telemetry. It reads two inputs and nothing else.
| Input | Source |
|---|---|
| The archive bytes | The destination bucket, read either from a local directory or directly from the destination itself with your own credentials: an S3-compatible bucket (R2, Backblaze B2, Wasabi, MinIO, AWS S3, Google Cloud Storage) over --s3-endpoint, or an Azure Blob container over --azure-endpoint. |
| The keys | The customer’s own keys, including a mandatory offline break-glass recipient whose private key is held offline by the customer and never reaches the vendor or Cloudflare. |
The local-directory backend makes no network call at all. The two network backends, S3-compatible and Azure Blob, make requests to the customer’s own bucket or container over HTTPS with the customer’s credentials. Both refuse plain HTTP except to localhost and refuse all redirects so a credential cannot leak to another host.
Every reading command (inspect, keys, verify, attest, restore) issues GET only, and keygen and selftest make no network request. prune --apply is the one command that writes to a destination. It issues a DELETE to remove a run your own retention policy has superseded, against the same customer bucket with the same customer credentials. The Azure backend implements no delete at all, so prune --apply refuses against an Azure container rather than issuing one. Neither backend reaches any Maelstrom AI or downpipes service. The whole recovery surface, keygen, inspect, keys, verify, attest, restore, selftest, prune, recombine and unseal-export, carries no path that calls home.
From reader 0.3.4, verify-report checks the signature on an assurance report that the engine generated, against your signer.pub. It reads the report from a local file or from standard input, and it makes no network request.
Azure Blob is reached by its own backend, and it is read-only
Independence from the vendor holds for all four destinations. Azure Blob Storage is not an S3-compatible store behind another host, so it is reached by a backend of its own rather than by --s3-endpoint: --azure-endpoint with --azure-container, authenticated from AZURE_STORAGE_KEY or AZURE_STORAGE_SAS_TOKEN in the environment. An estate whose only destination is Azure Blob has the same offline path as any other.
That backend is read-only on purpose. It carries the buffered fetch, the streamed fetch, the existence check and the listing, and no delete, so prune --apply against an Azure container refuses on the missing capability. Retention there is the engine’s job, which keeps the break-glass reader from being a tool that can destroy the last copy of the data it exists to recover. The per-provider detail is in destination providers compared.
The recovery path can fall back to no vendor or hosted service
There is deliberately no vendor service, no hosted helper, and no callback for recovery to depend on. The fallback is to keep the MIT reader alongside your recovery key, or to re-implement a conformant reader clean-room from the specification and the conformance vectors. Recovery is something you can do with the bucket bytes and your offline key on a machine with no internet, by design.
The licence gates nothing on backup or recovery
The licence model is an MIT reader plus an Elastic-2.0 platform. The MIT licence on the reader and format places no condition on backup or recovery: you may use, copy, modify, and redistribute the reader, and you may re-implement the format from the specification. The Elastic License 2.0 on the engine and console is a different bargain: you may read the source and run it in your own account, and what it withholds is the right to offer the platform to others as a hosted service. Buying an Enterprise edition does not unlock a recovery feature or a format capability, because recovery already depends on nothing the vendor controls. An Enterprise relationship buys human services and support, not a feature unlock that the open path lacks. The licence gates no feature of the paid platform either, and never your ability to read, verify, or restore an archive you already hold.
Installing the reader
The reader is the Go module github.com/downpipes-io/downpipe, built with Go 1.26 or newer, from the public repository github.com/downpipes-io/downpipe. go install github.com/downpipes-io/downpipe/cmd/downpipe@latest resolves against the public module proxy, and a plain git clone of the repository also works, with no account or engagement needed. The MIT licence then places no condition on holding, rebuilding, auditing or redistributing that copy.
From the source, the build is vendored: every dependency it needs, including the post-quantum signature module, is checked in, so the build downloads no module. That is what offline recovery depends on, and it is why the copy matters more than the command. If the vendor and Cloudflare are both gone, you can still rebuild the recovery tool from the source you hold, with no network access at all, provided the machine’s own Go already satisfies the toolchain go1.26.6 pin in go.mod. Under Go’s default GOTOOLCHAIN=auto an older local Go tries to download that pinned toolchain and fails outright when no network is available, so hold a Go meeting the pin alongside the source. Install the tool carries the pin and what to hold in advance.
Confirm the command set before you rely on the binary
Run downpipe --help against the binary and confirm prune, recombine and unseal-export are listed before you rely on it, because what the binary reports is the only account of its command set you can check. A plain from-source build leaves the version string at dev, so a locally built tool reports downpipe dev rather than a release version; the version a binary reports is the build’s stamp, and it is a different thing from the archive format version, which is the string downpipe/0.1.0.
What is byte-reproducible, and what is a reader corpus
For an evaluator checking durability against a second implementation, the conformance contract draws one more line worth understanding. The format is defined by tested behaviour against normative conformance vectors, not by prose alone, and the vectors split the archive into two authority classes.
| Authority class | Objects | How a second implementation proves it |
|---|---|---|
| Writer-authoritative, byte-reproducible | codec=none data segments, and shard manifests whose manifestCodec is none | A second writer reproduces the pinned bytes exactly. These objects are byte-deterministic from the pinned master and payload nonce. |
| Reader corpus, not byte-reproducible | The master capsule, the root manifest, the detached signatures, and the RUNLOG | A second implementation proves conformance by recovering and verifying them, not by reproducing their bytes. |
The reason the second class is not byte-reproducible is mechanical rather than a gap. The standard library’s post-quantum encapsulation draws its own randomness, and its one injected-randomness API is for tests only. The reference signer hedges each signature with fresh randomness. Those objects are therefore a reader corpus, proven by reading them back and verifying them. The four known-answer vectors are purely deterministic. One of them, the hybrid KEM combiner known-answer, is the vector a second implementation must reproduce byte for byte before sealing anything.
The construction is post-quantum hybrid
The envelope is post-quantum at CNSA 2.0 parameters and hybrid, so an archive stays safe if either the classical half or the post-quantum half is later broken. The hybrid design is a hedge against one half falling, not a guarantee that neither half ever will. The envelope is not an age file and is interoperable with nothing off the shelf. This is why recovery is delivered by a documented, conformant reader of the downpipe format rather than by a third-party tool. For the full construction, see cryptography.
Why interoperable-with-nothing is a feature, not a limitation
A format that any random tool could open would also be a format whose guarantees you could not pin down. By specifying the envelope precisely and proving it against conformance vectors, the format makes recovery reproducible: any conformant reader, the MIT one or a clean-room re-implementation, recovers every positive vector with the stated value and rejects every negative vector with the stated exit code. The cost is that you recover with a reader of this format, the open-source one or your own, rather than a generic decryption utility. The benefit is that the guarantee is testable, not asserted. The hybrid KEM combiner is pinned by a known-answer vector, so a second implementation reproduces the shared-secret derivation byte for byte, which is what lets an independent reader interoperate with the archives at all.
Where this fits
Licensing and the control-plane
What the licence and editions actually gate, and what an Enterprise relationship buys.
Security properties and limits
The limits on post-quantum hybrid, the reader-corpus split and the other security properties.
Break-glass recovery with the offline CLI
Recovering from the bucket bytes and your offline break-glass key with the open-source reader.
The downpipe CLI command reference
Every command the open-source reader exposes, on the recovery path and the provisioner path.
Last updated .