macOS Runners for GitHub Actions: Sizes and Pricing

WarpBuild runs GitHub Actions macOS runners on Apple Silicon M4 Pro and M5 Pro hosts, and macOS concurrency limits can be raised through support. The 6 vCPU size has 14GB memory and a 120GB SSD at $0.08 per minute, and the 12 vCPU size has 28GB and a 270GB SSD at $0.16 per minute (cloud runners docs, pricing). Five labels cover macOS 26, 15 and 14.

Switch a job with one runs-on change.

Which macOS runner labels does WarpBuild offer?Copy Anchor Link

WarpBuild registers five macOS labels against your GitHub organization, on macOS 26, macOS 15 and macOS 14. All of them run on Apple Silicon with ARM64 architecture, with these specs and rates:

The label format is warp-macos-<os version>-arm64-<size>x. The OS part is the macOS major version or the word latest, the architecture part is always arm64 on macOS, and the size part is the vCPU count. macOS 14 has the 6x size only, and every other macOS image has both sizes.

What the two sizes give a jobCopy Anchor Link

The 12x size doubles the cores, doubles the memory to 28GB, and raises disk from 120GB to 270GB (cloud runners documentation). Derived data, resolved Swift packages, several simulator runtimes and an app archive add up quickly. For a size-by-workload guide, see macOS Runner Sizes and Configurations for GitHub Actions.

Which Apple Silicon chips run WarpBuild macOS runners?Copy Anchor Link

The hosts are Apple M4 Pro and M5 Pro machines with ARM64 architecture. These runners have the same tooling preinstalled as the GitHub-hosted macOS runners, so they work as drop-in replacements. The preinstalled software reference links the upstream readme for each macOS image, so you can compare a tool version before you migrate.

Xcode coverage on the macOS 26 imageCopy Anchor Link

The warp-macos-26-arm64-6x and warp-macos-26-arm64-12x runners ship Xcode 27.0 (build 27A266a) in addition to the Xcode versions in the upstream GitHub macOS 26 image. Xcode 27.0 comes with these simulator runtimes:

Xcode 27.0 is a WarpBuild addition on top of the upstream image and is maintained until the official macOS 27 images are released. For the full Xcode list and the simulator runtimes on macOS 15 and macOS 14, see Xcode Image Coverage on macOS GitHub Actions Runners.

macOS 13 runners were removed on June 8, 2026, so workflows that still use a macOS 13 label need to move to macOS 14, macOS 15 or macOS 26.

What macOS runners do not supportCopy Anchor Link

macOS runners do not support nested virtualization and cannot run Docker. Container builds belong on Linux runners or on remote Docker builders. A repository that builds both an iOS app and a service image needs two jobs on two runner types.

Snapshot runners are not supported on macOS. Keep dependency caching on actions/cache with a key built from Package.resolved or your Podfile.lock.

Every runner is an ephemeral virtual machine. It is allocated when a job starts and destroyed when the workflow is complete, so nothing carries over from one build to the next.

How much macOS concurrency can you get?Copy Anchor Link

macOS concurrency limits can be raised through support. If your workflows need more macOS jobs running at the same time, contact [email protected]. The fleet includes 200 M5 Pro Macs with more on the way.

What do WarpBuild macOS runners cost against GitHub-hosted macOS runners?Copy Anchor Link

WarpBuild pricing for macOS is $0.08 per minute for the 6 vCPU runner and $0.16 per minute for the 12 vCPU runner, and CI runners are billed per minute. GitHub lists its 5-core M2 Pro larger runner (macos-latest-xlarge) at $0.102 per minute. That makes the WarpBuild 6 vCPU runner 22% cheaper per minute than macos-latest-xlarge.

Here is how the numbers in the table are calculated:

• Against macos-latest-xlarge, the 6 vCPU runner is $0.022 less per minute and has 6 vCPU against 5. ($0.102 - $0.08) / $0.102 = 21.6%, which rounds to 22%.
• Per vCPU, $0.08 / 6 and $0.16 / 12 are both $0.0133 per vCPU-minute. The size choice changes speed, not the price per core.
• macos-latest-xlarge is $0.102 / 5 = $0.0204 per vCPU-minute, so WarpBuild is 35% lower per vCPU-minute.

