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

[samus-aran]

Now in public preview, Linux arm64 hosted runners are available for free in public repositories. Following the release of arm64 larger hosted runners in June, this offering now extends to the open source-community. ❤️

Powered by the Cobalt 100-based processors, these 4 vCPU runners can deliver up to a 40% performance boost compared to Microsoft Azure's previous generation of Arm-based VMs, providing a power-efficient compute layer for your workloads. Arm-native developers can now build, test and deploy entirely within the arm64 architecture without the need for virtualization on your Actions runs.

How to use the runners

To leverage the arm64 hosted runners, add the following labels in your public repository workflow runs:

• ubuntu-24.04-arm
• ubuntu-22.04-arm

Important

Please note that these labels will not work in private repositories, and the workflow will fail if added.

All runs in public repositories will adhere to our standard runners usage limits, with maximum concurrencies based on your plan type. While the arm64 runners are in public preview, you may experience longer queue times during peak usage hours.

Images

In partnership with Arm, GitHub provides the Ubuntu VM images for these runners, helping customers with a seamless start to building on Arm. To view the list of installed software, give feedback, or report issues with the image, visit the partner-runner-images repository.

Get started today!

To get started, simply add one of the new labels to the runs-on syntax in your public Actions workflow file. For more information on arm64 runners and how to use them, see our documentation.

Share below what open source projects you maintain and how using GitHub Linux arm64 hosted runners will benefit you! Let us know how much speed performance they improve 🏎️ 🏎️

Read GitHub changelog

[bjorn3]

I tried using this in https://github.com/rust-lang/rustc_codegen_cranelift/actions/runs/12814835730/job/35732202343, but it seems that the cargo binary is not marked as executable.

[CodeDoctorDE]

Hello, i have the same issue that the directory permissions are wrong, see https://github.com/orgs/community/discussions/148648#discussioncomment-11858098

[bjorn3]

This looks to be resolved now.

[CodeDoctorDE]

I tested it a bit, but it looks like it uses the wrong permissions:

warning: unable to access '/home/runneradmin/.config/git/ignore': Permission denied
warning: unable to access '/home/runneradmin/.config/git/attributes': Permission denied
warning: unable to access '/home/runneradmin/.config/git/config': Permission denied
warning: unable to access '/home/runneradmin/.config/git/attributes': Permission denied
warning: unable to access '/home/runneradmin/.config/git/ignore': Permission denied
warning: unable to access '/home/runneradmin/.config/git/attributes': Permission denied
warning: unable to access '/home/runneradmin/.config/git/ignore': Permission denied

This is the error why it fails:

Error: Flutter failed to create a directory at "/home/runneradmin/.config".

this is my github action: https://github.com/LinwoodDev/Butterfly/blob/7cb574ed18fea6f8aa825069dcd8955cae99d1e7/.github/workflows/build.yml

https://github.com/LinwoodDev/Butterfly/actions/runs/12815058129/job/35732903060?pr=787

[Rhys-T]

