macOS Runners for GitHub Actions: Sizes and Pricing

WarpBuild runs macOS runners for GitHub Actions on Apple Silicon in two sizes: 6 vCPU with 22GB of memory and a 120GB SSD at $0.08 per minute, and 12 vCPU with 44GB of memory and a 270GB SSD at $0.16 per minute. Five labels cover macOS 26, macOS 15, and macOS 14, and a job moves onto them by changing one runs-on value.

This page is the catalog and price reference for those labels: every label with its specifications, the per-minute rates set against GitHub's published macOS list prices, and the workflow configuration that puts an Xcode job on them. Rates and specifications here are taken from the WarpBuild cloud runners documentation and re-checked on 2026-08-13.

Catalog

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners. The macOS fleet is Apple Silicon on ARM64, and it registers five labels against your GitHub organization.

The label grammar is warp-macos-<os version>-arm64-<size>x. The OS segment is the macOS major version or the word latest, the architecture segment is always arm64 on macOS, and the size segment is the vCPU count. Read a label left to right and you know the image and the machine without opening the runner page.

Size and configuration matrix per chip

WarpBuild offers multiple sizes and configurations per chip. Two configurations exist on macOS, and they scale memory and disk with the core count rather than holding either fixed:

The 12x configuration doubles the cores, doubles the memory to 44GB, and takes disk from 120GB to 270GB. Disk is the specification that decides most macOS build failures: a derived data directory, a resolved Swift package checkout, several simulator runtimes, and an archive of a large app add up quickly, and a runner that fills its disk halfway through xcodebuild fails in a way that reads like a compiler problem. If a job currently spends steps deleting simulator runtimes or clearing derived data to stay under a disk ceiling, the 12x size removes the reason for those steps.

macOS 14 carries the 6x size only. Every other macOS image carries both.

Image and Xcode coverage

The warp-macos-26-arm64-6x and warp-macos-26-arm64-12x runners ship Xcode 27.0 (build 27A5194q) in addition to the Xcode versions present in the upstream GitHub macOS 26 image, while GitHub's upstream macOS 27 runner image is in beta. Xcode 27.0 arrives with its simulator runtimes bundled:

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 per-image Xcode list and the simulator runtimes on macOS 15 and macOS 14, see Xcode versions and simulator runtimes on WarpBuild macOS images.

Outside that addition, the images track upstream. The tooling installed on WarpBuild macOS runners matches the GitHub-hosted equivalents, image by image, which is what makes the label swap a one-line change; the preinstalled software reference links the upstream readme for each macOS image so you can diff a tool version before you migrate.

macOS 13 runners were removed on June 8, 2026. Workflows still referencing a macOS 13 label need to move to macOS 14, macOS 15, or macOS 26.

What macOS runners do not carry

Three constraints are worth knowing before you plan a pipeline around these machines.

macOS runners do not support nested virtualization and cannot run Docker. Container builds belong on Linux runners or on remote Docker builders, so a repository that produces both an iOS app and a service image ends up with two jobs on two runner families rather than one job doing both.

Snapshot runners and the WarpBuild cache are Linux runner features. On macOS, keep dependency caching on actions/cache with a key derived from Package.resolved or your Podfile.lock.

High concurrency on macOS is a capacity conversation. Run as many jobs as your workflows need. Generally available Linux and Windows runners do not have plan-level concurrency caps. That said, macOS capacity is planned rather than elastic in the way Linux capacity is, so a team that needs a large number of simultaneous macOS jobs should raise it with support before the release week that depends on it.

Every runner is an ephemeral virtual machine. It is allocated when a job starts, and it is destroyed when the job finishes, so nothing leaks from one build into the next.

Pricing

Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee. A macOS job bills runner minutes and nothing else.

Against GitHub-hosted macOS list prices

GitHub publishes its per-minute rates for private repositories on the Actions runner pricing reference and on the GitHub pricing page. The macOS rows below were checked on 2026-08-13.

The arithmetic, one comparison at a time.

Against macos-latest-xlarge, the closest GitHub-hosted Apple Silicon machine, WarpBuild's 6 vCPU runner is $0.08 per minute against $0.102: a difference of $0.022 per minute, or 22 percent lower list price. The WarpBuild machine also carries 6 vCPU against 5, 22GB of memory against 14GB, and a 120GB SSD against 14GB.

Normalize by core and the gap widens. WarpBuild's 6 vCPU runner is $0.08 divided by 6, or $0.0133 per vCPU-minute. The 12 vCPU runner is $0.16 divided by 12, which is the same $0.0133 per vCPU-minute, so the size choice is a throughput decision rather than a discount decision. macos-latest-xlarge is $0.102 divided by 5, or $0.0204 per vCPU-minute: WarpBuild is 35 percent lower on that basis. Standard macos-latest is $0.062 divided by 3, or $0.0207 per vCPU-minute, so WarpBuild is 35 percent lower there.

