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.

Nothing here is closed source. Two licences apply, 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.

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 discipline behind the claims on this page, see precise claims and the honesty posture.

The boundary

The format is the part that matters most for independence. Because it is documented in full and shipped alongside the data in every archive, a holder of the destination bytes and the customer’s own offline break-glass key can always recover, 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 can never unwrap it, which is what keeps recovery in the customer’s hands.

Recovery depends on nothing the vendor controls

This is the load-bearing claim, so it is worth being precise about exactly why it holds. The reader on the recovery path imports no vendor SDK or telemetry. It reads two inputs and nothing else.

The local-directory backend makes no network call at all. The S3 backend makes requests to the customer’s own bucket over HTTPS with the customer’s credentials, refusing plain HTTP except to localhost and refusing all redirects so a credential cannot leak to another host. Every reading command (keygen, inspect, verify, attest, restore, selftest) issues GET only; prune --apply is the one command that writes, issuing a DELETE to remove a run your own retention policy has superseded, and only against the same customer bucket with the same customer credentials. Neither backend reaches any Maelstrom AI or downpipes service. The whole recovery surface, keygen, inspect, verify, attest, restore, selftest, prune, recombine and unseal-export, carries no path that calls home.

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 control-plane and licence checks gate the paid platform’s operation, never your ability to read, verify, or restore an archive you already hold.

Installing the reader

go install github.com/downpipes/downpipe/cmd/downpipe@latest is the quickest install (Go 1.26 or newer, needs network access to fetch the module). A from-source, vendored build is the no-network alternative: build it from the checked-out source, and every dependency it needs, including the post-quantum signature module, is vendored into the repository. That is what underpins the offline-recovery promise: if the vendor and Cloudflare are both gone, you can still rebuild the recovery tool from the repository alone, with no module download and no network access.

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.

The reason the second class is not byte-reproducible is mechanical rather than a gap: the post-quantum encapsulation draws its own randomness with no injected-randomness path in the standard library, and the signer is hedged (randomised) by default. So those objects are a reader corpus, proven by reading them back and verifying, while only codec=none data segments are writer-authoritative. One standalone vector, the hybrid KEM combiner known-answer, is the purely deterministic exception that 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 claim that neither half ever will. The envelope is not an age file and is interoperable with nothing off the shelf, which is precisely 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.

Where this fits

Last updated 5 August 2026.