The permissions are actually right - the environment variables are just pointing at the wrong directories (see actions/partner-runner-images#25, actions/partner-runner-images#27).

If you need a temporary workaround for now, this is what I'm using. It's based off of actions/partner-runner-images#25 (comment), but adapted to fix both of the affected variables.

# Insert this at the beginning of the `steps` array:
    - name: Fix environment for ARM64 Linux runners (actions/partner-runner-images#25)
      run: for var in PATH XDG_CONFIG_HOME; do sed -Ee "s/^/${var}=/" -e 's/(runner)admin/\1/g' <<< "${!var}"; done | tee -a "$GITHUB_ENV"

Edit: $HOME actually seems to be right on mine, but if it's giving you problems too, you can just add it to the for loop.

[nazar-pc]

Seems to be fixed, my latest build proceeded past that error now

[balupton]

yep fixed

[maxim-lobanov]

Hello, rollout of the fix is finished. Let us know if you still see the same issue.

[kjxbyz]

See https://github.com/orgs/community/discussions/149529

[cdce8p]

Is there a plan to add a ubuntu-arm-latest tag similar to ubuntu-latest?

[xlionjuan]

I think people who using latest knows the risk, but some jobs are too simple that making latest not that dangerous, the more ARM runners are adopted, the more the footprint is reduced, isn't it?

[tats-u]

@lkfortuna It is a pain in the neck to update labels in many workflow files every 2 years. It is a bad decision not to add it.

[ferferga]

This is the 2nd most voted message from this thread, yet it seems that they don't care.
It's also super inconsistent that the amd64 runners have latest and arm does not. If this is the way they want to go, then remove latest from amd64 as well (why I give them more ideas though?)

[tiagoliveira9]

@lkfortuna Does GH have any plans to add this to the roadmap? Providing GitHub-owned Linux ARM image?

[samus-aran]

Hey folks (in this reply), we want to share that this particular request was highlighted in the latest announcement here. To help gain more visibility we are utilising another discussion specifically for this request if people want to add more to it. Your existing votes/reactions on this will still be tracked but felt for easier reference to have it's own. 👍

[darthmaim]

The new runners don't report that they are ARM and have incorrect links in the "Set up job" step:

The "Runner Image" should report ubuntu-24.04-arm and the included software should link to https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-24-image.md

[lkfortuna]

Hey @darthmaim! We are aware of this issue and are working on a fix for it. Thanks for reporting!

[FoxxMD]

I'm puzzled about my perceived lack of performance gains using the new runners...

For my project building a multi-platform docker image using GHA with QEMU/buildx/build-push-action on a normal runner has always taken a long time (11-13min) -- and the majority of that time was spent on the arm emulation part of the build. The x86 part takes ~1:30 while arm finishes in 9-10 minutes. I've always expected this would be the case due to the emulation.

But now I've tried the new runner using a GHA where a matrix builds my image on separate runners, arm/x86 native without QEMU, and the difference in build time is only about 8% faster. I'm scratching my head about why this isn't improved more. For an absolute comparison, the project builds the same docker image (for arm platform only) on my Raspberry Pi 5 in 1:40 and 1:50 on my RPI4b (compared to 8:37 on ubuntu-22.04-arm).

Is this expected? Are the new runners this anemic in terms of performance?

EDIT: AS @darthmaim mentions below the solution is to use runs-on: {{ matrix.os }} as well as configuring the matrix to use the correct image/arch/os. Build times are now down to 2min. The working workflow here

[darthmaim]

You have to change your runs-on: ubuntu-latest to runs-on: {{ matrix.os }}.

I have a similar workflow that went from ~14 minutes using QEMU to ~2 minutes using the ARM runner.

[nightlark]

I'm seeing a similar (or better?) performance improvement. I have a Docker image build for arm64 that was taking at 3.5 hours with QEMU, and after switching to the native arm64 runners it finished in 16 minutes.

[nightlark]

Are there any ways to further improve the build time with the new runners?

The build times I’ve seen so far are the same or slightly faster than the same build on the amd64 Linux runners. What are you looking for? Could always pay for a larger runner instance with more cores if your build/tests can take advantage of the increased parallelism.

[FoxxMD]

Thank you @darthmaim that did the trick. Down to 2 minutes for execution on the arm build now 👍

[kjxbyz]

See https://github.com/orgs/community/discussions/149347

[lkfortuna]

hey @kjxbyz - we are aware of the issue and are in process of rolling out a fix

[kjxbyz]

If the issue is fixed, please reply in this discussion. Thank you!

[maxim-lobanov]

Hello, rollout of the fix is finished. Let us know if you still see the same issue.

[Athou]

The ubuntu-24.04-arm runner seems to miss the libgbm1 package:

╔══════════════════════════════════════════════════════════════════════════════════════════════════════╗
║ Host system is missing dependencies to run browsers.                                                 ║
║ Please install them with the following command:                                                      ║
║                                                                                                      ║
║     sudo mvn exec:java -e -D exec.mainClass=com.microsoft.playwright.CLI -D exec.args="install-deps" ║
║                                                                                                      ║
║ Alternatively, use apt:                                                                              ║
║     sudo apt-get install libgbm1                                                                     ║
║                                                                                                      ║
║ <3 Playwright Team                                                                                   ║
╚══════════════════════════════════════════════════════════════════════════════════════════════════════╝

See https://github.com/Athou/commafeed/actions/runs/12823180867/job/35757289975

The package is installed on ubuntu-latest. I fixed this with this but it would be nice if the packages installed on both ubuntu runners were the same 😊

  - name: Install Playwright dependencies
    run: sudo apt-get install -y libgbm1
    if: matrix.os == 'ubuntu-24.04-arm'

[lkfortuna]

Hi there- for image related feedback, please open an issue in this repo! https://github.com/actions/partner-runner-images

[jacob-carlborg]

Would have been nice to have support for hardware accelerated nested virtualization (KVM). Seems it's not available:

$ sudo modprobe kvm
$ sudo /usr/sbin/kvm-ok
INFO: /dev/kvm does not exist
HINT:   sudo modprobe kvm
modprobe: FATAL: Module msr not found in directory /lib/modules/6.8.0-1017-azure
$ sudo dmesg | grep -i kvm
[    0.585208] kvm [1]: HYP mode not available

Does anyone know if there's a limitation in hardware, the virtualization layer or if it's just not configured to be enable?

[lkfortuna]

hey there- nested virt is not supported for this sku https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dpdsv6-series?tabs=sizebasic#feature-support

[jacob-carlborg]

That's disappointing 😞, but thanks for letting us know.

[lkfortuna]

as soon as azure supports it, we can support it, but just blocked until then.

[tamird]

Hi @lkfortuna looks like it is supported on 7-series SKUs https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dasv7-series?tabs=sizebasic. Are there any plans to offer these? my mistake, only the dp* SKUs are arm64.

[orazioedoardo]

No ubuntu-20.04-arm runner? Technically it's still supported.

EDIT: Ok, saw this as well https://github.blog/changelog/2025-01-15-github-actions-ubuntu-20-runner-image-brownout-dates-and-other-breaking-changes/

[dalcinl]

From time to time, actions/checkout@v4 is failing but I see no output, for example:
https://github.com/mpi4py/mpi4py-publish/actions/runs/12827690739/job/35770199992#step:2:1

I'm also seeing some docker instabilities when running jobs that have large matrices. Typical error messages are:

https://github.com/mpi4py/mpi4py-publish/actions/runs/12827690739/job/35770200582#step:10:398

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: unable to apply cgroup configuration: unable to start unit "docker-8fd5c4828e7358dfa718c5dddf5f48350fc6a3e059fba62947fb8c540ddbf3fd.scope" (properties [{Name:Description Value:"libcontainer container 8fd5c4828e7358dfa718c5dddf5f48350fc6a3e059fba62947fb8c540ddbf3fd"} {Name:Slice Value:"system.slice"} {Name:Delegate Value:true} {Name:PIDs Value:@au [4710]} {Name:MemoryAccounting Value:true} {Name:CPUAccounting Value:true} {Name:IOAccounting Value:true} {Name:TasksAccounting Value:true} {Name:DefaultDependencies Value:false}]): Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms): unknown```

https://github.com/mpi4py/mpi4py-publish/actions/runs/12827690739/job/35770199123#step:10:287

+ docker version -f '{{json .}}'
  Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

[dalcinl]

Here you have an example of actions/checkout@v4 failing 4 times in a matrix of 48 rows:
https://github.com/mpi4py/mpi4py-publish/actions/runs/12842120486/attempts/1

[sterliakov]

+1, I also reported this to actions/checkout (actions/checkout#2064, with another workflow and relevant logs), but probably there is some issue to solve on the runner level.

[brandond]

For the Is the docker daemon running? error, we've had to add a while ! docker version; do sleep 1; done to the start of our arm jobs. It seems like these nodes are a good bit slower and docker isn't up yet when the step runs some portion of the time.

[lkfortuna]

Hey there- we are still investigating but we believe if you use the ubuntu-22.04-arm runners this will fix the issue, do you mind testing on that runner?

[pllim]

Hello. I ran into permission problem using this new runner with tox. This same workflow was using paid linux-arm64 before and did not have such problem. Please see:

• TST: Use free Linux ARM64 runner astropy/astropy#17645

[lkfortuna]

the permission issue has been fixed

[nazar-pc]

Should have been called -arm64 or -aarch64

[eregon]

Agreed, it's odd to have macos-14-arm64 but ubuntu-24.04-arm.
Also Node.js os.arch() is arm64, as is core.platform.arch.

[nazar-pc]

uname -p is aarch64, so are many Linux packages and other things, but arm is the worst possible option, it is inconsistent with basically everything

[eregon]

Yeah, arm sounds like 32-bit ARM which is not the case.
Even the first post above mentions "arm64" 7 times.

FWIW I tried ubuntu-22.04-arm/ubuntu-24.04-arm64 but those are not recognized.
Would be nice to at least make them aliases.

[webknjaz]

$ python3.13 -c 'import platform;print(platform.machine())'
arm64

[mhemani-reach]

Are there plans for a ubuntu-latest-arm label?
Are there plans to allow free usage in private repos (especially for Enterprise Cloud)?

[rvanlaak]

@johnnyplaydrums meaning you can run ARM on private repositories? Is it correct that you've then configured it like runs-on: macos-latest or runs-on: macos-15-arm like in https://github.com/actions/runner-images/blob/main/images/macos/macos-15-arm64-Readme.md ?

Ref: https://docs.github.com/en/actions/writing-workflows/choosing-where-your-workflow-runs/choosing-the-runner-for-a-job#standard-github-hosted-runners-for-public-repositories

Another +1 here to prioritize the Arm runners for private repos.

[thom-nic]

We do offer them in private on our larger runners, they just do not consume entitlement minutes.

@lkfortuna it's not clear how I can get a "ubuntu arm64 large" runner. We have enabled larger runners for our org, however I only see ubuntu-latest-m and windows-latest-l Found it, had to create a new runner. Thanks!

[oom-]

Hi there- we do not currently have plans to add a -latest label. We will support ubuntu24 and ubuntu22 with ubuntu24 being the most up to date image until ubuntu26 comes out.

We have found that the latest tag causes confusion, with people thinking that we do not keep the other image tags up to date. Both images are being actively maintained by Arm.

We also will eventually allow these for use in private, that is targeted for H2 this year.

hello @lkfortuna, I suppose it wasn't a firm date, but is this still planed ?
many thanks

[ds5678]

I too am curious about an update on the timing.

[jsoref]

@lkfortuna I can't find private linux arm runners on the roadmap: GitHub Public Roadmap (view)

Should we take it that it has fallen off the roadmap?

Note that anyone interested in doing things today in private repositories can create a private runner using the Arm partner image (the GitHub base image doesn't have docker amongst other things): https://github.com/orgs/community/discussions/148648#discussioncomment-13379180 -- the billing is different and the UX for this is painful, but it is a thing that's available today.

[dennisameling]

Ran into this error while testing the new ubuntu-22.04-arm runners:

JavaScript Actions in Alpine containers are only supported on x64 Linux runners. Detected Linux Arm64

Looks like there's an open issue for this since 2020. Any chance this could be prioritized? Thanks!

[userdocs]

Until you can run commands on the host before the container is set up the system is crippled anyway.

You have always been able to call a docker image on demand from the runner and not use container:

https://github.com/userdocs/test/actions/runs/12828579208/workflow

As you can see build-3 does not fail, which is why I don't have this issue.

[eregon]

I've never seen this error before, only on these new linux-arm64 images:
https://github.com/ruby/ruby-builder/actions/runs/12844097279/job/35816748560

Run gh release upload "toolcache" "ruby-3.2.4-ubuntu-22.04-arm64.tar.gz"
failed to create root command: failed to read configuration: open /home/runneradmin/.config/gh/config.yml: permission denied

Restarting the failed jobs is a workaround but obviously not ideal.

[lkfortuna]

This was related to the permissions issue we had last week - we rolled out a fix so that is why you saw this succeed on retry. It should not be an issue going forward.

[LesnyRumcajs]

After switching to ubuntu-24.04-arm we get quite a lot of failures on checkout@v4. It wasn't the case for ubuntu-24.04.

Samples:

https://github.com/ChainSafe/forest/actions/runs/13176064234/job/36775533964?pr=5245

Workflow https://github.com/ChainSafe/forest/blob/6ba1931312430901371694ec14e1ea101dfdc683/.github/workflows/butterflynet.yml

https://github.com/ChainSafe/forest/actions/runs/13176045079/job/36775467670?pr=5247

Workflow https://github.com/ChainSafe/forest/blob/25627734910c5d3bd8587b488caf6477fad07bb4/.github/workflows/scripts-lint.yml#L52-L71

[lkfortuna]

Hey there- we are still investigating but we believe if you use the ubuntu-22.04-arm runners this will fix the issue, do you mind testing on that runner?

[LesnyRumcajs]

I'll let you know if we still have the same issues under that runner. Thanks.

[Rhys-T]

I've switched my repo from ubuntu-24.04-arm to ubuntu-22.04-arm, and so far it seems more stable. Haven't seen it get these errors there yet, though it hasn't been using that runner for very long. I'll reply here again if I see it have problems with that runner.

(I did see one reference to the 22.04 runner also failing - actions/partner-runner-images#37 (comment) - but the same user's comments above seem to suggest that that turned out to be an unrelated issue.)

[jakob-keller]

(I did see one reference to the 22.04 runner also failing - actions/partner-runner-images#37 (comment) - but the same user's comments above seem to suggest that that turned out to be an unrelated issue.)

That is correct! Whatever I wrote with regards to ubuntu-22.04-arm was invalid.

[LesnyRumcajs]

@lkfortuna I can confirm that downgrading our workflows to ubuntu-22.04-arm made the checkout errors go away.

[consideRatio]

Issues with arm ubuntu 2204 and 2404 runners have gone away for jupyter/docker-stacks, no longer failing on actions/checkout and such! Nice!!

[mathbunnyru]

Update: unfortunately, still happens sometimes on 24.04: https://github.com/jupyter/docker-stacks/actions/runs/13287528395/job/37099753888?pr=2209

[lkfortuna]

Hey Everyone 👋 Thanks for your patience with the checkout errors and random failures. We discovered it was an issue with the underlying hardware and have migrated all the runners to a different arm sku (dpdsv5) and this should solve the errors you were seeing. Anyone who migrated to ubuntu 22 to solve the issue should be able to move back to ubuntu 24 with no problems as well. We reported the issues to the Microsoft Azure team and they are working to debug them, but in the meantime we have moved our runners so that you can use the runners without issue.

[martin-frbg]

Is it possible that the sku change could have led to ubuntu-24.04-arm jobs now executing on Neoverse N1 like the "large" ones instead of Cobalt100 ?
I've been using this setup successfully for CI testing OpenBLAS builds, but since yesterday builds for NeoverseN2 fail with illegal instruction errors during runtime tests, and querying the cpuid returns the one matching N1

[brandond]

It was mentioned in the comment that you are replying to that the runners now use dpdsv5 instance types.

Relying on CI to use any specific model or chipset is probably a bad idea though.

[martin-frbg]

Sure, but it is probably not ideal to have a blog post specifically announce availability of that specific model (NeoverseN2) under a certain job name that then leads to execution on different hardware - it would certainly be nice to know if the change is intentional
(end of the public preview or whatever).
(The VMs were not reliably reporting their cpuid early on, which is why I had resorted to specifying the build target instead of allowing the build script to autodetect it. Now that I have switched back to autodetection, it is definitely seeing NeoverseN1 since yesterday, which would match the Ampere Altra of dpdsv5.)

[lkfortuna]

Yes this was a purposeful change, we migrated the runners back to the v5 sku due to the errors mentioned in the issue comments above. The N2 machines were not working and causing failures so we have migrated back to N1 in order to unblock people from using the arm64 runners.

The change is intentional and like I mentioned in the comment above, we have reported the issues to Microsoft azure team, but until they can resolve them we will not be migrating these runners back.

[martin-frbg]

Thank you very much for this clarification.

[thesuperzapper]

I'm not sure how it would work on the backend, but the ability to run service containers on these new ARM runners, and access them from an X86 job would enable very simple multi-arch docker builds.

This would allow a docker buildx builder running on the ARM node to be accessed from the X86 node using a remote driver, and you can even combine multiple builders using docker buildx create --append ... on the X86 node.

Obviously, you could do something like run a VPN across your various jobs so they can talk to each other, but that does not account for the locality of the actually servers running these jobs, plus, having a job that only runs the builder service causes all sorts of "retry" issues.

[brandond]

Why would you need that? Just build the image for each arch separately and then merge them in a manifest step. Having the runners communicate between each other seems like an unnecessary additional complication.

[consideRatio]

For reference, building and combining arch-specific images and combining them is done in jupyter/docker-stacks repo

[baentsch]

Is this the right place to report issues with arm-runners? Two weeks ago, everything was working well, a specific job completed in 10 mins and now, it simply ceases to progress after different times in different run attempts. Github status is green. Sample job: https://github.com/open-quantum-safe/oqs-demos/actions/runs/13421069421/job/37692339114. Thanks for checking/letting me know where (else) to report this.

[lkfortuna]

this is the correct place, unless its an issue with the image itself in which case the images repo referenced above would be right. in this case though i think the issue is with the docker action itself since they just released a new version and it appears your workflow is using the latest version. Can you report this to the docker team that manages that action?

[baentsch]

Can you report this to the docker team that manages that action?

Thanks for the feedback! This raises 2 questions for me: 1) Who is this docker team/where can I reach them? 2) It does not seem to be a problem with the docker image but rather the way things are set up within GH: Apparently, this action (runner?) has no internet connectivity as the downloading of data from a public server fails just for arm64 (works OK for x64).

[lkfortuna]

hey @baentsch - we are trying to recreate on our end first to see if we can help narrow it down but we are unable to reproduce the error. Can you reproduce this reliably and send us the links to the runs?

[baentsch]

Thanks @lkfortuna for reaching out: https://github.com/open-quantum-safe/oqs-demos/actions/runs/13421069421 is the job that failed 2 times so far (the "sibling" x64 job always passes). Just triggered another re-run to see whether this qualifies for a "reliable reproducer". Let's see...

[baentsch]

Third time, the job passed. So, no reproducibility, sorry. Case closed but thanks for taking a look!

[lkfortuna]

Hey Everyone 👋 Another update here. Azure has fixed the issue with their dpdsv6 hardware. We have tested the fix and the errors we were seeing before are resolved.

We will be rolling out the dpdsv6 hardware to our public arm runners starting tomorrow. This will be a gradual rollout so your runs may not be moved onto the new hardware right away. If you encounter any issues, please continue to report them here. Thank you.

[lakshanthad]

Hey @lkfortuna. Thanks a lot for this! We have already deployed this in our production environments and they are working great so far!
ultralytics/ultralytics#19596

[Bnaya]

Is there ETA when arm is gonna be supported in regular private repos?

[lkfortuna]

https://github.com/orgs/community/discussions/148648#discussioncomment-11920086

[thom-nic]

It took me a while to figure out but you can create your own runners using a linux/arm64 base image:

This is an org on a "Github Team" plan.

[abarragan-adtriba]

@thom-nic, that's clearly not regular private repository as explained here https://github.com/orgs/community/discussions/148648#discussioncomment-13379582

[snadampal]

Hi @lkfortuna Are the Neoverse N2 instances enabled for ubuntu-22.04-arm runners as well? I don't see them in one of the repos using the ubuntu 22.04 runners. so, i believe they are not yet enabled. Is there any ETA for this?

[lkfortuna]

we have only rolled out to 50% so not all jobs are running on N2 right now.
We found that not all VMs were patched with the fix so we have paused the rollout and have not fully migrated all the runners to N2 yet.

[snadampal]

thank you! please post here when N2 is enabled for ubuntu-22.04-arm runners as well. We will check our CI then.

[snadampal]

I see N2 instances for ubuntu-22.04-arm runners. thank you!

[wcampbell0x2a]

I'm running into exec_format: /home/runner/work/_temp/be459d83-1e0e-4b7b-918f-1c7d65d1e053.sh: line 1: /home/runner/.cargo/bin/rustup: cannot execute binary file: Exec format error.

https://github.com/wcampbell0x2a/backhand/actions/runs/14811544007/job/41586818134?pr=711

[0x26res]

I had a similar issues. You need to change your cache key to include the arch (as well as the os)

https://github.com/wcampbell0x2a/backhand/blob/master/.github/workflows/cache/action.yml#L21

Something like:

${{ runner.os }}-{{ runner.arch }}-rsadsb-${{ hashFiles('**/Cargo.lock') }}

[wcampbell0x2a]

Hmmm. Tried that but still failures: wcampbell0x2a/backhand@778e1e9

[michealroberts]

Does anyone know when these will be available for private repositories?

Currently trying to get an arm64 ubuntu runner to work ...

[thom-nic]

It is now, at least for orgs on a "Github Team" plan. Go to https://github.com/organizations/YOUR_ORG/settings/actions/github-hosted-runners/new and you should see something that looks like this:

Not sure if individual accounts with private repos are different.

[rvanlaak]

Keep in mind that these Github hosted runners are different from public runners, and are billed separately as they do not account for free minutes. This is why they currently solely are available for Teams, as it is a requirement to have billing setup.

[jeankhawand]

[userdocs]

only if you get the name wrong.

https://github.com/jeankhawand/anki/blob/publish-registry/.github/workflows/build-publish.yaml#L29

https://github.com/actions/partner-runner-images?tab=readme-ov-file#available-images

[julianxhokaxhiu]

My job that uses the ubuntu-24.04-arm64 failed with

The job has exceeded the maximum execution time while awaiting a runner for 24h0m0s

For unknown reasons to me. Are these ARM runners really available? Is there anything special I need to do to enable the support on my own repo?

Thank you in advance

[lkfortuna]

You are using the wrong label, that is why it never finds a runners. See label names in the discussion post above.

How to use the runners
To leverage the arm64 hosted runners, add the following labels in your public repository workflow runs:

ubuntu-24.04-arm
ubuntu-22.04-arm

[julianxhokaxhiu]

My bad, I didn't noticed I misstyped the label. Thanks a lot :) Now it works like a charm! https://github.com/julianxhokaxhiu/leveldbCI/actions/runs/15693008550/job/44212271271

[julianxhokaxhiu]

Sorry one more question: I guess those runners can't be used to cross compile arm binaries right? Is there an additional step I might need to do to be able to accomplish so? See https://github.com/julianxhokaxhiu/leveldbCI/actions/runs/15693008550/job/44212271270 ( vcpkg is failing to find the compiler for the armv7 family )

[julianxhokaxhiu]

Ok nvm solved :) For anyone in need of this, here's the patch to make it work: julianxhokaxhiu/leveldbCI@d791935

Thanks again! Cheers

[leros1337]

Is there plans for enabling for private repos? Our org need this runners (we know can be self-hosted)

[thom-nic]

You can create your own ARM64 runners, see my previous comment. They function the same except you choose your own size, label, and there is no free tier. As long as your org is on a paid plan you should have no problem.

[abarragan-adtriba]

Is there plans for enabling for private repos? Our org need this runners (we know can be self-hosted)

as mentioned here, it's targeted for H2
https://github.com/orgs/community/discussions/148648#discussioncomment-11920086

[jsoref]

It was targeted for 2025H2 according to that message. It seems incredibly unlikely that it is still targeted for that and there isn't a sign of it on the roadmap: https://github.com/orgs/community/discussions/148648#discussioncomment-14906936

[aivoric]

I am really looking forward to arm64 runners in private repos. I had to upgrade to an organisation account and move my repo there just now in order to create a custom arm64 runner. Not very convenient...

[haslingerm]

At least getting an update on the ETA would be nice. I am still juggling self-hosted runners on a Pi while waiting and it's been months at this point.

[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 ❤️