GitHub Actions Runner Images in 2026: The Complete Selection Guide

Three runner image migrations converge in June 2026: Windows moves to Visual Studio 2026, macOS jumps from 15 to 26, and GitHub takes full ownership of all ARM64 images. If you manage CI workflows for anything beyond a hobby project, the next three weeks require decisions. This guide covers every current image label, the migration timelines, and the specific scenarios where standard images stop being enough.

The current runner image landscape

Before diving into what's changing, here's where things stand today. GitHub-hosted runners come in three OS families across two architectures, plus a lightweight container option.

For public repositories, standard runners get 4 vCPUs and 16 GB RAM on Linux and Windows x64. Private repos get half that: 2 vCPUs, 8 GB. All images share 14 GB of SSD storage. The macOS ARM64 runners (M1) are an outlier with 3 cores and 7 GB RAM regardless of repo visibility, while macOS Intel gets 4 cores and 14 GB.

The pricing spread matters for image selection. Linux x64 costs $0.006/min, Linux ARM64 is $0.005/min (17% cheaper), Windows x64 and ARM64 are both $0.010/min, and macOS is $0.062/min. That macOS premium is 10x Linux. If your workflow can run on Linux, that's the single biggest cost lever you have.

Ubuntu 24.04 vs. 22.04: when to stay and when to move

The ubuntu-latest label already points to Ubuntu 24.04, and has for a while now. No migration is pending here. But the decision between ubuntu-24.04 and ubuntu-22.04 still comes up constantly.

Stay on 22.04 if your build depends on libraries or system packages that haven't been ported to the 24.04 package set yet. The glibc bump from 2.35 to 2.39 can break older compiled binaries, and some PPAs haven't published 24.04 (Noble) packages. If you're building .deb packages targeting 22.04 servers, building on 22.04 avoids accidental dependency on newer system libraries.

Move to 24.04 if you don't have a specific blocker. The 24.04 image ships newer toolchains by default (GCC 14, Python 3.12, Node 20), which means fewer setup-action steps and faster job starts. Ubuntu 22.04's standard support runs through April 2027, but GitHub could deprecate the runner image before that.

There's also ubuntu-slim now: a single-CPU, 5 GB container runner at $0.002/min. It can't run Docker-in-Docker or anything needing elevated privileges, but for lightweight automation like issue triage, label syncing, or notification dispatching, it's 70% cheaper than the standard Linux runner. The 15-minute job timeout is the hard constraint.

Windows: the VS 2026 migration you need to plan for

This is the migration most likely to break things. Starting June 8, 2026, the windows-latest and windows-2025 labels will gradually roll over to a Visual Studio 2026 image. The rollout completes by June 15.

GitHub says no packages are being added or removed, but a Visual Studio version bump touches MSBuild, the MSVC compiler toolchain, .NET SDK versions, and Windows SDK headers. If you're building C++ projects with specific MSVC version expectations, or your MSBuild scripts depend on VS 2022 directory paths, test now.

Your options:

• Test early: Switch a non-critical workflow to windows-2025-vs2026 right now. This test label exists specifically for validation and will point to the regular windows-2025 image after the migration completes.
• Pin to VS 2022: If you need more time, change your runs-on to windows-2022. This buys time but puts you on a path toward an older, eventually-deprecated image.
• Do nothing: If your Windows builds are .NET-only or don't depend on specific MSVC compiler versions, the transition will likely be transparent.

One thing to watch: the Windows 11 ARM runner (windows-11-arm) doesn't yet have VS 2026 installed. That's being tracked in the runner-images repo. If you're doing Windows ARM builds that need VS 2026 tooling, you'll need to wait or install it yourself in the workflow.

macOS: from 15 to 26, and why pinning matters

Starting June 15, 2026, macos-latest will begin pointing to macOS 26 instead of macOS 15. The rollout takes 30 days, so you'll see a mix during that window. Some runs land on 15, others on 26.

This matters most for iOS and macOS app developers. A major macOS version bump means a new Xcode major version, updated Swift compiler, and potentially different simulator runtimes. If you ship to the App Store and your Xcode version is pinned in your project, a mismatch between the runner's default Xcode and your expected version will cause build failures.

The fix is straightforward: pin to macos-15 if you're not ready. You can also explicitly target macos-26 to start validating early. Both Intel and ARM64 variants are available for each version.

The label map for macOS is worth knowing:

• macos-latest, macos-14, macos-15, macos-26 all run on ARM64 (M1, 3 cores, 7 GB RAM)
• macos-15-intel and macos-26-intel run on Intel (4 cores, 14 GB RAM)

