When Red Hat sends people to an open hardware summit, it is a signal worth paying attention to.
I had the chance to catch up with Brian Harrington from Red Hat at RISC-V Summit Europe 2026 in Bologna — and our conversation was a good reminder that the convergence between RISC-V and the cloud-native stack is no longer a roadmap item. It is happening in production code, in upstream projects, and in real deployments.
Why Red Hat Is at a RISC-V Summit
Red Hat’s presence at RISC-V Summit Europe is not accidental. The company has been involved in RISC-V upstream work for several years, primarily through contributions to the Linux kernel and the GNU toolchain — the foundational software layers that any RISC-V platform depends on.
What has changed recently is the scope of that involvement. As RISC-V silicon has moved from embedded and research to server-class deployments — think EPIC Semi’s AI server running Ubuntu or Scaleway’s EM-RV1 RISC-V cloud instances — the cloud-native toolchain becomes relevant in a way it was not when RISC-V was primarily a microcontroller ISA.
Running Kubernetes on RISC-V requires:
- A container runtime (containerd, CRI-O) built and tested for
riscv64 - Container images that support
riscv64multi-arch builds - A scheduler that understands RISC-V-specific hardware topology (vector units, AI acceleration cores)
- An operator ecosystem that does not assume x86 or ARM as the baseline
Red Hat has contributed to all of these layers. RHEL and CentOS Stream now publish riscv64 packages. OpenShift has been tested on RISC-V hardware in lab environments. The work is incremental but it is real.
The Convergence Is Structural, Not Just Technical
What Brian articulated — and what the summit made tangible — is that the RISC-V and cloud-native movements share a structural alignment that goes beyond technical compatibility.
Both are built on open standards and collaborative governance. RISC-V International manages the ISA specification the same way the CNCF manages Kubernetes and its related projects: through an open membership model where contributions and decisions are made in the open. Neither is controlled by a single vendor. Neither has a single point of lock-in.
For enterprises building long-horizon infrastructure — the kind of platform that needs to be serviceable and extensible over ten years, not just three — that structural alignment matters as much as any benchmark. You can build on RISC-V and Kubernetes with confidence that the rules of the road will not change unilaterally, because neither has a single vendor with the power to change them.
This is the same argument behind RISC-V’s case for European digital sovereignty: open standards reduce dependency on any single nation’s export controls, supply chains, or commercial decisions.
What Is Still Ahead
The honest assessment is that RISC-V cloud-native is early. Container registries are still catching up on riscv64 multi-arch support — many popular images simply do not have RISC-V builds. Toolchain maturity varies: some language runtimes are well-supported (Go, Rust, C/C++), others have gaps. Hardware availability for testing is limited outside of community programs like Scaleway’s early-access RISC-V instances.
The trajectory, however, is clear. The Linux kernel RISC-V port is mature. The GCC and LLVM toolchains support RVV 1.0 and the broader RVA23 profile that server-class RISC-V hardware is targeting. The RISC-V ecosystem in 2026 spans dozens of vendors across embedded, laptop, and server form factors.
When Red Hat shows up at RISC-V Summit, they are not betting on something speculative. They are doing the upstream work now so that when RISC-V server silicon becomes widely available, the software stack is ready.
From Custom Silicon to Cloud-Native Platforms
The broader point — that the future is open, from ISA to orchestration — is one I find compelling for a specific reason: it describes a supply chain where every layer can be inspected, contributed to, and replaced without negotiating with a proprietary vendor.
That is what platform engineering at its best looks like: a stack of choices you own, not a stack of dependencies you are locked into. RISC-V at the silicon layer and Kubernetes at the orchestration layer are increasingly pointing to the same answer.
Related Coverage from RISC-V Summit Europe 2026
- DeepComputing DC-ROMA: DeepSeek on a RISC-V Laptop
- EPIC Semi’s First RISC-V AI Server Runs Ubuntu
- RISC-V and European Digital Sovereignty
- RISC-V Containers and Kubernetes
- RISC-V Summit Europe 2026: Bologna Highlights
About the Author
I am Luca Berton, AI and Cloud Advisor. I work at the intersection of open-source infrastructure and enterprise AI deployments. Book a consultation.
