GitHub Actions macOS 13 (Ventura) Runner Image Retirement October — when and how should I migrate?

As of 2026-03-18, the GitHub Actions macos-13, macos-13-large, and macos-13-xlarge runner images have been fully retired since December 4, 2025. Workflows still pinned to any macos-13 label fail immediately. Teams must choose a replacement runner: ARM64 runners (macos-14, macos-15) are the long-term direction but can silently break x86-dependent build steps, while macos-15-intel preserves x86_64 continuity but is itself scheduled for retirement in August 2027.

macos-15-intel now, unless you've verified every dependency and action is ARM64-safe; use self-hosted only when x86_64 needs extend past August 2027.

Blockers

Who this is for

Candidates

ARM64 Runner (macos-14 or macos-15)

The macos-14 (Sonoma) and macos-15 (Sequoia) GitHub-hosted runners run on Apple Silicon M1 (ARM64) with 3 vCPU and 7 GB RAM. As of 2026-03-18, the macos-latest label resolves to macOS 15 (ARM64) following the migration completed September 2025. These are GitHub's long-term strategic path with no announced retirement. The critical differentiator is that switching to ARM64 can silently break workflows that compile, link, or test x86_64-specific binaries.

When to choose

Best for low-ops + small-team workflows where all build steps are architecture-agnostic: pure Swift, Objective-C, or cross-platform scripting that does not produce or test x86_64 binaries. The single most decisive factor is verifying that every Homebrew formula, native dependency, and third-party GitHub Action in the workflow has an arm64 build before switching.

Tradeoffs

Pros: GitHub's long-term supported path with no planned EOL, macos-latest convenience label works out of the box, generally faster cold-start, consistent with Apple's silicon direction. Cons: 3 vCPU and 7 GB RAM vs 4 vCPU and 14 GB RAM on Intel runners; ARM64 ABI breaks workflows that link against x86-only libraries or produce x86 binaries for distribution; some older GitHub Marketplace actions bundle x86 native binaries and fail silently on ARM64.

Cautions

Rosetta 2 is not pre-installed on GitHub-hosted ARM runners; x86 binary execution will fail unless you explicitly run softwareupdate --install-rosetta --agree-to-license as a workflow step. ARM incompatibilities in third-party actions often surface at runtime rather than during step setup, making them difficult to catch without a full end-to-end test run on the new label.

Sources

Intel Runner (macos-15-intel)

The macos-15-intel runner runs macOS 15 (Sequoia) on x86_64 Intel hardware with 4 vCPU and 14 GB RAM, providing a direct architecture-compatible replacement for macos-13 workflows. As of 2026-03-18, this is the only GitHub-hosted x86_64 macOS runner available. GitHub has confirmed it will be retired in August 2027, after which no x86_64 macOS runner will be offered on GitHub-hosted infrastructure.

When to choose

Best for enterprise + cost-sensitive teams whose workflows must produce or test x86_64 binaries, link against x86-only native libraries, or cannot absorb the risk of ARM compatibility regressions in the current delivery window. The single most decisive factor is whether your build output is required to be x86_64 native — if so, this is the only GitHub-hosted option available as of 2026-03-18.

Tradeoffs

Pros: direct x86_64 architecture continuity from macos-13 with no compatibility work required for existing x86 toolchains; more CPU and RAM than ARM runners (4 vCPU / 14 GB vs 3 vCPU / 7 GB); immediate fix for broken macos-13 workflows. Cons: explicitly GitHub's last x86_64 macOS image, retired August 2027, requiring a second migration within roughly 18 months; Intel runners may face longer queue times as GitHub deprioritizes the architecture.

Cautions

Using macos-15-intel without a parallel ARM64 migration plan creates a hard deadline in August 2027 with no GitHub-hosted fallback option. The macOS version jump from 13 to 15 may still cause subtle breakage in Xcode toolchain versions, default Homebrew formula versions, or pre-installed software regardless of the architecture match.

Sources

Self-Hosted macOS Runner

Self-hosted runners let teams register any macOS machine — physical, virtual, on-premises, or cloud — as a GitHub Actions executor, retaining full control over hardware architecture, OS version, and installed tooling. This eliminates all GitHub-imposed architecture and OS retirement timelines. The decisive differentiator is that it shifts full operational burden (provisioning, patching, scaling, security) to the team.

When to choose

Best for enterprise + compliance teams with hard x86_64 requirements extending beyond August 2027, teams needing Xcode versions or hardware configurations unavailable on GitHub-hosted runners, or teams that need macOS runner capacity beyond what GitHub-hosted pools provide. Use only when the operational cost of runner fleet management is explicitly budgeted.

Tradeoffs

Pros: full control over hardware architecture and macOS version, no GitHub-imposed retirement dates, can maintain x86_64 macOS indefinitely, enables hardware-in-the-loop or notarization-specific configurations. Cons: team owns all provisioning, patching, and scaling; horizontal scaling requires manual effort or a third-party autoscaler; security patching and runner software updates are the team's responsibility.

Cautions

Apple's macOS EULA restricts running macOS on non-Apple hardware; virtualizing macOS on non-Apple hosts violates the license. Self-hosted runners attached to public repositories carry significant security risk because pull requests from forks can execute arbitrary code on your runner machine — restrict to private repositories or use ephemeral runner configurations.

Sources

Facts updated: 2026-03-18
Published: 2026-04-03

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "GitHub Actions macOS 13 (Ventura) Runner Image Retirement October — when and how should I migrate?"
Missing something? Request coverage