FAQ: the hard questions, answered honestly

Because a model never decides what is published. AI models write build strategies, handbooks and fixes. Today they are hosted AI model subscriptions; earlier, a locally run open model did part of the work, and our plan is to move back to locally run models as they improve. Whichever model it is, code checks what it writes, and each check has a recorded result (How AI is used, and fenced in):

• The build runs with the network off (--network=none). It cannot fetch anything.
• Every input fetched beforehand is pinned by digest or commit. The packaging step refuses a recipe that fetches anything unpinned, or that turns off TLS or signature checks (curl -k, --no-check-certificate, pip --trusted-host, GIT_SSL_NO_VERIFY and similar, since 2026-11-12), so a made-up URL or flag cannot pull in new bytes unnoticed.
• Images run as a non-root user by default. The few products with an exception are named, each with its reason (the non-root rule).
• Our own vulnerability scan checks every release. A release with a fixable critical or high vulnerability is not published as grade A.
• Every claim in a handbook is checked by code against recorded facts and against the running image. It errs toward holding a release.
• A held release gets an independent review, then a clean-room rebuild on a second build host, before it is published.
• Most build recipes are generated by deterministic code from a written build strategy. The rest are written by hand and reviewed like any code change, with the full test suite.

Limits today. Our threat model for prompt injection (instructions planted in an upstream README or issue that a model then reads) is written down on How AI is used, and fenced in, with what stands in the way of each attack. We have not yet tested those defences adversarially, and the independent reviewer is also an AI model, so a trick that fools one model may fool both.

What you can do. Do not take our word for it. Read the recipe: its public part is open to everyone, and every file is open to any registered account. Rebuild the release from its build kit with the network off and compare the digest. Verify the signature. The Guide says what each piece of evidence proves, and what it does not.

No. Reproducible means you can check it, not that it is safe. A bit-for-bit rebuild proves the image is exactly what the published recipe builds, so you can audit the recipe instead of trusting us. It says nothing about whether the recipe's inputs are benign.

What we check for safety is separate, and each check has its own published result:

• a daily vulnerability scan, with VEX statements for findings that do not apply to the image;
• an SBOM, and build provenance (SLSA v1) where the release carries it, with the image's signature recorded in the public transparency log;
• a non-root user by default;
• the handbook checks against the running image;
• an independent review of any release a check held.

Limits today. None of these proves software safe either. A scan finds only what has been reported. A handbook check covers only what its commands exercise.

What you can do. Read the recipe, rebuild it, and run your own scanner on the image by digest. The auditor's page maps what each release carries to the criteria an auditor asks about.

If the project's own image does what you need, use it. It is often a fine answer. What a ReadyStack release adds, in one place:

