Every runtime, every platform, one table.

A tebako runtime is not one artifact but a family of artifacts. Each runtime factory publishes its interpreter once per engine, once per version line of that engine, and once per platform triplet, so the question an author must answer before pinning a runtime requirement is whether the cell they need — this engine, this version, this platform — actually exists. This page answers that question with a single matrix, and it treats an empty cell as a statement that owes the reader a reason: every unpublished cell below is named, and the reason it is unpublished is given in a sentence of its own.

The axis is eight platform triplets. The canonical form is the vcpkg-form triplet, which is what manifests and runtime requirements use; the release-asset form is the suffix that appears in published file names, which is what a release listing shows.

A check mark (✓) means the cell is published in the factory’s current release. An em dash (—) means the cell is unpublished, and the reason is stated in the next section. The matrix below was verified against the live factory releases on 2026-10-21.

The JRuby row is inherited rather than built. JRuby ships as a single universal image, because its interpreter is Java bytecode, and that image runs on whichever OpenJDK (Temurin) runtime is installed; the JRuby row therefore covers exactly the platforms the Temurin row covers, which today is the full axis.

Every em dash above is one of the following six situations, and no unpublished cell exists outside these six.

The matrix is verified by listing the assets of each factory’s current release and parsing their platform suffixes, which is a mechanical check that anyone can repeat with the GitHub CLI’s gh release view command against the factory repositories. The page is re-verified at every factory release, and the verification date in the matrix section is updated with it.