Don't trust us. Read the code.
A backup product that asks for your trust has already failed. We publish our source so you can verify what we claim, and we license it so you can run it yourself.
Trust through transparency
A closed-source backup product is a contradiction. You would be trusting that the encryption is real, that the data paths are actually absent, and that the keys are never held.
We do not ask for that trust. Every component a customer runs is licensed under the two-layer rule below. The downpipes engine, console and offline reader are published on GitHub; the control plane, which we operate rather than customers, stays private. What is also public is the documentation and our Trust Centre. Find a bug and tell us.
One rule, not a per-component decision
We do not decide licensing case by case. One rule decides it for every component. The full breakdown is in the licensing register.
Layer 1: permissive
Cryptographic cores, offline readers, and specifications: MIT or Apache-2.0. The archive format specification ships with the offline reader under MIT. Anyone may use, modify, embed, sell, and host these. The only obligation is to keep the notice.
Layer 2: source-available
Engines and consoles: Elastic License 2.0. Anyone may read the code, run it in their own account, modify it, and rely on it for free, for as long as they like. It forbids providing the product to others as a hosted or managed service. A managed-service provider can do that under a separate agreement with us. The licence also forbids circumventing licence keys or removing notices.
downpipes
The engine and console are source-available (Layer 2, Elastic License 2.0). The offline reader is MIT-licensed (Layer 1). The engine, console and offline reader repositories are published. Maelstrom operates the control plane and does not publish its source.
The things you would otherwise have to take on faith
These are the components the two-layer rule puts in the open. The licensing register records the licence and the publication status of each one.
Cryptographic cores
The post-quantum hybrid sealing that protects downpipes archives at rest.
Services & engines
The downpipes in-tenant backup engine and operator console, which run inside your own account.
Client tooling
The MIT-licensed downpipe offline reader that restores archives with no vendor in the loop.
Specifications
A frozen archive-format specification, implementation-independent. Anyone can build a compatible reader.
Security documentation
Our Trust Centre publishes our security overview, privacy notices and legal terms alongside the code. Threat models, risk registers and records of processing are available to customers, prospects and auditors on request.
Signed releases, pinned updates
downpipes release tags are signed with a hardware security key. The engine update channel is signed with a hybrid Ed25519 and ML-DSA-87 release key that our CI never holds. The channel is pull-only. The engine verifies each update against a pinned public key before it applies it. It rolls the update back automatically if a post-apply canary fails. Nothing is pushed to you. The engine sends no telemetry unless you turn on the advisory beacon, which is off by default. On each cron tick, the engine checks the channel at update.downpipes.io with a GET for two static files. Cloudflare adds a CF-Worker header to that request, and the header names the engine's zone. To stop the check, unset UPDATE_CHANNEL_URL.
Each downpipes release on GitHub carries SLSA provenance that ties its artefacts to the exact source commit. Each release also carries keyless Sigstore signatures. The VERIFY.md file in each repository tells you how to check them.
- Release tags signed with a hardware security key
- Signature-pinned, pull-only update channel
- Canary-gated apply with automatic rollback
- Hourly canary flight of known data through your destination
- SLSA provenance published with each release
Your data stays yours
A downpipes backup belongs to the customer: it lives in the customer's own account, sealed under keys only the customer holds, and we never receive a copy. When we say you own your data, we mean you are the only one who has it.
A standard, not a walled garden
We write an implementation-independent archive-format specification and license it for publication, so others can build compatible readers.
That is deliberate. A recovery path you can rebuild from a public spec is one no vendor, including us, can ever take away from you.
What we believe
No-custody beats good intentions
A promise not to misuse your data is only as good as the company making it. A system that never holds your data cannot break that promise, because there is nothing to break.
Privacy and sovereignty are architectural
Not a toggle, not a policy, not a promise. When the data paths do not exist, or the keys live only with you, there is nothing to breach, subpoena, or sell.
Regulation needs better tools
Breach-notification and data-protection rules are tightening. The question is whether meeting them requires handing a vendor standing access to your live environment, or whether no-custody architecture offers a better path. We think the answer is obvious.
Verifiability is non-negotiable
Closed systems ask you to take their word for it. We think that is an unreasonable ask. If you cannot read the code and run it yourself, you cannot verify the claim.
Get involved
Report bugs, review the cryptography, suggest improvements, or build something new on top of our specifications. We welcome contributions from anyone who shares the goal.