CNCF Triggers a Platform Parity Breakthrough for ARM64 and x86

Cloud Native Computing Foundation (CNCF) needed ARM64 parity with x86 in GitHub Actions CI. Developers faced slow QEMU emulation and insecure self-hosted runners, creating inconsistent builds and blocking ARM64 adoption. The breakthrough came with Actuated: secure, isolated microVMs running on Ampere® Altra® CPUs at Equinix Metal. With a single-line config tweak, CNCF projects such as OpenTelemetry and Falco migrated to native ARM64 CI/CD, delivering stable performance and predictable results. The solution demonstrated real demand for ARM64 parity and provided a practical path forward. The momentum helped nudge GitHub to roll out official ARM64 hosted runners, expanding options for cloud-native teams and setting a resilient, scalable baseline for ARM64 ecosystems.

GitHub dominates the hosting of software projects these days. The most popular way that GitHub-hosted projects generate builds and releases for Continuous Integration (CI) is with the platform’s built-in CI toolset, GitHub Actions. The most important role played by the GitHub Actions CI/CD platform is the automation of software development pipelines. The party responsible for triggering any GitHub Action is a runner. It’s an agent running on a server, waiting for something to do and eager to do it once it’s given the assignment. It’s given a job from the workflow and tasked with getting it done.

GitHub is a complete software deployment platform. As such, it hosts its own runners, each of which is adapted to its specified target environment and architecture. Until recently, GitHub did not offer hosted runner environments for ARM64. Projects that wanted to generate ARM64-native builds did have an option – the self-hosted runner. GitHub users could install an agent on a physical or virtual machine hosted elsewhere, and have GitHub Actions dispatch jobs to that host, managed by the project users. This required project administrators to not only manage the project itself, but also to take care of the maintenance and security of the build environment that the projects would use.

In CNCF’s case, developers took advantage of credits to Equinix Metal, enabling them to provision bare metal instances use them as self-hosted runners for projects. But for a code lab whose projects must be made available 24/7/365 to other developers worldwide, the security of self-hosted runners poses a challenge: Anyone could clone the project repository, modify the Actions jobs, and get access to the runner node to run arbitrary jobs, according to GitHub documentation.

Another problem was ensuring consistency between CI runs. With self-hosted runners, if there were side-effects of the CI jobs, such as configuration changes or files left behind afterwards, they would still be there for ensuing jobs. This posed a problem – when running a CI job to build or test software, you should have a controlled environment, so that the only thing that changes between runs is the software. In the case of self-hosted runners, the environment can drift over time. In the absence of a cleanup process, it was possible for runs of the same build job on the same host to generate different results over time.

One way developers bypassed the need for ARM64 native runners was by running virtual ARM64 environments on x86 servers, using QEMU open source emulation. Emulated environments add a huge performance overhead for software compilations, which run at a fraction of the pace of compilations on native, non-emulated hardware. Emulation worked well enough for developing small to medium projects. But if developers had to build something big and important for ARM64, the strain would become so great on their virtual environments that builds would completely fail.

Unlike the typical enterprise, the Cloud Native Computing Foundation has a special obligation to build its cloud-native components for all the world’s major processor architectures. Projects such as the containerd portable container runtime, the etcd key/value data store, the fluentd log data collector, the Falco real-time threat detection tool, and the OpenTelemetry observability and instrumentation toolkit, among dozens of others, are critical dependencies for the cloud native ecosystem, and as such, must be built for both x86 and ARM64.

To build low-level infrastructure components with support for ARM64, CNCF developers need access to native ARM64 infrastructure. This means, ironically, they need the very class of tools they’re trying to create. At first, Ampere and Equinix collaborated with CNCF to overcome these gaps, by donating Ampere Altra-based servers or setting up Altra-based bare metal nodes at Equinix facilities. The granularity of the ARM64-based server resources that Equinix could share were bare metal nodes – 160 core dual-socket Ampere Altra system. Ideally, a server like this would be shared among several projects, but this was, at the time, beyond the capabilities of the CNCF. This is the problem that Ampere and Actuated proposed to solve for CNCF, by allowing multiple projects to run on a smaller number of hosts, thus providing easy access to build services for more projects, while consuming less hardware.