• the Community Edition only, checked;
• a build kit that rebuilds the release with the network off, to the same digest where that has been verified (each release's page says whether and when);
• every available critical and high fix when the release is published, a re-scan every day, and a rebuild when a release falls below grade A on our scan;
• admin, database and API handbooks checked against the running image;
• a signature, an SBOM and build provenance.

That matters most to teams that have to show an auditor how an image was built. Free catalogues also change: in 2025 one of the largest moved most of its free version tags to a legacy repository that gets no updates. The Guide's comparison names the options, with links to their own pages.

Limits today. We publish linux/amd64 images only (arm64), and on Docker Hub only (pull limits). On either, the project's own image may suit you better.

What you can do. Compare product by product. Each product page shows the release's grade with its reasons, its user, whether its rebuild was verified, and its admin handbook's comparison with the project's own image.

That is what the build kit is for. It carries everything the build needs:

• upstream's source at the pinned commit;
• the operating-system packages, as .deb files;
• the language dependencies;
• the base images, saved.

BUILD_OFFLINE.sh rebuilds with the network off, so a mirror that later drops its old packages does not matter. On 2026-11-11 a tester outside ReadyStack rebuilt one release (pause) offline from its kit and got our published digest.

Limits today. In November 2026 we found two kinds of non-reproducibility our check had missed:

• Two live releases, argocd v3.6.1-CE-ubuntu24.04-r1 and flannel v0.28.10-CE-ubuntu24.04-r2, carry their build date in /etc/shadow: a package script ran before the build's fixed date was set. Each reproduces only when rebuilt on its build day.
• nodejs 26.13.0-CE-ubuntu24.04-r1 depends on the order in which the filesystem lists a directory (Node's build lists its ICU files unsorted). It reproduces on some filesystems and not on others.

Our check rebuilt each release on the same host on the same day, which is exactly what let these through. Fixed revisions are being built, and the build now refuses the first kind. So we do not claim that every release reproduces for everyone: each release's page says whether its rebuild was verified, and when.

What you can do. Rebuild it yourself: VERIFY_OFFLINE.sh compares your result with the published digest. If it does not match, tell us, with the release tag and your host's filesystem.

The build kit is the part that does not depend on us. Every release's kit is self-contained and rebuilds offline without us, our servers or our accounts. If we stopped tomorrow, you could still rebuild what you run and keep running it. We do not delete published releases: earlier release tags stay pullable on Docker Hub.

Limits today. New releases and security fixes stop if we stop. Today ReadyStack is run by one person, on contributed hardware, with AI model subscriptions doing much of the work; our plan is to move that work back to locally run models as they improve, so it depends less on any outside service. ReadyStack is soon to be a nonprofit (About), but today there is no second maintainer.

What you can do. Download the build kit of each release you run (free with an account) and keep it with your own records. Copy the images you run into your own registry, by digest. If you need the kits kept somewhere we do not host, tell us.

You should know first: ce.rodeo is run by the ReadyStack team. Its about page says so, and its publisher ranking marks our row as affiliated. The facts:

• Its rubric is public, with its changelog, and it scores every publisher the same way. A change to the rubric applies to every publisher.
• It is not written to flatter us. Its v2 rubric, which takes a point off for each medium finding with no fix yet, graded about half of our images D or F in its first week (2026-11-08). We are changing our images to meet it, by moving products to a smaller base.
• When we wrote this (2026-11-12), the publisher ranked first on ce.rodeo was not ReadyStack.
• We also report grades we do not compute. Each release's page shows Docker Scout's policy grade, from Docker's own tool. Our daily scan uses syft and grype, open-source tools we do not maintain, and each product page shows how its score was worked out, line by line, with the scanner versions.

Limits today. However fair the rubric, a ranking run by one of the publishers it ranks deserves a second look.

What you can do. Read the rubric and its changelog. Then run grype or Docker Scout on the image yourself, by digest, and compare.

Finding and queuing the fix is automated, and we measure how long it takes:

• Every published release is scanned every day, and its SBOM is checked against the newest vulnerability data every four hours.
• A new fixable critical or high vulnerability queues a security revision, and security revisions are built before other work.
• When a base image is updated, the releases built on it are queued to be rebuilt on the new base.
• We track a fix deadline for each product tier, counted from when the fix is published. We have not published those deadlines yet; we will publish them with our measured record against them.

What is published today is the measured time itself: the updates page shows, from our records, how long a fixable critical or high vulnerability stayed in a release over the last 30 days.

Limits today. There is no contractual time limit. And the record has misses: in November 2026 a nodejs security revision was held past its deadline because it failed its reproducibility check (above).

What you can do. Let the Renovate preset offer each new revision as a pull request. Watch the build queue and the defect log, which show what is being fixed now and why.

No. Every image is linux/amd64 today. arm64 is not available yet. The build kit builds linux/amd64 too: its base images and packages are amd64.

What you can do. Run the images on an x86-64 host. On an Apple silicon Mac, Docker Desktop can run linux/amd64 images under emulation: slower, but enough to try a product. If you need arm64, tell us, and for which products.

You can. Images are on Docker Hub only today. Docker Hub limits anonymous pulls per IP address, so many machines behind one address reach the limit quickly. We reach it ourselves, and run a pull-through cache because of it.

We build upstream's own code at its release tag, and keep upstream's configuration file and data paths wherever we can. What we add is small: first-start checks that refuse an unsafe setup, generated secrets, and a health check.

• Each release's notes say what changed and which release it replaces, and a revision's notes say whether it replaces that release on the same volumes: replace the container, keep the volumes.
• Each new release's admin handbook compares the image with upstream's own image (the user and its uid, the data path, the ports, the entrypoint) and gives the command that bridges each difference.
• Where upstream's image runs as a non-root user, we move to that user's uid, so a volume upstream's image wrote stays writable after a straight swap.
• On 2026-11-12, before publishing new revisions of MinIO, NetBox, Redash and Coder, we started each one on the data its previous release wrote, and read the data back.

Limits today. That upgrade test on the previous release's data is not yet a standard step for every release. Since 2026-11-12 the build runs it for PostgreSQL, MariaDB, Valkey, MinIO and NetBox and records the result in the release's archive (provenance/UPGRADE_CHECK.json); it does not hold a release yet, and other products follow. And we do not yet write down the way back to upstream's own image as its own section; the handbook's comparison is where to start.

What you can do. Try each move on a copy first and keep the previous tag and your backup (best practice for stable releases). If a move breaks, tell us.