Docker images
Fifteen public images package the runtime, GPU prover, operator tools, recovery controls, and release checks. Each image has one job, so you can pull only the pieces your deployment needs.
The short version
Docker downloads the same filesystem and startup command on every machine. The coordinator assigns work, a room node runs the application, the prover agent carries proof jobs, and prover-cuda performs the GPU work. The remaining images help deploy, observe, recover, and test that path.
Open an image page to see its current tags and immutable digests. In a reproducible deployment, choose the GPU-specific tag where required and pin the resulting sha256 digest instead of relying on latest.
These four images are the main application, execution, queue, and proof path.
Runtime · linux/amd64
Runs the coordinator API, console, and the control-plane roles that manage rooms and proof jobs.
The same packaged server can start the coordinator or a delegated worker role. It connects application activity to the proof queue and watches the L1 result.
Runtime · linux/amd64
Runs an application room node without a browser interface.
It loads a room configuration, executes allowed actions, talks to peers, requests proofs, and exposes health, readiness, metrics, and capability endpoints.
Runtime · linux/amd64
Moves proof jobs between the coordinator queue and a GPU prover.
The agent leases one job, sends its input to the local prover, returns the proof, and reports bounded liveness through the coordinator.
GPU runtime · sm86 / sm89 / sm90 / sm120
Runs the RISC Zero proof service on a supported NVIDIA GPU.
Choose the tag that matches the GPU compute capability. The service replays a room batch in the zkVM and wraps the result as a Groth16 proof for L1 verification.
These images make an installation repeatable, inspectable, and recoverable without adding application logic.
Operations · linux/amd64
Serves operator guides, API references, schemas, metrics, and runbooks as a small local website.
NGINX serves the versioned documentation shipped with the deployment, so an operator can read the matching guidance even when external services are unavailable.
Operations · linux/amd64
Provides one consistent toolbox for validation, deployment, and inspection.
It packages the reviewed Python scripts with Docker, Kubernetes, Helm, Kind, Kurtosis, and MinIO clients. The same tool versions run on every operator machine.
Operations · linux/amd64
Supplies the PostgreSQL, MinIO, encryption, backup, restore, and archive-checking tools.
The container runs the checked-in backup and restore scripts with fixed tool versions, keeping recovery commands separate from the application containers.
Recovery · linux/amd64
Decides whether a warm standby has enough evidence to become the active coordinator.
It checks health, database replay, fencing, and freshness, then asks separately scoped services to perform the promotion. It does not directly control Docker or Kubernetes.
Recovery · linux/amd64
Performs the small set of approved Docker or Kubernetes actions needed during failover.
A scoped request tells it to fence the old writer, promote the standby, and move the stable route. It returns evidence of what actually changed.
These images exercise failures and long-running behavior before a candidate is treated as ready.
Verification · linux/amd64
Checks that a hosted candidate behaves like the source-bound build it claims to be.
It follows a fixed scenario plan, calls the live services, joins their evidence, and fails when a source identity or required behavior does not match.
Verification · linux/amd64
Rehearses a real promotion and checks that the old writer cannot continue afterward.
It drives the promotion controller and failover provider, measures recovery, then runs independent split-brain and fencing assertions.
Verification · linux/amd64
Coordinates a long, restart-safe lifecycle test and checks that it closes cleanly.
It binds the run to one candidate, resumes from durable state, and verifies the append-only evidence. The published wrapper is not by itself proof that a release passed the soak.
Verification · linux/amd64
Introduces known failures and bounded load during resilience tests.
It accepts only an allow-listed fault or load profile for a named candidate, records the attempt, and prevents callers from supplying arbitrary commands or targets.
Verification · linux/amd64
Runs a controlled PostgreSQL and object-store backup-and-restore rehearsal.
It encrypts candidate-bound backups in a separate store, restores only into fresh targets, and compares the restored hashes before reporting success.
This is a build environment, not a service you normally keep running.
Build image · sm89
Provides the CUDA, Rust, RISC Zero, and Groth16 tools used to compile an sm89 prover.
Use it as the controlled build stage when reproducing the RTX 4090 prover. The resulting runtime belongs in prover-cuda; this image is not the HTTP proof service.
See the other half of the public platform.
Explore the public repositories