Example monthly cost for an iOS teamCopy Anchor Link

This is an example with assumed numbers. An iOS team runs 60 pull request builds each weekday, and each build-and-test job takes 14 minutes.

1. 60 jobs x 14 minutes = 840 minutes per weekday.
2. 840 minutes x 21 working days = 17,640 macOS minutes per month.
3. On warp-macos-latest-arm64-6x, 17,640 x $0.08 = $1,411.20 per month.
4. On macos-latest-xlarge at GitHub's list rate, 17,640 x $0.102 = $1,799.28 per month.
5. The difference is $388.08 per month, or $4,656.96 over twelve months at the same volume.

The example uses the same job duration on both machines, so it does not count any time saved by the extra core. To use your own job durations, see What macOS Runners Cost on GitHub Actions.

How do you move a GitHub Actions macOS job to WarpBuild?Copy Anchor Link

Change runs-on to a WarpBuild macOS label. The rest of the workflow file stays the same.

name: ios-pull-request
on:
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: warp-macos-15-arm64-6x
    steps:
      - uses: actions/checkout@v7

      - name: Print the toolchain
        run: xcodebuild -version

      - name: Cache SwiftPM
        uses: actions/cache@v6
        with:
          path: ~/Library/Caches/org.swift.swiftpm
          key: spm-${{ hashFiles('**/Package.resolved') }}

      - name: Resolve packages
        run: xcodebuild -resolvePackageDependencies -project App.xcodeproj

      - name: Build for testing
        run: |
          xcodebuild build-for-testing \
            -project App.xcodeproj \
            -scheme App \
            -destination 'generic/platform=iOS Simulator' \
            -resultBundlePath TestResults.xcresult

      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: xcresult
          path: TestResults.xcresult

For an existing workflow on GitHub-hosted macOS runners, the migration is one line:

 jobs:
   build:
-    runs-on: macos-latest-xlarge
+    runs-on: warp-macos-latest-arm64-6x

The checkout, cache and xcodebuild steps keep working without changes. For pipeline details, see iOS Builds on GitHub Actions with macOS Runners and Swift Package Builds on GitHub Actions.

How the latest labels resolveCopy Anchor Link

warp-macos-latest-arm64-6x resolves to warp-macos-15-arm64-6x, and warp-macos-latest-arm64-12x resolves to warp-macos-15-arm64-12x. The latest tag points to macOS 15.

An alias moves when the tag moves, which suits pull request jobs that should use the current image. Release pipelines that sign and notarize against a fixed toolchain should pin an explicit version:

jobs:
  pr-checks:
    runs-on: warp-macos-latest-arm64-6x   # follows macOS 15 today

  release-build:
    runs-on: warp-macos-26-arm64-12x      # pinned, moves only when you edit this line

Testing several macOS versions in one workflowCopy Anchor Link

A matrix over labels shows whether a new macOS image breaks a build before the alias moves:

jobs:
  os-compatibility:
    strategy:
      fail-fast: false
      matrix:
        runner:
          - warp-macos-26-arm64-12x
          - warp-macos-15-arm64-12x
          - warp-macos-14-arm64-6x
    runs-on: ${{ matrix.runner }}
    steps:
      - uses: actions/checkout@v7
      - run: sw_vers
      - run: xcodebuild -version
      - run: swift build -c release
      - run: swift test

Run it weekly on a schedule, and a macOS 26 regression shows up in a scheduled run before your release day.

Picking a sizeCopy Anchor Link

Start on 6x. Move a job to 12x when the job runs out of disk at 120GB, runs out of memory at 14GB, or spreads its work across cores, as xcodebuild test plans and swift test do. Both sizes cost $0.0133 per vCPU-minute at the rates in the cloud runners documentation. A job that uses all 12 cores costs about the same on 12x as on 6x and finishes sooner. A job that uses 4 cores costs twice as much on 12x with no gain. Measure before you upgrade.

Debugging and metricsCopy Anchor Link

WarpBuild observability shows CPU, memory and disk usage for each runner instance, which helps you tell a memory-bound Xcode job from a slow one. It uses OpenTelemetry for data collection. Action-Debugger is a free, open-source GitHub action that pauses a workflow and lets you SSH into the running runner, which helps when a macOS-only failure does not reproduce locally.