macOS CI/CD Runner

Why run your own macOS CI/CD runner

Hosted macOS minutes are convenient, but every job starts on a clean machine and every minute is billed. Once your team pushes more than a few times a day, a self-hosted runner on a Mac you control is usually faster and easier to budget for.

• Warm caches. DerivedData, Swift Package Manager checkouts, CocoaPods, Homebrew and Gradle caches stay on disk between jobs. Incremental builds stop starting from zero.
• Fixed cost. You pay per month, not per build minute. A busy release week costs the same as a quiet one.
• Your toolchain. Pin the Xcode versions you need, preinstall simulator runtimes and keep the exact Ruby, Node or Java your pipeline expects.
• Dedicated hardware. Each Hatmac machine is a physical Mac assigned to one customer. It is not shared and not a virtual machine, so build times stay consistent.

The trade-off is that you maintain the machine: macOS updates, Xcode upgrades and disk clean-up are yours to schedule. For most teams that is a small, predictable job.

Prices in USD per month for each machine's starting configuration. More memory, storage or several machines? Ask us.

Which CI system it works with

A cloud Mac is a normal macOS machine with a full desktop and terminal, so any CI tool that ships a macOS agent will run on it. These are the most common setups, each with its own step-by-step guide:

CI system	How the Mac connects	Guide
GitHub Actions	Runner app polls GitHub over outbound HTTPS	GitHub Actions Mac runner
GitLab CI/CD	gitlab-runner with the shell executor, outbound HTTPS	GitLab macOS runner
Jenkins	Controller connects over SSH, or the agent connects inbound	Jenkins macOS build agent
Buildkite, TeamCity and others	Vendor agent binary for macOS	Install it like any macOS service

GitHub and GitLab runners only make outbound connections, so you do not need to open extra ports. Jenkins over SSH needs the controller to reach the Mac on its SSH port.

Security basics for a build Mac

A CI runner executes whatever code your pipeline tells it to. Treat it like production infrastructure.

1. Use a dedicated user. Run the runner as a standard user, not your admin account. Keep admin access for maintenance only.
2. Use a separate keychain for signing. Import certificates into a keychain that only the CI user uses, unlock it in the job and lock it afterwards.
3. Keep secrets in your CI system. Store certificate passwords and App Store Connect API keys as CI secrets, not in the repository or in plain files on the Mac.
4. Do not run untrusted code. On a persistent runner, avoid building pull requests from forks of public repositories.
5. Patch regularly. Apply macOS security updates and plan Xcode upgrades between releases.

Create the CI user (the command prompts for a password):

sudo sysadminctl -addUser ci -fullName "CI Runner" -password -

A typical keychain setup for code signing, run as that user:

security create-keychain -p "$KEYCHAIN_PASSWORD" ci.keychain-db
security set-keychain-settings -lut 21600 ci.keychain-db
security list-keychains -d user -s ci.keychain-db login.keychain-db
security import dist.p12 -k ci.keychain-db -P "$P12_PASSWORD" -T /usr/bin/codesign
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "$KEYCHAIN_PASSWORD" ci.keychain-db

The last command lets codesign use the key without a UI prompt, which is what usually blocks headless builds.

Choosing the right Mac

• Mac mini M4 or M6, 16GB / 256GB: one pipeline, small to medium apps, lint and unit tests. Month to month is available.
• Mac mini M6, 24GB / 512GB: our most popular plan. Room for two Xcode versions, several simulator runtimes and a healthy cache. Xcode with simulators easily takes tens of gigabytes.
• Mac mini M5 Pro, 24GB / 512GB: larger apps and parallel simulator testing. 6- and 12-month terms.

If one machine is not enough, add more and spread jobs across them. Our Mac build farm page covers multi-machine setups, and you can tell us what you need for a bulk quote.

Getting started

1. Choose a plan in the pricing section and pay by card, PayPal, Bitcoin or USDT.
2. After payment we set up your Mac and email you. Access details appear under My Macs in your account.
3. Connect over SSH or remote desktop, install Xcode and Homebrew, then install your runner. Our Xcode build server guide covers the toolchain.

For a worked example of a full pipeline, read iOS CI/CD on a cloud Mac mini.

FAQ

Is a self-hosted macOS CI/CD runner cheaper than hosted minutes?

It depends on volume. With a fixed monthly price, the more builds you run, the better a dedicated Mac compares. Plans start from $119/mo on a 12-month term.

Can one Mac serve several CI systems?

Yes, but keep each runner under its own user and working directory so caches and keychains do not collide. Most teams pick one system per machine.

Is the Mac shared with other customers?

No. Each machine is a dedicated physical Mac assigned to one customer. It is not a virtual machine.

Can I run more than one job at a time?

Most runners can run several jobs in parallel, but Xcode builds are heavy. On 16GB we suggest one job at a time. For more concurrency, use a larger plan or add machines to a build farm.