One row runs the other way, and it is worth stating plainly. macos-latest-large is $0.077 for 12 Intel cores, which is $0.0064 per vCPU-minute, the lowest number in the table. It is an Intel machine, so it applies to workloads that target Intel rather than Apple Silicon.

A worked monthly model

Take an iOS team with 60 pull request builds on a weekday and a 14-minute build-and-test job.

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

Both figures assume the same wall-clock minutes on both machines, which is the conservative way to model it, because the WarpBuild runner brings one more core and 8GB more memory to the same job. To model your own repository against its real job durations, work through modeling the monthly cost of macOS runners for GitHub Actions.

Signup includes $10 free credits, which buys 125 minutes on a 6 vCPU macOS runner or 62 minutes on a 12 vCPU macOS runner before a card is involved. That is enough to run the model above against your own workflow for a day and compare the bill rather than the brochure.

Two more line items to know. SSO is a flat $250 per month, whatever the user count, listed on the WarpBuild pricing page alongside the per-minute rates for every runner family. Cache storage, cache operations, and snapshot line items are Linux runner features and never appear on a macOS-only bill.

Configuration

Point runs-on at a WarpBuild macOS label and the rest of the workflow file stays where it is.

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

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

      - name: Pin the toolchain
        run: |
          sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
          xcodebuild -version

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

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

      - name: Build and test
        run: |
          xcodebuild test \
            -project App.xcodeproj \
            -scheme App \
            -destination 'platform=iOS Simulator,name=iPhone 17,OS=latest' \
            -resultBundlePath TestResults.xcresult

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

Alias behaviour of the latest labels

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 tracks macOS 15 in sync with GitHub's own macos-latest tag, so the two ecosystems point at the same major version and a repository that mixes hosted and WarpBuild jobs stays on one image family.

An alias follows the tag when the tag moves. That is convenient for a repository that wants the current image without editing YAML, and it is a hazard for a release pipeline that signs and notarizes against a fixed toolchain. Use the alias on pull request jobs where a moving image is acceptable, and pin the explicit version on release jobs:

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

Migrating an existing workflow

The migration from GitHub-hosted macOS runners is a label edit:

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

Nothing else in the job changes. The image carries the same tooling as the GitHub-hosted equivalent, sudo is passwordless, and the working directory layout matches, so the checkout step, the Xcode selection step, and the simulator destination string all behave the same way. Repository-level detail for Swift and iOS pipelines lives on iOS builds and tests on GitHub Actions and Swift package builds on GitHub Actions.

Testing several macOS versions in one workflow

A matrix over labels is the cheapest way to find out whether a new macOS image breaks a build before the alias moves under you:

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@v4
      - run: sw_vers
      - run: xcodebuild -version
      - run: swift build -c release
      - run: swift test

Run that weekly on a schedule and a macOS 26 regression shows up on a cron job instead of on the morning you planned to ship.

Picking a size

Start on 6x. Move a job to 12x when one of three things is true: the job is disk bound at 120GB, the job is memory bound at 22GB, or the job parallelizes cleanly across cores, which xcodebuild test plans and swift test both do. Because both sizes cost the same $0.0133 per vCPU-minute, a job that genuinely uses 12 cores costs roughly the same on 12x as on 6x while finishing in less wall-clock time; a job that uses 4 cores costs twice as much on 12x for no benefit. Measure before you upgrade.

Tooling around the runner

CI observability reports OpenTelemetry system metrics from the runner agent next to the GitHub Actions job logs, which is how you tell a memory-bound Xcode job apart from a slow one. The Action Debugger opens an SSH session on a paused runner when a macOS-only failure will not reproduce locally.

FAQ

Which macOS runner labels does WarpBuild register for GitHub Actions?

Five labels. warp-macos-26-arm64-6x and warp-macos-26-arm64-12x on macOS 26, warp-macos-15-arm64-6x and warp-macos-15-arm64-12x on macOS 15, and warp-macos-14-arm64-6x on macOS 14. The macOS 15 labels also answer to the aliases warp-macos-latest-arm64-6x and warp-macos-latest-arm64-12x.

What do WarpBuild macOS runners cost against GitHub-hosted macOS runners?

The 6 vCPU runner is $0.08 per minute and the 12 vCPU runner is $0.16 per minute. GitHub lists its arm64 macOS 5-core larger runner at $0.102 per minute and its standard 3-core macOS runner at $0.062 per minute (GitHub Actions runner pricing, checked on 2026-08-13). At 6 vCPU for $0.08, WarpBuild works out to $0.0133 per vCPU-minute against $0.0204 for the GitHub arm64 larger runner.

What does warp-macos-latest-arm64-6x point to?

It is an alias for warp-macos-15-arm64-6x. The latest tag tracks macOS 15 in sync with GitHub's own macos-latest tag, so pin an explicit OS version such as warp-macos-26-arm64-12x when a job must stay on one image.

Can WarpBuild macOS runners run Docker?

No. macOS runners do not support nested virtualization and cannot run Docker. Send container builds to WarpBuild Linux runners or to remote Docker builders, and keep the macOS runner for Xcode, Swift, and simulator work.