Windows arm64 hosted runners now available for free in public repositories (Public Preview)

[tuves]

We’re excited to announce that Windows ARM64 hosted runners are now available in public preview and free to use in public repositories! This new runner comes with a Windows 11 Desktop image, fully equipped with the tools you need to get started running your workflows seamlessly.

Building on the release of linux arm64 hosted runners earlier this year, this marks an important milestone in extending Windows support to the open-source community. These four vCPU runners offer a power-efficient compute layer for Windows workloads, enabling ARM-native developers to build, test, and deploy entirely within the ARM64 architecture—without virtualization—directly in your GitHub Actions runs.

How to Use the New Runners

To start leveraging the ARM64 hosted runners in your workflows, simply add the following label in your public repository workflow runs:

runs-on: windows-11-arm

A few important notes:

• This label is exclusive to public repositories. Attempting to use it in private repositories will result in a workflow failure.
• Usage in public repositories adheres to GitHub’s standard runner usage limits, with maximum concurrency determined by your plan type.
• As the ARM64 runners are in public preview, you might experience longer queue times during peak usage hours.

Enhanced Images for Larger ARM64 Runners

In partnership with Arm, we’re introducing a Windows 11 Desktop ARM64 image with preinstalled tools, now available across all GitHub runner sizes. This includes both the new free offering and our existing ARM64 larger runners.

To use the new image on larger runners:

1. Create a new runner in your repository or organization.
2. Select the Microsoft Windows 11 Desktop by Arm Limited image from the Images console.

For the full list of installed software, to provide feedback, or to report issues, visit the partner-runner-images repository.

Get Started Today!

Ready to build Windows on ARM64 for free? Add the new label to the runs-on syntax in your public Actions workflow file and get started today. For more details on ARM64 runners and usage instructions, check out our documentation and join the conversation in the Community discussion.

---

This is a game-changer for ARM-native developers, and we’re thrilled to see what you’ll build with this new capability. Happy coding!

[dscho]

Nice! I've waited for these for a long time.

Something I noticed immediately: The link (see e.g. here) to the document with the list of included software is not working, neither is the one to the image release:

Included Software: https://github.com/actions/runner-images/blob/win11/0.0/images/windows/Windows11-Arm-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/win11F0.0

Would there be a chance to push the tag(s) so that these links work?

[dennisameling]

That looks like a bug to me, because the list of installed software is in the partner-runner-images repository instead: https://github.com/actions/partner-runner-images/blob/main/images/arm-windows-11-image.md

[jay0lee]

This was working earlier today but now my jobs never get picked up. I'm guessing there's an issue with this runner image at the moment?

[Nielsbishere]

I seem to be able to run these however the architecture somehow stays x86_64 (at least that's what conan & cmake detect).

[dscho]

maybe windows has emulation for x64 on arm64

It most certainly does!

[Nielsbishere]

An update on what's going on here: Even though a bat file knows the right architecture (ARM64) the default python installed with the runner somehow returns AMD64 :) python3 -c "import platform; print(platform.machine())"

https://github.com/Nielsbishere/gh_repo_arm/blob/main/.github/workflows/arm.yml

As you can imagine, this results in all sorts of weird behavior, such as conan thinking the host is AMD64 even though it's not.

Need help to get this fixed. (I think this is just because it runs an x64 python binary through emulation)

[hugovk]

I get "ARM64" when installing Python using https://github.com/actions/setup-python. For example:

• https://github.com/hugovk/test/actions/runs/14516246173/job/40725885829#step:6:28
• https://github.com/hugovk/test/actions/runs/14516246173/workflow
  "Python 3.13.3 (tags/v3.13.3:6280bb5, Apr 8 2025, 15:28:43) [MSC v.1943 64 bit (ARM64)]"

And "AMD64" when using whatever Python is the default in the runner image:

• https://github.com/hugovk/test/actions/runs/14516349275/job/40726195010#step:5:22
• https://github.com/hugovk/test/actions/runs/14516349275/workflow
• "Python 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 bit (AMD64)]"

I suggest using actions/setup-python to install Python.

[Nielsbishere]

@hugovk Thank you, I'll try it out but I'm sure that works. Hopefully it gets fixed in future runners so other people don't run into it too. There's also an issue here actions/partner-runner-images#85 as I was told by others.

[mstorsjo]

As noted above, the default version of CMake installed in the runner images is an x64 version, and this causes CMAKE_SYSTEM_PROCESSOR (and CMAKE_HOST_SYSTEM_PROCESSOR) to be set to AMD64. (CMake does that here by inspecting the PROCESSOR_ARCHITECTURE or PROCESSOR_ARCHITEW6432 env variables. When an x64 binary runs emulated, PROCESSOR_ARCHITECTURE also is set to AMD64.)

One slight tricky aspect here is that one may be tempted to manually set -DCMAKE_SYSTEM_PROCESSOR=ARM64 when configuring CMake, however when CMake isn't cross compiling, it also overwrites any user specified CMAKE_SYSTEM_PROCESSOR with the value of CMAKE_HOST_SYSTEM_PROCESSOR here. So in order to override it, one has to set both -DCMAKE_SYSTEM_PROCESSOR=ARM64 and -DCMAKE_SYSTEM_NAME=Windows, making CMake operate as if you were cross compiling.

[Avasam]

For anyone else making the jump from windows-2019:

windows-2022 removed a bunch of VisualStudio components from being installed by default. You may have to re-install them yourselves. See

• [Windows-2022] Multiple VC Build Tools will be removed on May, 13 actions/runner-images#9701
• Missing atlbase.h file in windows-2022 runner actions/runner-images#9873 (comment)

[joergbaier]

Now that we have arm64 Linux & Windows as "standard runners" for public repositories. Can we expect these "standard runners" for private repositories as well? The architecture is more cost-effective.

[Gustl22]

I would expect to have the same output for:

- run: echo $PROCESSOR_ARCHITECTURE
  shell: bash

Returns: AMD64 -> Wrong

- run: echo $env:PROCESSOR_ARCHITECTURE
  shell: pwsh

Returns: ARM64 -> Right

I strongly think, that is due to that bash is installed as x86 version:

Run bash --version
GNU bash, version 5.2.37(1)-release (x86_64-pc-msys)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

[dscho]

The reason has nothing to do with GitHub or hosted runners, but with the gigantic amount of work required to address the underlying problem: The Bash used on Windows-based runners is Git for Windows' Bash, and that Bash uses as POSIX emulation layer the MSYS2 runtime. That in turn requires the entire MSYS2 toolchain to be ported to Windows/ARM64. The MSYS2 toolchain is based on Cygwin, and that is being ported to Windows/ARM64 for the past few years. See e.g. msys2/MSYS2-packages#3834 for more details.

[samus-aran]

We’ve just announced arm64 standard runners are now available in private repositories: check out the changelog here.

We’d love to hear how it’s going for you: share your experiences in our feedback discussion here ❤️