How Much Disk Do macOS Runners Have?

A WarpBuild macOS runner carries a 120GB SSD on the 6 vCPU labels and a 270GB SSD on the 12 vCPU labels, and the figure comes from the runner row you name in runs-on (cloud runners documentation, checked on 2026-08-13). That volume is ephemeral: it is deleted when the runner is terminated, so anything the job needs to keep goes to an artifact, a cache, or a registry before the job ends.

Answer

Five macOS labels ship in the catalog, and storage moves with the size rather than with the macOS release.

Every row comes from the cloud runners documentation, checked on 2026-08-13. macOS 13 labels were removed on June 8, 2026, so a workflow that still names one queues without a match.

Volume size and free space at step one are two different numbers. The image is built from the matching upstream GitHub runner image and carries the same preinstalled tooling (preinstalled software documentation), which means Xcode, the bundled simulator runtimes, and the rest of the toolchain already occupy part of the disk when step one starts. On the macOS 26 labels that set includes Xcode 27.0 (build 27A5194q) with the iOS, tvOS, watchOS, and visionOS 27.0 simulator runtimes, a WarpBuild addition on top of the upstream GitHub macOS 26 image while GitHub's upstream macOS 27 image is in beta (macOS 26 tooling). A dedicated macOS 27 image follows once that upstream image is released.

For a baseline, GitHub documents 14 GB of SSD storage on its hosted macOS runners, standard and larger alike (GitHub-hosted runners reference, checked on 2026-08-13). A job that fits in 14 GB has room to spare at 120GB, and a job that spends steps deleting simulator runtimes to survive may stop needing those steps at all.

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, and macOS pricing is flat per minute by size: $0.08 for the 6 vCPU labels and $0.16 for the 12 vCPU labels (pricing page, checked on 2026-08-13).

Detail

What consumes the disk in an Xcode job

Four things account for nearly every macOS runner disk failure, and they are worth knowing by path because that is what a cleanup step needs.

Delete in this order when a job runs tight:

1. Unused simulator runtimes and unused Xcode bundles. These are the largest single items on the image and your job rebuilds none of them, so removing them costs nothing beyond the delete. Pin DEVELOPER_DIR before you do it so a later step cannot reach for a bundle you removed.
2. DerivedData intermediates, once the archive is written. Intermediates.noindex, ModuleCache.noindex, and Index.noindex are rebuild artifacts; the Build/Products directory is what your test and export steps still read.
3. The .xcarchive, once the IPA is exported and the dSYMs are uploaded. Keep the export, drop the archive.
4. Package checkouts, last. They are the cheapest to lose in disk terms and the most expensive to lose in time, since dropping them means a fresh resolve on the next step that needs them.

macOS runners do not support nested virtualization and cannot run Docker (cloud runners documentation), so container images are never part of the macOS disk budget. Container builds belong on remote Docker builders, which sit alongside snapshot runners, CI observability, an MCP server, and the Action Debugger in the product surface around the runner.

Measure your own headroom

Guessing at disk pressure wastes more time than measuring it. Print free space around the archive step and the log tells you exactly how much room the job had.

name: ios-archive

on:
  workflow_dispatch:

jobs:
  archive:
    runs-on: warp-macos-26-arm64-12x
    steps:
      - uses: actions/checkout@v4

      - name: Disk before archive
        run: df -h /System/Volumes/Data

      - name: Archive
        run: |
          xcodebuild archive \
            -workspace App.xcworkspace \
            -scheme App \
            -configuration Release \
            -destination 'generic/platform=iOS' \
            -derivedDataPath DerivedData \
            -clonedSourcePackagesDirPath SourcePackages \
            -archivePath build/App.xcarchive

      - name: Disk after archive
        run: |
          df -h /System/Volumes/Data
          du -sh DerivedData SourcePackages build

      - name: Reclaim space before the export
        run: |
          rm -rf DerivedData/Build/Intermediates.noindex
          rm -rf DerivedData/Index.noindex
          xcrun simctl delete unavailable

      - uses: actions/upload-artifact@v4
        with:
          name: app-archive
          path: build/App.xcarchive

Read df -h /System/Volumes/Data rather than df -h /. On macOS the root filesystem is the read-only system volume, and the writable data volume is where the checkout, DerivedData, and every download live. The du -sh line names the three directories the numbers usually point at, so one run tells you whether DerivedData or the packages are the growth term in your repository.

Sizing the disk against the bill

The 12 vCPU labels double the disk and double the rate: 270GB at $0.16 per minute against 120GB at $0.08 per minute (pricing page, checked on 2026-08-13). Per vCPU-minute the two sizes cost the same, so the size choice is a throughput and headroom decision rather than a discount decision.

A worked case: a release job that runs 20 minutes costs 20 x $0.08 = $1.60 on the 6 vCPU label and 20 x $0.16 = $3.20 on the 12 vCPU label. If the tight disk forces three cleanup steps that add four minutes, the 6 vCPU job is 24 minutes at $1.92, and the wider label buys both the space and the shorter wall clock for $1.28 more. Run the measurement workflow above on both labels before you decide, because the delta lands differently on a test job that runs on every push than on an archive that runs once per merge.

Related Questions

How much disk does a WarpBuild macOS runner have?

A 120GB SSD on the 6 vCPU labels and a 270GB SSD on the 12 vCPU labels, with the exact row per label on the macOS runner hub and the full shape breakdown on the macOS runner sizes page. Runner storage is ephemeral and is deleted when the runner is terminated.

Why does df report less free space than the catalog figure?

The image ships Xcode, the bundled simulator runtimes, and the rest of the preinstalled toolchain before your job starts, and those files sit on the same volume (preinstalled software documentation). Print df -h /System/Volumes/Data as the first step to record the real starting headroom.

What should I delete first when an Xcode job runs out of disk?

Unused simulator runtimes and unused Xcode bundles first, then DerivedData intermediates once the archive is written, then the .xcarchive after the IPA is exported, then the resolved package checkouts. The step-by-step cleanup workflow is in the macOS runner disk space guide, and the cross-platform picture is in which GitHub Actions runners carry large disks.

Pick a label on the macOS runner hub, check the disk against your own df output, and price the minutes on the pricing page.