The Intel runners exist for compatibility with x86-only dependencies and for the static UDID requirement (Apple doesn't support static UDIDs on virtualized ARM). If neither applies to you, ARM64 is the default and has been since macOS 14.

ARM64: GitHub takes full ownership

Until May 2026, the ARM64 runner images for Linux and Windows were maintained by Arm Limited under the actions/partner-runner-images repository. That's changing. GitHub now owns all ARM64 images, and the partner repo will be archived.

The windows-11-arm image has already transitioned. ubuntu-24.04-arm and ubuntu-22.04-arm are mid-migration. During the transition period (estimated completion June 12), the Ubuntu ARM images won't receive updates or release notes. That's a known gap, not a crisis. Image functionality and compatibility stay the same.

The practical upside of this transition is consolidation. All issues, bug reports, and feature requests now go to actions/runner-images instead of the partner repo. And over time, GitHub-owned images should reach better parity with x64 images on preinstalled toolchains. Right now there are still gaps: for example, Node.js LTS versions aren't cached on ARM runners the way they are on x64, which means actions/setup-node downloads the binary on every run instead of using a local cache.

When ARM64 makes sense over x64

The cost argument for ARM64 Linux is simple: $0.005/min vs. $0.006/min per core at the standard tier, and the gap widens at larger runner sizes. A 4-core ARM runner costs $0.008/min vs. $0.012/min for x64. That's a 33% discount.

Beyond cost, ARM64 runners are the right pick when your deployment target is ARM. If you're shipping container images to AWS Graviton, Azure Cobalt, or any ARM-based Kubernetes fleet, building natively on ARM avoids cross-compilation complexity and QEMU emulation overhead.

The catch is ecosystem maturity. Some third-party Actions still don't support ARM64 and need manual workarounds. The preinstalled tool set is thinner. These are solvable problems, but they add friction if your toolchain is complex.

The decision tree: which image label to use

Here's how to think about it for new workflows or when revisiting existing ones after the June migrations:

1. Does it need to run on a specific OS? iOS/macOS builds require macOS. MSBuild and .NET Framework (not .NET Core) require Windows. Everything else can probably run on Linux.
2. Is your deployment target ARM? Use ARM64 runners. The cost is lower and you avoid cross-compilation.
3. Is it a lightweight automation job? Consider ubuntu-slim at $0.002/min. It won't work for Docker builds or anything needing privileged operations.
4. Do you need reproducibility across migration windows? Pin to explicit version labels (ubuntu-24.04, windows-2022, macos-15) instead of -latest. You lose automatic upgrades but gain predictability.
5. Is cost the primary constraint? Linux ARM64 is cheapest. Linux x64 is next. Windows is nearly 2x Linux. macOS is 10x. If you're on macOS just for cross-platform testing, consider whether you can move those tests to a separate, less frequent workflow.

When standard images aren't enough

Standard runner images cover a wide range of workflows. But there are three recurring scenarios where they create real pain:

Build time dominated by dependency installation. If your workflow spends 6 minutes installing system packages, compiling native extensions, or pulling large container images before your actual build even starts, you're paying for setup on every single run. Caching helps, but cache restoration adds its own overhead, caches expire, and some dependencies (system-level packages, custom certificates, proprietary SDKs) can't be cached through the standard GitHub Actions cache.

Compliance requirements. Regulated industries often require specific OS hardening, approved package versions, or audit-ready configurations. Standard GitHub images are updated weekly with whatever GitHub decides to include. You can't control when a package version bumps, and you can't guarantee that the exact same image content will persist across runs separated by days.

Proprietary tooling. Licensed compilers, EDA tools, hardware emulators, or internal SDKs that can't be distributed through public package managers. Installing these at workflow runtime means storing credentials, downloading large binaries, and handling license validation. All of that is slower, more fragile, and harder to secure than having the tools baked in.

Custom images: GitHub's GA feature and Tenki's approach

GitHub made custom images for hosted runners generally available in March 2026. You start with a GitHub-curated base image, layer on your own tools and dependencies, and your runners boot with everything pre-baked. No setup steps, no cache warming, no runtime installation.

The trade-off is operational overhead. You need to define, build, version, and maintain these images yourself. Custom images are only available with larger runners (Team or Enterprise Cloud plans), and image storage is billed separately. For teams that already manage AMIs or Packer builds for other infrastructure, it's a natural extension. For teams that don't want another artifact to maintain, it's added complexity.

This is where Tenki's managed runners fit in. Tenki plugs directly into your existing GitHub Actions setup and offers runners at $0.015/min/core, with benchmarks showing 30-50% faster builds compared to standard GitHub-hosted runners depending on the workload. The speed advantage comes from higher-performance compute and optimized environments, which means less time spent waiting for builds even before you get into custom image territory.

If your bottleneck is compute performance rather than image content, swapping to faster runners is a simpler fix than building and maintaining custom images. If your bottleneck is image content (proprietary tools, compliance baselines), custom images are the right call regardless of your runner provider.

Action items for June 2026

If you're reading this before June 15, you still have time to prepare. Here's the short list:

1. Audit your runs-on labels. Search your org's workflow files for windows-latest and macos-latest. Decide per-workflow whether to pin or ride the migration.
2. Test Windows builds against VS 2026. Use windows-2025-vs2026 in a branch. Fix issues now rather than after June 8 when it starts rolling out to production.
3. Evaluate ARM64 for Linux workloads. With GitHub owning the images now, the parity gap should close faster. If your stack is ARM-compatible, the 33% cost savings at the 4-core tier are hard to ignore.
4. Measure your setup overhead. If dependency installation accounts for more than 30% of your total job time, that's a signal to investigate custom images or faster runners.

The runner image landscape is more fragmented than it's ever been: three OS families, two architectures, multiple version labels, and now custom images as a first-class option. That's a lot of choices. But for most teams, the decision reduces to a few variables: what OS you actually need, whether ARM64 fits your deployment target, and whether your build time is dominated by compute or by setup. Get those three answers right and the rest follows.