As a result of the lack of availability of easily available ARM64 platforms for these projects, developers were unaware if changes they were committing were causing issues on ARM64, because test suites were not being run as frequently as for x86. Since container orchestration platforms are among the platforms being developed to support Arm64, this phenomenon became a vicious cycle: Releases were gated on passing integration test suites for x86, but releases were not gated on the same test suites passing for ARM64.

The solution CNCF’s developers would discover falls far short of qualifying as radical or revolutionary — in fact, it’s more of a bug fix in practice. It’s so simple to implement that it completely compensates for this disparity not just for CNCF but for any developer of any platform-level component for any architecture.

To take the first step towards platform parity between x86 and ARM64, Ampere enlisted the help of Alex Ellis, the creator of a service called Actuated. It’s a product that runs GitHub Actions jobs in secure, isolated microVMs, instrumented to receive build jobs from GitHub Actions, and offering developers visibility into the performance of their build jobs, and the load on the shared build systems.

Actuated could run all the CNCF’s existing GitHub Actions runners after altering a single line of their configuration files, plus in some cases the pasting of a few code snippets — changes which took less than five minutes to implement. These changes enabled GitHub-hosted projects to point to Actuated’s microVM-driven environment on Ampere Altra processors for their build jobs.

Having seen the increase in demand for Arm native build environments in recent years, GitHub announced last June the availability in public beta of ARM64-based hosted runners for GitHub Actions, powered by Ampere compute instances on Microsoft Azure, followed in January 2025 by the release into public preview of free hosted runners for public repositories. For OpenTelemetry, this means the end of network loads as high as 10 times their assigned bandwidth caps, on account of OpenTelemetry builds constantly downloading dependencies from Docker Hub repositories.

Now for the first time, project maintainers can pay as close attention to the safety and security of ARM64 builds as they have for x86 builds, knowing that they’re no longer likely to encounter performance degradations or penalties.

For its part, Oracle is continuing its policy of donating $3 million per year in OCI credits for ARM64 instances powered by Ampere to CNCF projects. This generosity, coupled with the new-found stability of ARM64 platforms catalyzed by Ampere and Equinix, and brought about by Actuated, is enabling prominent cloud infrastructure vendors including Red Hat, SUSE, Canonical, and Mirantis to provide full support for their enterprise customers who choose ARM64 infrastructure.

Parity makes it possible for enterprises to make sensible choices about their computing infrastructure and platforms without incurring penalties just for choosing an alternative architecture. Large cloud customers are proving that ARM64 can provide organizations with the performance they need, and reduced expenses for workloads–all with industry-leading energy efficiency. But organizations can’t experience those benefits until they can deploy their workloads on all infrastructure options on a level playing field with one another, and measure the results for themselves.

In early 2023, few options existed for GitHub-hosted projects who wanted to fully integrate ARM64 into their Continuous Integration processes. Through this initiative, leveraging an innovative software solution from Actuated with Ampere CPUs hosted by Equinix, lowered the bar for CNCF projects to make a start towards partity of support for ARM64 and x86. Key cloud native projects including etcd, containerd, Open Telemetry, Falco, and others were able to advance their support of ARM64, accelerate their CI runs on native ARM64 infrastructure, and support increasing numbers of their users taking advantage of ARM64 compute in the cloud.

By the end of this pilot project, the number of options for developers has grown considerably. The CNCF now offers its projects the ability to run GitHub Actions jobs on managed Kubernetes clusters on OCI, using Ampere-powered instances and the GitHub project Actions Runner Controller, and with the addition of hosted ARM64 runners to GitHub, it has never been easier for projects to easily support this fast-growing and exciting architecture for cloud native applications.