Self-Hosted GitHub Actions macOS Runner Setup
·8 min read
GitHub's hosted macOS runners are convenient right up until you build a lot. Then two things start to hurt: cost (macOS minutes are billed at a premium) and cold starts (every run spins up a clean machine and re-downloads everything). Moving those builds to a self-hosted runner on a dedicated cloud Mac takes care of both. Here's how it works, and when it's actually worth the switch.
Hosted vs. self-hosted macOS runners
A hosted macOS runner spins up a fresh VM for every job. Great for isolation. Less great in three ways:
- You pay per minute, and macOS minutes carry a multiplier over Linux.
- Caches, simulators and toolchains are cold on every run unless you re-fetch them.
- You can't pin an exact Xcode/macOS combo for long without workarounds.
A self-hosted runner is a Mac you control that stays online between builds. Your dependencies, CocoaPods and SPM caches, and simulators all stick around, so a build starts the moment it's queued, and the bill is flat no matter how many jobs you throw at it.
When self-hosting pays off
- High build volume: many PRs, frequent merges, or matrix builds.
- Long builds: large iOS/macOS apps where cold caches hurt most.
- Cost ceilings: you want a predictable monthly number instead of variable minutes.
- Version control: you need to pin a specific Xcode and macOS version.
Building only now and then? Hosted runners are fine, stick with them. But the moment macOS minutes show up as a recurring line item on your bill, the math tips fast.
How to set it up on a cloud Mac
- Get a dedicated Mac. Rent a cloud Mac Mini M4 so you have a persistent, always-on machine with full-admin access.
- Install Xcode and your toolchain (Homebrew, fastlane, CocoaPods/SPM) once.
- In GitHub:
Settings → Actions → Runners → New self-hosted runner, choose macOS, and run the download/configure commands it gives you on your cloud Mac. - Point your workflow at it: set
runs-on: [self-hosted, macOS]in your job. - Run the runner as a service so it reconnects automatically and is always available.
From there, every build uses your warm machine. The same setup works for GitLab CI, Buildkite and other systems that support self-hosted macOS agents.
A note on security
Self-hosted runners execute workflow code on your machine, so avoid using them on untrusted public forks, keep the OS and runner agent updated, and isolate secrets. A dedicated machine (not a shared one) makes this much easier to reason about.
Bottom line
If your team ships iOS or macOS apps on any kind of cadence, a dedicated cloud Mac as a self-hosted runner buys you faster builds and a bill you can predict. See MacRent for CI/CD for a machine set up for exactly this, or rent a Mac if you just need one to work on.
Frequently asked questions
Can I use a self-hosted macOS runner with GitHub Actions?
Yes. GitHub Actions supports self-hosted runners on macOS. You install the runner agent on a Mac you control, register it to your repo or organization, and target it from your workflow with runs-on.
Is a self-hosted Mac runner cheaper than GitHub's hosted macOS runners?
For frequent builds, usually yes. Hosted macOS minutes are billed per minute and at a multiplier, so heavy usage adds up fast. A dedicated cloud Mac is a flat monthly cost you can saturate with unlimited builds.
What hardware do I need for a macOS CI runner?
A Mac with Apple Silicon is ideal for fast, native builds. A dedicated Mac Mini M4 with 16GB RAM and a fast SSD handles most iOS/macOS pipelines comfortably and keeps caches warm between runs.
Need a Mac without buying one?
Rent a dedicated Mac Mini M4 in the cloud from $15/day. Full-admin access, ready in minutes, cancel anytime.
Rent a Mac