Source is the recipe. The release is the deliverable.

1. Get the sourcegit clone … && git checkout v2.4A tag can be moved. Which commit was built?
2. Install a toolchaingo / node / python / jdkWhich version, from where? Unless the project pins it, it differs per machine and per week.
3. Resolve dependenciesnpm install · pip install · go mod downloadLockfiles pin what the project locked; the rest comes from public registries as served that minute. A compromised maintainer or a typosquat enters here.
4. Buildmake · npm run buildBuild tools often stay in what you run. Unless the build is reproducible, nobody else can check this output.
5. Configure & first boot.env · admin user · migrationsDefault passwords, open installers, the enterprise edition by accident?
6. Run it./serverWhat is in it? Who signed it? Has anyone scanned it since?

Evidence	Establishes	Does not establish
Image digest	Exactly which image you run	That the software in it is safe or correct
Signature (our published key, recorded in the public Rekor log)	That we published this digest	That the upstream code is trustworthy
SBOM	Which packages and versions are in the image	That none of them is vulnerable
Daily scan and grade	The known, published vulnerabilities on the scan date, and which have a fix	Flaws nobody has reported yet
Bit-for-bit offline rebuild	That the build kit's recorded inputs produce the published image, on linux/amd64	That those inputs were benign
Handbook checks	That the handbooks' verification commands work in this image	Behaviour those commands do not exercise
Non-root user	Less privilege inside the container	Isolation: that still depends on how you run it

So when we say a release is a known state, we mean known bytes, built from recorded inputs, with this evidence attached. We do not mean software known to be safe: no publisher can promise that, and the evidence is there so you can check what we do promise.

We gave the same AI agent the same task nine times. It had to deploy Paperless-ngx with its database and cache, survive a reboot, create an admin, upload a document through the API, and write down how to back it up and upgrade it. Three runs started from upstream's source repository, three from upstream's official image and three from our image. A script, not the agent, decided whether each run passed.

• Against the source build, our image saved time. Its median was less than half the source build's, which spent about ten minutes building the image.
• Against upstream's official image, ours did not help. The agent was a little faster and cheaper with upstream's image, and passed just as often. It already knew how to deploy that image without reading anything. With ours, it read our documentation first.
• Where ours differed was outside the agent's choices. No process in our container ran as root, and ours had a signature and an SBOM that could be checked. No agent checked them, and no agent pinned an image by digest.

*The API-equivalent price the CLI reports. No person intervened in any run. This is one product, one task, one model (Claude Sonnet) and three runs per starting point, designed and run by ReadyStack. The full study has every run, what the agents got wrong, the limits, and the protocol and raw data to check it.

The Agent-ready Build Kit is the complete, pinned build of one release, and it is yours to change.

For a release built from upstream's source, the build kit holds the source tree, every dependency, the base images pinned by digest and the build toolchain, with a recipe that builds with the network off. Change the code the way you want, apply a fix upstream has not released yet, or turn on a build option, then run ./BUILD_OFFLINE.sh. Your build starts from a kit that already builds our release with the network off, instead of from a fresh clone and the six open questions above.

Your changed build is your release: VERIFY_OFFLINE.sh will report that it no longer matches our digest, and built with --provenance on your platform, the provenance it signs records what you built. Each release's page says how it was built.

You can build all of this yourself: pin every input, make the build reproducible, sign and attest it, scan it every day, and write and test the handbooks. The question is whether doing that for every service you run is where your engineers' time should go.

Bitnami. Since 28 August 2025 its free public catalogue is a limited set of images on the latest tag only, which Bitnami says are "intended for development". Versioned tags moved to bitnamilegacy, which Bitnami says "will no longer receive updates". Production images are its paid Bitnami Secure Images subscription. Bitnami's announcement

Chainguard. Minimal images built on its own Wolfi OS, whose package recipes are open source, and rebuilt continuously. Its Catalog Starter (March 2026) is a free plan for up to five Chainguard images, all supported versions; the full catalogue is a paid subscription. If five minimal images cover what you run, that is a strong free option. Our difference is the build kit: the exact image we publish, rebuilt offline on your own builder to the same digest, with handbooks checked in that image, seed data and tests. Chainguard's announcement

Upstream's own images. Free and usually version-pinned, and many are signed and well maintained. What is signed, scanned, documented and kept to the open-source edition varies from project to project, so compare product by product.

ReadyStack. Free, version-pinned images on Docker Hub for every release, open-source edition only, each release graded with the date and the reasons, re-scanned daily, and rebuilt when it falls below grade A. The paid Agent-ready Build Kit is the complete build of that exact release.

	Build from source yourself	ReadyStack image	ReadyStack build kit on your platform
Same bytes on every machine	Only if you make your build reproducible	Yes: one digest	Yes: rebuilds to our published digest where verified
When a fix lands upstream or in Ubuntu	You notice it and rebuild	We find it in the daily scan and build the fixed release (see below)	The fixed release's archive; you rebuild
Open-source edition only	Your call	Always, checked	Always, checked
Signature, SBOM, provenance	Whatever you produce	Attached per release (each release page shows which)	Your own, from your platform
Handbooks checked against the image	You write them	Yes	Yes, in the build kit
Works with the network off	Only if you vendor every input	Pull once, run anywhere	Yes: --network=none

What happens when a vulnerability is published

• Found within a day. Every release on sale is scanned every day, on our scan and on Docker Scout's policy grade.
• Worked the same day. A release that drops below grade A on either one goes into the build queue that day: upstream's newer version when there is one, otherwise a rebuild with the fixed packages. The queue shows what is building now and why.
• No upstream fix. We patch it ourselves where we can (Consul, for example, is built from our own maintained fork), or the release stays below A and its page says why.
• No time promise yet. We measure the time from detection to a fixed release for every release first, and will publish a target once we have it.

SLSA Build Level 3 is earned by a build platform, not by an image. The platform must keep builds from influencing one another and keep the key that signs the provenance away from the build steps. So we don't stamp "SLSA 3" on an image. We give you everything Level 3 needs from the inputs side, and your platform supplies the rest. Having the inputs does not make a build Level 3 by itself: your platform and the provenance it signs have to meet the Level 3 requirements, and can be assessed against them.

Build kits from 2026-10-10 carry --provenance. Each release's page says whether its offline rebuild has been verified to reproduce the published image bit-for-bit, and when.