GitHub Actions · your hardware

Self-hosted macOS GitHub Actions runners

Run Apple builds on the Macs you own, with a fresh Tart VM for every job.

Get started free →

Turn an Apple Silicon Mac into a macOS CI host

A Mac mini, Mac Studio or Apple Silicon Mac Pro can host GitHub Actions runners for Xcode, Swift, iOS and macOS builds. Baremetal uses Tart to clone a clean macOS VM, registers a single-job runner inside it, and removes the VM when that job finishes.

You retain control of the physical Mac and the image. Pin the Xcode version, simulator runtimes and other tools in the image so changes to a shared host do not silently change the build environment.

What you need

  • An Apple Silicon Mac with a macOS version supported by Tart; Intel Macs are not supported.
  • Homebrew, network access and enough storage for the base image and VM clones.
  • A Tart-compatible macOS image containing the tools your workflow requires.
  • A GitHub organization or repository you can administer.

Keep the Mac powered and awake. The Baremetal agent connects outbound to the control plane, so enrolling a host does not require opening an inbound port on your router. See Tart’s current requirements.

Configure a macOS runner pool

  1. Connect GitHub in your Baremetal workspace.
  2. Open Add machine and run the generated join command on the Mac.
  3. Create a macOS pool with your Tart image, guest CPU and memory, and a custom label such as baremetal-macos.
  4. Set the host’s capacity and warm-runner target, then run a test workflow.
name: Check macOS toolchain
on: workflow_dispatch
permissions:
  contents: read
jobs:
  check:
    runs-on: [self-hosted, macOS, ARM64, baremetal-macos]
    steps:
      - run: sw_vers
      - run: xcodebuild -version
      - run: xcrun simctl list devices available

Use the labels configured on your pool. The image must contain Xcode and the simulator runtimes for the last two commands. Once this works, target the same pool from your project’s build and test workflow.

Plan memory, concurrency and startup time

Baremetal caps macOS hosts at two concurrent VMs. Available RAM, CPU and your configured host reserves can reduce that to one. Size each guest for your build and simulators, leaving resources for macOS on the host.

Warm runners reduce the wait for a VM to start but occupy resources while idle. Scaling idle runners down releases those resources; the next job may wait for a new guest. Measure both approaches with your actual Xcode project.

Handle signing, artifacts and caches explicitly

Each job gets a clean VM. Install signing credentials only when the workflow needs them, limit which workflows can access them, and export build artifacts before teardown. Files left only in the guest will not be available to the next job.

Use your chosen external cache or artifact service for data that should survive a job. VM isolation does not make an untrusted workflow safe to give signing credentials. Review the public repository guidance and security model before running outside contributions.

For Linux builds alongside your Apple builds, see GitHub Actions on bare metal.

Plan and troubleshoot your runners

Read the setup guide →Connect your first machine →