By Ludovic Henry, RISE
Six weeks ago, we announced the Early Availability of the RISE RISC-V Runners, a free, managed GitHub Actions runner service that gives any open source project access to native RISC-V hardware. This post is a status update: usage so far, the projects that have picked it up, what we changed under the hood, and what is still rough.
Usage since the announcement
Between March 19 and May 6, 2026, the service ran more than 13,000 jobs for 197 unique repositories across 87 organizations. The completion rate is 99.78%. Daily volume climbed from a handful in the announcement week to a current average of around 445 jobs per day over the last seven days.
In the last 14 days, 15 new organizations and 28 new repositories ran their first job on the runners. That is the number that matters most to me: it tells us the service is finding new users on its own, not just being kept alive by the early movers. The same signal shows up outside of direct CI use: there have been writeups on Hackster.io and the Adafruit blog, a thread on Hacker News, a thread on the Julia Discourse, an RFC on the LLVM Discourse, and much more that I missed.
You can find more detailed information about our usage at https://monitor.cloud-v.co/d/riscv-runner-main/rise-risc-v-runners-overview
Who is using it
A few highlights from the top of the usage distribution:
- llama.cpp is the heaviest user, with 2,589 jobs. Upstream llama.cpp now exercises every change against native RISC-V hardware on every CI run, so RISC-V has become a first-class CI target alongside x86 and ARM for one of the most actively developed inference projects out there. We are partnering with Cloud-V to host the RVV 1.0 enabled machines.
- PyTorch out-of-tree CI runs in riseproject-dev/pytorch-ci, 870 jobs combined. This is the work I covered at the PyTorch Conference EU. It currently builds PyTorch end to end on riscv64; testing is in progress. The setup follows the PyTorch Out-of-Tree Cross-Repository CI Relay RFC, and the goal is to reach Level 3 (non-blocking checks in pull requests with the right label) fairly soon.
- k0s, the CNCF Sandbox Kubernetes distribution, is in the home stretch of integrating with the runners. The work lives in k0sproject/k0s#7414; once merged, k0s will run nightly builds and tests on RISC-V on these runners.
- Kairos (CNCF Sandbox), the immutable Linux meta-distribution for edge and Kubernetes, is using the runners via kairos-io/kairos-init. Enabling Kairos to ship and validate on RISC-V matters for the broader edge / IoT story; we are happy to be the CI substrate for that.
- CNCF more broadly. Beyond k0s and Kairos, we are engaged with k3s, Kubernetes itself, and containerd to bring native RISC-V CI to those projects too. The aim is to make RISC-V a routine target across the cloud-native stack rather than a one-off.
- pq-code-package/mldsa-native and pq-code-package/mlkem-native account for 2,208 jobs combined. These are reference implementations of the NIST post-quantum signature (ML-DSA) and KEM (ML-KEM) standards. Cryptographic primitives like these need to run correctly on every architecture they will plausibly target; native RISC-V testing is no longer a gap there.
- NumPy. Integration is in flight at numpy/numpy#30995. Getting NumPy onto native RISC-V CI is a big lever, it sits at the bottom of a very large dependency tree.
- alibaba/zvec (101 jobs), Alibaba’s in-process, vector database. A focused, performance-oriented use of the runners.
- kubetail-org/kubetail (499 jobs), the real-time Kubernetes log explorer.
- eshattow accounts for 1,707 jobs across riscv64 Home Assistant container builds, and gounthar (501 jobs) across DuckDB, llama.cpp, duckdb, and the whole Docker and Python ecosystem. Both have been notably proactive in adopting the runners and giving feedback early, exactly the kind of usage that helps shake bugs out of the platform. Thank you.
- Other active workloads include armbian/os (Linux distribution images), wazero/wazero, pyca cryptography, ChanTsune/Portable-Network-Archive, MarkusPettersson98/mullvadvpn-app-riscv, and ndren/uiua.
The mix of workloads is the part I find encouraging. AI inference, post-quantum cryptography, Kubernetes and the cloud-native stack, scientific Python, programming languages and runtimes, distros, and database engines all on the same infrastructure.
What changed under the hood
The platform looks meaningfully different from what was running on March 24. The webhook handler and scheduler are now separate processes coordinating through PostgreSQL, which keeps the webhook path fast and the control plane resilient to restarts. And each runner pod now runs a single unified container image (the GitHub Actions runner with all the tooling) which simplifies the pod and supports a wider range of workflows out of the box, including workflows that run in-container. The full architecture is documented at riseproject-dev.github.io/riscv-runner for anyone who wants to dig in.
On hardware: the base pool is a fleet of Scaleway EM-RV1 nodes shared by all users. A few organizations (ggml-org is one) have needs that justify a dedicated pool with specific hardware (RVV 1.0 for example). The plan from here is to add more EM-RV1 capacity to the shared pool, bring up new pools on RVA23-class hardware (stay tuned), and grow the RISE Board Farm to host a more diverse set of hardware in dedicated pools.
For workflow authors, the only label that matters today is ubuntu-24.04-riscv (Ubuntu 24.04 on Scaleway EM-RV1). The full label reference lives in the documentation.
What is still rough
A few items worth being honest about:
- Capacity headroom is thin. Current peaks fit within available capacity, but a sudden surge from a single large project would saturate us. We are already the largest users of Scaleway EM-RV1, and we are working with them on EM-RV2, which should bring meaningfully better and faster machines.
- Observability for users is limited. The public job feed is unstyled and read-only. Users deserve better introspection into their own jobs: queue position, recent failures, and any limits applied.
- Kernel & Virtualization. The EM-RV1 nodes run an older vendor kernel (5.10.x) and do not support virtualization, which has bitten us in places. The real fix is upstream: RISE is contributing full TH1520 support to mainline Linux so we can move to recent kernel versions and stop carrying vendor patches.
Getting involved
The runners are in active use, no allowlist, no approval. If you maintain a project that should test on RISC-V, the simplest contribution is to 1. install the GitHub app, and 2. open a PR adding runs-on: ubuntu-24.04-riscv to a workflow you care about.
The full reference docs are at riseproject-dev.github.io/riscv-runner; labels, configuration, architecture, FAQ. Have a look, and please contribute!
If you want to discuss whether a particular workload fits on the existing hardware, or sort out anything else, the issues on riscv-runner-app are the fastest path.
We will keep posting updates as the platform evolves.
