Why ReadyStack

Hardened, reproducible, signed images are established practice, and our release process follows it: every release is signed with our published key when it is published, and each release's page shows its signature, whether it runs as non-root, and whether and when its offline rebuild reproduced it bit-for-bit. What we add is everything around the image: Community Edition only, handbooks checked against that exact image, tested seed data, a record of known defects, and a build kit that rebuilds it with the network off. Why we built it · Source or image?

Who it is for

Teams that inspect their stack

See what was built, from which source, which tests ran against it, and what the database seed did.

Teams that need the paperwork

Build records, test results, and handbooks with their command transcripts come with each release.

Teams experimenting at the top

Move fast with experiments, prompts, and features. Your foundation stays stable and reproducible while you iterate above it.

Teams shipping fast with AI tools

Hand your agent a working base. Need a WordPress instance? Start from our image, with a handbook the agent can follow step by step.

For security and compliance review

The auditor's page, with SOC 2 criteria

Is this the image we published?: Its digest, and a cosign signature against our published key, recorded in the public Sigstore transparency log. Each release's page on the products page shows both.
What is in it?: The SBOM attached to the image, and the build provenance (SLSA v1) where the release carries it; the release's page says which it carries.
What is known to be wrong with it?: Its grade on our daily scan and on Docker Scout, each dated with its reasons, and the public defect log with how each defect was found and what happened to it.
Can we rebuild it ourselves?: The Hermetic Build Kit rebuilds the release with the network off; VERIFY_OFFLINE.sh compares the result with the published digest. With --provenance on your own build platform it produces SLSA provenance signed with your key.
How do we keep it up to date?: Release tags are exact and never move. A Renovate preset offers each new release, a new revision or a new upstream version, as a pull request, and never an internal- tag or another base OS.
What does each piece prove?: What the digest, signature, SBOM, scan, rebuild and handbook checks each establish, and what they do not: the evidence table.

What the image alone doesn't answer

How do I run it?: An admin handbook and a database handbook, checked against this exact image, with verification commands run inside it.
What does a working instance look like?: Seed data the release was tested with, and the use-case tests that passed and failed.
What is broken in this release?: A defects record and a security report, written down instead of left for you to find.

Documented by running it

# traefik v3.7.13-CE-ubuntu24.04-r1: handbook verification
# commands, run inside the published image
$ traefik version
Version:      3.7.13
Go version:   go1.26.8
$ curl -fsS http://127.0.0.1:8080/ping
OK

# docs/validation/PASSED_TESTS.md
  ✓ traefik_test_001  GET /api/version  -> 200
  ✓ traefik_test_005  GET /ping         -> 200

ReadyStack's approach

Document by execution

Each handbook's verification commands are run inside the published image and their output is kept. Tests, seed data, and defects are recorded the same way.

Deterministic builds

Bases pinned by digest, timestamps frozen, toolchain vendored. Releases verified reproducible rebuild to the identical linux/amd64 image-manifest digest we published, and each release's page says when that was last verified.

How a release is built

The steps every release goes through today

01Investigate dependencies

02Isolate source collection

03Stamp and lock dependencies

04Offline validation

$ ./BUILD_OFFLINE.sh   # docker build --network=none
$ ./VERIFY_OFFLINE.sh

Hermetic Build Kit

$ docker buildx build --network=none \
    --attest type=provenance,mode=max --attest type=sbom
$ cosign sign --key readystack.key readystack/<slug>@sha256:…

Docker Hub image candidate

What each release documents

Into its build kit

05Admin handbook

06DB handbook

07API guide

08Seed data

09Automated tests

10Vulnerability scan

Built to be the image you move to

How we think about upgrades

An image is only worth switching to if you can move to it from what you run today, and on to its next release, without losing data or meeting a surprise. We design every release around that move.

Exact tags that never move: Each release tag names one image and never changes. A fix to the same upstream version is its next revision (-r4 after -r3), so nothing changes under you until you change the tag. Our Renovate preset offers each new release as a pull request.
A revision replaces the last one in place: Each release's notes name the release it supersedes and say what changed, and a revision's notes say whether it replaces that release on the same volumes.
Moving from the upstream image, written down: Each new release's admin handbook compares the image with the upstream image most installs already run, where a single upstream image exists: the runtime user and its uid, the data path, the ports, the entrypoint and default command. For each difference it gives the command that bridges it: the chown, the mount path, the port mapping. The comparison is generated from measured records, not written by hand.
The upstream user, where upstream runs as non-root: Our images never run as root by default. Where the upstream image already runs as a non-root user, each product's next release moves to that user's uid, so a volume the upstream image wrote stays writable after a straight swap. That release's notes give the one-time chown for a volume an earlier ReadyStack release wrote.
Security revisions go first: When a fixable critical or high vulnerability appears in a published release, its fix is built as a revision ahead of other work. We publish how long that takes, measured from our records.
What we don't promise: Going back. Most products migrate their data the first time a new upstream version starts and do not migrate it back, so back up before a version upgrade. A revision rebuilds the same upstream version, so it does not migrate your data.

What would make moving to ReadyStack easier? Tell us at [email protected].Email a suggestion

What's in the Hermetic Build Kit

BUILD_OFFLINE.shRebuild with the network off
VERIFY_OFFLINE.shCompare with the published digest
Dockerfile.offlineBuild recipe
CHECKSUMS.sha256Verify integrity
vendored/Source and packages
bases/Base images, pinned by digest (not the published image: you rebuild that)
toolchain/Build tools
docs/Handbooks, tests, seed data, defects, SBOM

Trust through transparency

We don't ask for blind trust. We make the process inspectable.

Trust = Transparency × Consistency × Verifiability

Stable base. Fast experiments. Community Edition images your team and your agents can run, recover, and rebuild.Register