Diffinery’s November 5 U.S. launch announcement presents an open-source code-hosting and continuous-integration platform built on Cloudflare. Its GitHub Actions compatibility claim deserves a close look at runner selection: the current documentation says an Ubuntu ARM label can run on the hosted x64 image. A familiar workflow label therefore does not establish that a job tested ARM code on an ARM machine.
Diffinery’s company-issued launch announcement
Read the native-workflow runner mapping
For workflows running on Diffinery itself, the compatibility guide maps ubuntu-latest, ubuntu-24.04 and ubuntu-22.04 to the same hosted Ubuntu 24.04 x64 container. It says Ubuntu ARM labels also use that x64 image; actual ARM execution requires suitable self-hosted labels and an ARM machine. Hosted Windows and macOS runners are unavailable, with registered self-hosted runners needed for those platforms.
Diffinery compatibility guide: runner labels and image differences
This concerns Diffinery’s native workflow engine. Its separate GitHub-runner integration keeps workflow orchestration on GitHub and selects Diffinery runners through different labels. Keep the two adoption paths distinct when reading setup instructions.
Separate guide for using Diffinery runners while code stays on GitHub
Build an execution record before comparing results
For each job in a proposed pilot, write down the intended operating system, architecture, toolchain and output. Beside those expectations, record what the job actually reports. Keep its run identifier and commit with the record so the evidence can be traced to the version tested. A successful exit status is useful only within the environment that produced it.
Consider a fictional library with two planned tests: one on Linux x64 and one on Linux ARM. If both jobs execute on x64, two green results still provide no ARM-machine execution evidence. The job names may be different while the tested architecture is identical. This example describes an evaluation mistake, not a Diffinery benchmark or a result we obtained.
Check the environment as well as the YAML
The compatibility guide also describes a smaller hosted image than GitHub’s. Do not assume that a language runtime, browser or cloud command-line tool used by your existing job is already installed. Inventory those dependencies and make their setup explicit in the pilot. Record a missing dependency separately from a failed application test; they answer different questions.
Keep a short acceptance checklist: did the intended architecture run, did the required tools initialize, did the expected tests execute, and were the expected outputs produced? Review each requirement before making a wider migration decision. If ARM execution is required and remains untested, leave that requirement open even when other checks pass.
No instance was deployed, workflow executed or performance claim independently tested for this article. The practical next step is a representative, authorized pilot with environment evidence retained alongside its results.