Which Operating Systems Can GitHub Actions Runners Use?
GitHub Actions runners cover four platforms: Linux x64, Linux ARM64, macOS, and Windows. WarpBuild ships Ubuntu, macOS, and Windows Server images for each one.
Last verified:
GitHub Actions runners cover four operating system platforms: Linux on x86-64, Linux on ARM64, macOS on ARM64, and Windows on x86-64. WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners across those four platforms, with the Ubuntu release, the macOS version, and the Windows Server release selected by runner label (WarpBuild cloud runners, checked on 2026-08-13).
This page lists the image families that exist on each platform today, the label shape that selects them, the deprecations and removals with their dates, and which workload belongs on which platform.
Answer
There are three ways to put an operating system under a GitHub Actions job, and the platform list is the same in all three.
GitHub-hosted runners. GitHub publishes labels for Ubuntu, Windows Server, and macOS, on x86-64 and on ARM64. The label list and the per-minute rates are on the GitHub Actions billing reference.
Self-hosted runners. The runner agent ships releases for Linux x64, Linux ARM64, macOS, and Windows on github.com/actions/runner, so a machine you own on any of those platforms can register against a repository or organization and advertise labels. You own the image, the tooling on it, and the cleanup between jobs.
Managed runners. A provider registers ephemeral virtual machines against your GitHub organization and you pick the operating system by label. WarpBuild runs this shape, and each label encodes the platform, the image version, the architecture, and the size.
Here is the coverage on the managed side. Every row comes from the cloud runners documentation and the feature matrix, checked on 2026-08-13.
| Platform | Architecture | Image families | Label shape | Sizes | Per minute |
|---|---|---|---|---|---|
| Linux x64 | x86-64 | Ubuntu 22.04, Ubuntu 24.04, Ubuntu 26.04 | warp-ubuntu-<release>-x64-<size> | 2, 4, 8, 16, 32 vCPU | $0.004 to $0.064 |
| Linux ARM64 | ARM64 | Ubuntu 24.04, Ubuntu 26.04 | warp-ubuntu-<release>-arm64-<size> | 2, 4, 8, 16, 32 vCPU | $0.003 to $0.048 |
| macOS | ARM64 | macOS 14, macOS 15, macOS 26 | warp-macos-<version>-arm64-<size> | 6, 12 vCPU | $0.08 to $0.16 |
| Windows | x86-64 | Windows Server 2022, Windows Server 2025 | warp-windows-<release>-x64-<size> | 4, 8, 16, 32 vCPU | $0.016 to $0.128 |
Three absences in that table matter when you plan a matrix. Ubuntu 22.04 exists on x64 and has no ARM64 counterpart. Windows runners are x86-64 across every size. macOS runners are ARM64 and run on WarpBuild cloud only, so they have no bring-your-own-cloud equivalent.
A job selects its operating system on one line, so a matrix that fans a build across all four platforms is a list of labels:
name: cross-platform-ci
on:
pull_request:
push:
branches: [main]
jobs:
build:
strategy:
fail-fast: false
matrix:
include:
- platform: linux-x64
runner: warp-ubuntu-latest-x64-4x
- platform: linux-arm64
runner: warp-ubuntu-latest-arm64-4x
- platform: macos
runner: warp-macos-15-arm64-6x
- platform: windows
runner: warp-windows-latest-x64-4x
runs-on: ${{ matrix.runner }}
steps:
- uses: actions/checkout@v4
- uses: actions/setup-go@v5
with:
go-version: "1.24"
cache: true
- name: Record the platform
run: |
go version
go env GOOS GOARCH
- name: Build
run: go build -o dist/ ./cmd/...
- name: Test
run: go test ./...
- uses: actions/upload-artifact@v4
with:
name: dist-${{ matrix.platform }}
path: dist/go env GOOS GOARCH prints linux amd64, linux arm64, darwin arm64, and windows amd64 on the four legs, which is worth keeping in the log while you are adding or moving labels. fail-fast: false keeps the other three legs running when one platform breaks.
Detail
Linux x64 carries the widest image set
Three Ubuntu releases and five sizes each give 15 labels. The warp-ubuntu-latest-x64-<size> labels resolve to Ubuntu 24.04 and carry warp-ubuntu-2404-x64-<size> aliases, so a workflow that wants a release pinned across a rollout should name the versioned label. Ubuntu 26.04 uses warp-ubuntu-2604-x64-<size> and Ubuntu 22.04 uses warp-ubuntu-2204-x64-<size>.
Every size carries 150GB of SSD storage, 4GB of memory per vCPU, and the same tooling that GitHub-hosted images install (cloud runners documentation). Storage is ephemeral and is deleted when the runner terminates, so anything you want to keep goes to an artifact, a cache, or a registry.
Two capabilities live on this platform and nowhere else in the cloud catalog. Nested virtualization and /dev/kvm access, which Android emulator jobs need, are enabled with the nested-virtualization.enabled=true dynamic label on x86-64 Linux. Cache is enabled by default on Linux runners. The full label list with per-size rates is on the Linux x64 runner catalog.
Linux ARM64 covers two Ubuntu releases
Ubuntu 24.04 and Ubuntu 26.04, five sizes each, ten labels. The warp-ubuntu-latest-arm64-<size> labels resolve to Ubuntu 24.04 with warp-ubuntu-2404-arm64-<size> aliases, and Ubuntu 26.04 uses warp-ubuntu-2604-arm64-<size>.
Two documented differences account for most first-run failures on this platform. The arm64 images for Ubuntu 24.04 set the work dir to /runner/_work, which differs from GitHub's /home/runner/work/ for the same instance, so any step with a hardcoded path breaks. Use ${{ github.workspace }} in YAML and $GITHUB_WORKSPACE in shell steps. Workloads that require nested virtualization stay on the x86-64 line (cloud runners documentation).
The Ubuntu 24.04 ARM64 images are compatible with GitHub's Ubuntu 24.04 ARM64 runners, and the package list is published at actions/partner-runner-images. Read it before you assume a language version is present, because ARM64 images and x86-64 images do not always ship the same set. The Linux ARM64 runner catalog has the labels and the rates.
macOS runs on ARM64 with three images
macOS 14, macOS 15, and macOS 26, in 6 vCPU and 12 vCPU sizes, five labels in total. The warp-macos-latest-arm64-<size> aliases resolve to macOS 15, in sync with GitHub's own macos-latest tag, so an iOS job that must stay on one image should name warp-macos-15-arm64-6x or warp-macos-26-arm64-6x directly.
The macOS 26 labels ship Xcode 27.0 (build 27A5194q) on top of the Xcode versions in the upstream GitHub macOS 26 image, with the iOS 27.0, tvOS 27.0, watchOS 27.0, and visionOS 27.0 simulator runtimes. That addition exists while GitHub's upstream macOS 27 runner image is in beta, and a dedicated macOS 27 image follows once that image is released (cloud runners documentation). Plan a re-pin of your DEVELOPER_DIR path at that switch.
Two limits shape how a macOS job fits into a pipeline. macOS runners do not support nested virtualization and cannot run Docker, so a workflow that builds an iOS app and then packages a container image needs two jobs on two platforms. High concurrency on the macOS fleet is arranged with support rather than assumed from the Linux and Windows behavior. Move the container half of the pipeline to a Linux runner or a remote Docker builder while the macOS runner keeps the Xcode, Swift, and simulator work.
Windows covers two Server releases
Windows Server 2022 sits behind warp-windows-latest-x64-<size> with warp-windows-2022-x64-<size> aliases, and Windows Server 2025 uses warp-windows-2025-x64-<size>. Sizes run from 4 vCPU to 32 vCPU, each with 256GB of SSD storage and 4GB of memory per vCPU.
A third label family exists on the same Windows Server 2025 base image. The warp-windows-2025-vs2026-x64-<size> labels carry Visual Studio 2026 while the other Windows Server 2025 labels carry Visual Studio 2022. Those labels are transitional and track GitHub's own rollout of the Windows Server 2025 with Visual Studio 2026 image, so a .NET job that needs the new toolchain names a vs2026 label today and can move back to the plain 2025 label once Visual Studio 2026 becomes the default.
Windows images carry the same tooling as GitHub-hosted Windows runners and the same ephemeral storage rule. Cache is a Linux feature and is not available on Windows runners. The Windows runner catalog lists every label and rate.
The removals and deprecations that change a label
Three dated changes retire labels that older workflow files still name. All three come from the cloud runners documentation, checked on 2026-08-13.
| Change | Platform | Date | What the workflow does instead |
|---|---|---|---|
| arm64 images for ubuntu-22.04 deprecated | Linux ARM64 | March 31, 2025 | Move to warp-ubuntu-latest-arm64-<size> on Ubuntu 24.04 or warp-ubuntu-2604-arm64-<size> on Ubuntu 26.04 |
| macOS 13 runners removed | macOS | June 8, 2026 | Move to a macOS 14, macOS 15, or macOS 26 label |
| Windows 2 vCPU runners removed | Windows | June 8, 2026 | Use a 4 vCPU or larger Windows label |
Ubuntu 22.04 stays available on the x64 side, so the first row is an architecture change rather than a release change. Cloud spot runner labels were also removed on June 8, 2026, and spot capacity now comes from bring-your-own-cloud runners on AWS, GCP, and Azure.
Which operating system a given job wants
Platform choice usually follows the toolchain rather than preference.
Container image builds, most language test suites, and anything that needs /dev/kvm belong on Linux x64. Builds that ship aarch64 binaries or linux/arm64 container layers belong on Linux ARM64, where the compiler emits native instructions and the test binary you assert against is the binary you ship. Xcode builds, Swift packages, and simulator tests belong on macOS, which is the only platform that can run them. MSBuild, .NET Framework targets, and Windows-native installers belong on Windows.
Mixed pipelines split by job rather than by workflow. One repository can run its unit tests on warp-ubuntu-latest-x64-8x, its aarch64 integration tests on warp-ubuntu-latest-arm64-8x, its iOS build on warp-macos-15-arm64-6x, and its desktop installer on warp-windows-2025-x64-8x, in one file, with each job priced at its own per-minute rate.
Operating system coverage on your own cloud
Bring-your-own-cloud runners run inside your AWS, GCP, or Azure account and cover a subset of the same images. Linux x64 carries Ubuntu 22.04, 24.04, and 26.04 on all three clouds, and Linux ARM64 carries Ubuntu 24.04 and 26.04 on all three. Windows runners are available on AWS and Azure. macOS has no bring-your-own-cloud form and runs on WarpBuild cloud only (feature matrix, checked on 2026-08-13).
The billing shape differs from the cloud runners above. Bring-your-own-cloud runners carry a $0.002 per minute WarpBuild fee and the compute itself is billed by your own cloud account, which is where custom VM images, static IPs, and spot capacity come from. Both models are on the pricing page.
Related Questions
Which Linux distributions can a GitHub Actions runner use?
On x64 the images are Ubuntu 22.04, Ubuntu 24.04, and Ubuntu 26.04, five sizes each from 2 vCPU to 32 vCPU. On ARM64 the images are Ubuntu 24.04 and Ubuntu 26.04, also five sizes each. The latest labels resolve to Ubuntu 24.04 on both architectures. Labels and rates are on the Linux x64 runner catalog.
Which Windows versions can GitHub Actions runners use?
Windows Server 2022 and Windows Server 2025, both on x86-64, in sizes from 4 vCPU to 32 vCPU. A transitional set of Windows Server 2025 labels carries Visual Studio 2026 while the other 2025 labels carry Visual Studio 2022. Windows 2 vCPU runners were removed on June 8, 2026. The Windows runner catalog lists every label.
Which macOS versions can GitHub Actions runners use?
macOS 14, macOS 15, and macOS 26, all on ARM64, in 6 vCPU and 12 vCPU sizes. macOS 13 runners were removed on June 8, 2026, so a workflow still pinned to that image has to move to one of the three that remain. Image contents and Xcode versions are on the macOS runner catalog.
Is Ubuntu 22.04 available on ARM64 runners?
No. The arm64 images for ubuntu-22.04 were deprecated on March 31, 2025. Ubuntu 22.04 remains available on x64 labels, and ARM64 jobs run on the Ubuntu 24.04 or Ubuntu 26.04 ARM64 labels documented on the Linux ARM64 runner catalog.
Pick the label for the platform each job needs from the four catalogs above, check the image caveats in the cloud runners documentation, and price the matrix against your own job minutes on the pricing page.
Start with $10 in free credits
Change the runner label in your workflow and keep the rest of your GitHub Actions setup. Runner time is billed per minute.