Stable, Open-source Releases, Automated
We release dozens of the most popular open-source projects every week, with every available critical and high security fix applied.
We don't write another version of your favorite open-source software. We make the existing software easier to deploy, understand, verify, and reproduce.
Oh, and you also get full documentation, reference data, tests and a build recipe that recreates our install bit-for-bit. Go ahead, try and match our bytes exactly. It's fun.
Why automation gives you better images, and keeps improving them.
Agents make open source more accessible to you. Popular open-source software is free to use, but running it well takes steady work that most teams never get to: applying each security fix as it lands, rebuilding when the base system ages, and writing down how the software really runs. You should be running the best image of the software you depend on. That is why we exist.
Our agents do that work for every release, and keep doing it after the release ships. Nothing waits for someone to find the time.
- Community Edition only, every release.
- Every release signed with our published key and dated.
- Every defect we find, logged in public with what happened to it.
- No contractual SLA yet. The Core times are targets. We measure every fix against them, and will expand our services with official SLAs as we gain the confidence and the history to back them.
- linux/amd64 only. Every digest and rebuild we publish is for linux/amd64.
- Not a compliance certificate. We supply evidence; your controls decide how you use it.
The network is off.
The bytes still match.
You never need to rebuild one of our images to use it. But every release comes with the documentation and the build kit to try: rebuild it with --network=none, nothing fetched, and compare your digest with the one we published. Most people never will. It is there so you don't have to take our word for anything.
A release counts below only when our latest clean-room rebuild reproduced the identical linux/amd64 image-manifest digest we published.
--network=none, nothing fetchedDon't trust us. Rebuild it yourself.
What a match looks like# 1. the build kit is what we shipped (-p keeps file modes: they are build input) $ tar -xpzf ReadyStack-<app>-<tag>.tar.gz && cd <tag> $ sha256sum -c CHECKSUMS.sha256 # 2. rebuild it with the network off, and compare $ ./BUILD_OFFLINE.sh # --network=none, nothing fetched $ ./VERIFY_OFFLINE.sh published : sha256:7e229b55c116501a7c00b78a1eba91ca… rebuilt : sha256:7e229b55c116501a7c00b78a1eba91ca… ==> DIGEST MATCH — reproduces the published image bit-for-bit. # 3. the image is ours: signed, logged in the public Sigstore log $ cosign verify --key https://readystack.dev/keys/cosign.pub readystack/<app>@sha256:…
How we count: a release counts only when our latest record shows it rebuilt from its build kit as published, with the kit's own scripts and the network off, to the identical linux/amd64 digest. Each product page gives the date of that rebuild, or says it has not been re-verified.
What that takes
How the build works- Every basePinned by digest
- Every timestampFrozen
- The whole toolchainVendored
- Left to varyNothing
- Live Docker Hub tagAdd
--onlineto prove it holds that digest
SLSA-enabling builds on your own infrastructure.
Each build kit is the complete, pinned build of one release. Run it on your own build platform and sign the SLSA v1 provenance BuildKit generates with your own key. The kit supplies the pinned inputs; the SLSA build level is your platform's.
$ ./BUILD_OFFLINE.sh --provenance # --network=none · SLSA v1 provenance from BuildKit $ ./VERIFY_OFFLINE.sh ==> DIGEST MATCH # then sign the provenance with your own key
Platform stacks: for software that is more than one image.
Some software is not one image. A Kubernetes cluster that runs virtual machines is many parts, host programs and container images, whose versions must match exactly and which install in order across several machines. A platform stack is that matched set, plus the procedure that installs it.
- Every part built by us with the network off, from pinned upstream source and packages.
- Rebuildable by you, byte for byte.
- Signed, with an SBOM and SLSA v1 provenance. Non-root by default.
- Installs with no internet, from a local registry on your own network.
- Tested together on a multi-node cluster, with a runbook checked against that running cluster.
For sites that must verify what they run and cannot pull from the internet: air-gapped, regulated and sovereign environments.
Kubernetes VM Stack
- Kubernetes1.36, three nodes, highly available with kube-vip
- Virtual machinesKubeVirt 1.9
- Networkingflannel for pods, Multus bridge networking for VMs
- StatusPublished
- ReleaseKubernetes VM Stack
- The stack's pageWhat is in it, how it was tested, how to install it
Every part and the install bundle are published and signed. Before release, a three-node cluster was installed from the published images, each pulled at its published digest from a local registry, and passed every check of its acceptance run, including the loss of a control-plane node and a virtual machine running under KVM.
Defects our checks found
Open the defect logWhat our checks found before release, counted from the public defect log, which says how each was found and what happened to it.
- Documentation 14,538
- Insecure default 177
- Image 96
- Deviation from upstream 39
- Verification 32
- Build kit 23
- Reproducibility 17
- License 11
- Bug 10
- Upstream documentation 8
- Build 1
What happened to them: 14,139 fixed before release · 61 fixed after release · 713 open, disclosed with their release · 39 not a defect (works as designed). Where they were: 14,747 in our build or documentation, 205 in the upstream project.
Docker Hub image
FreeOpen source images, free to pull.
- Community Edition (CE), open source only
- Documented build process
- Addressed by SHA-256 digest
- Base OS named in every release tag
- Each release's grade, with the date and why
Whether a release is signed, runs as non-root and carries SBOM and provenance attestations is shown per release on its product page, as read from the registry.
Hermetic Build Kit
Free with an accountEverything to verify, rebuild, and operate.
The offline build, full documentation, seed data, validated tests, defect reports, and provenance records — per product.
Dockerfile.offlineBUILD_RECIPE.jsonCHECKSUMS.sha256SBOM.jsonVERIFY.mdREBUILD.mdbases/pinned base imagesvendored/source
- Admin handbook
- DB handbook
- API guide
- Seed data
- Security report
- Defects report
- Validation tests
- Release notes
The build kit holds the pinned base images and everything else the build needs, not the published image itself: you rebuild that from it, and VERIFY_OFFLINE.sh checks it matches.