For iOS and cross-platform teams on GitHub Actions

Your agents open the PRs.Your Macs run the CI.

GitHub runs five hosted macOS jobs at a time, and your agents open more pull requests than that. Buildhound turns the Mac mini you own into clean, single-use runners beside GitHub's, and new jobs route to the healthy side when it is off.

Set up by hand

Copies one prompt for Claude Code, Codex or Cursor.

faster than GitHub-hosted: About 3x
per job, destroyed after: 1 VM
to boot a Linux VM: About 2 s
for public repositories: $0

Pull requestyour-org/ios-app

Add offline sync to the photo picker

Opened by your coding agent, 9 minutes ago

Cache photo metadata for offline use
Queue uploads while the device is offline
Tests for the sync queue

9 files changed, 214 additions, 38 deletions

Ready to mergeAll checks passed on your MacWaiting for checksRunning in fresh VMs on your Mac

Checks

All passed in 7m 11sRunning 07:11

Native iOS buildmacOS, in a fresh VM on your Mac7m 11s
Tauri desktop appLinux, in a fresh VM on your Mac3m 12s
Lint, typecheck and testLinux, in a fresh VM on your Mac1m 04s

The slowest check, start to finish3.2x faster

Your Mac7m 11s

GitHub-hosted23m 18s

Times measured 8 October 2026 on an M4 Pro MacBook Pro against GitHub's standard runners. The pull request is an illustration.

Measured

The wait is the slow part.

GitHub runs five hosted macOS jobs at a time. When agents push more, the rest queue for a hosted Mac before they start. Your Macs add slots beside those five.

What teams report in public

Other teams' measurements, linked to their sources.

Waited for a hosted macOS runner25m 56sagainst 12s on the same team's own Mac mini, for the same commitSlyWombat/MegaPDF #614 Waited, for a job that ran 221 mina Swift package build on hosted macOS, over about 78 pull request runskaeawc/auto-mobile #11011 Hosted macOS jobs at a time5on GitHub's Free, Pro and Team plans, shared with larger runnersGitHub's Actions limits

Our own runs, on one clock

Three jobs from a production app, the same workflow on both sides.

Job	Your Mac	GitHub-hosted	Speed-up
Native iOS buildmacOS, 8 cores against 3	7m 11s	23m 18s	3.2x faster
Tauri desktop appLinux, 8 cores against 2	3m 12s	9m 03s	2.8x faster
Lint, typecheck and testLinux, 8 cores against 2	1m 04s	3m 12s	3.0x faster

Measured 8 October 2026 on an M4 Pro MacBook Pro, against GitHub's standard runners.

A Next.js web app, a Tauri desktop app and an Expo iOS app in one repository, built by the same workflow on both sides. The Mac is an M4 Pro MacBook Pro with 12 cores and 24 GB; every job ran in a fresh Buildhound VM with 8 vCPUs and 8 GB. GitHub-hosted means its standard runners: x64 with 2 cores for Linux, an M1 virtual machine with 3 cores for macOS. Each job ran twice on the Mac and we show the slower run. The clean VM starts with no cache, so Rust compiled from scratch on the Mac and from GitHub's build cache on GitHub-hosted. GitHub's times come from one iOS run, three desktop runs and, for lint and test, the median of recent runs that missed the build cache. These are run times; the hosted queue comes on top.

Against a plain runner

Keep the Mac. Drop the upkeep.

Plenty of teams register a Mac mini with GitHub themselves. Then every job runs straight on the host, state piles up between runs, and one machine becomes a release dependency.

Clean every time

Every job boots a fresh virtual machine and is destroyed when it ends. Nothing is left from the last run, and the job reaches the internet and nothing else on your network.

Plain runner: Caches, keychains and leftovers pile up on the host
Buildhound: A fresh VM per job, off your network

Never your only runner

When the Mac is off, new jobs route to the healthy side within a minute. A job that waits too long for a busy Mac is re-run on GitHub-hosted.

Plain runner: An offline Mac leaves jobs waiting up to 24 hours
Buildhound: New jobs route to the healthy side

Looks after itself

The agent updates itself and the runner, builds the macOS image on your Mac, and keeps jobs that use secrets on Macs a person marked as trusted.

Plain runner: You update the runner on every Mac, every month
Buildhound: Updates, images and trust handled

A plain runner is fine for one dedicated Mac with no secrets.Every difference, side by side

Routing

Your Macs, plus GitHub's five.

Jobs go to your Macs first, and GitHub-hosted is still there. When every Mac is busy or away, the job runs on the healthy side instead.

Jobs on your Macs

Machines that share a label share the jobs. The Mac mini carries the base load; a plugged-in laptop takes the burst.

your-org/ios-app3 workflows

your-org/web1 workflow

RoutingYour Macs firstthen GitHub-hosted when none canFallback on

mac-miniBaseOnline

macbook-proBurstPlugged inTakes jobs only while plugged in and idle

GitHub-hostedFallbackUsed when no Mac can take the job

A sketch of the routing rules, the same picture as the Fleet page in the dashboard.Strangers' jobs stay on GitHub-hostedSecrets only on trusted Macs

The dashboard

Every job, in one place.

Where each job ran, how long it waited and what GitHub would have billed. Every view is also a command your agent can run.

The Overview page, with sample numbers.

Pricing

Flat per machine. Never per minute.

Public repositories are free on any account. Private ones are $10 a machine a month on a personal account and $20 in an organisation, whatever the minutes.

One Mac at 5,000 macOS minutes a month