Treating every Mac mini M4 in a pool as interchangeable sounds democratic until one monorepo’s jobs always land on the same host and cook its SSD, or until flaky UI tests need fresh simulators and you accidentally serialize the whole org on a single machine. Affinity is the scheduler’s preference for where work runs; spread is the opposite force—push concurrent jobs across hosts to cut correlated failure and thermal hotspots. This 2026 matrix translates Kubernetes-flavored “soft/hard” thinking into GitHub Actions–style labels, runner groups, and org policies on dedicated Apple Silicon hosts.
Label governance: label namespaces and starvation guards. Fair concurrency: concurrency slices and fairness. OS pinning: macOS and Xcode pinning. Pricing: pricing; help: help.
Soft vs hard affinity (what you are allowed to break)
| Constraint | Behavior if no match | Typical macOS use |
|---|---|---|
| Soft affinity | Queue or pick next best host | Prefer m4-apple-silicon but allow overflow to m2 staging |
| Hard affinity | Stay queued until exact label set matches | Codesign with org-specific keychain on nm-org/signing/* runners only |
| Anti-affinity / spread | Reject host if sibling job from same repo is running | Simulator-heavy workflows: max 1 UI job per host |
When to spread vs when to pin
| Signal | Prefer spread | Prefer pin / hard label |
|---|---|---|
| Disk IO saturation | Yes—stagger heavy DerivedData workloads |
Rare—unless dedicated cache volume per host |
| License / signing | No—keep hard pool | Yes—token-bound hosts |
| Flaky parallel UI | Yes—one shard per host policy | Optional sticky debug host for repro |
Rule of thumb: if two failures on the same host would waste more than 30 min of engineer time to disambiguate, enforce spread or shard by modulo across runner names.
Eight-step rollout checklist
- Inventory workflows with
runs-onlines; tag each as soft, hard, or spread. - Encode spread as either orchestrator feature (unique concurrency group per repo+workflow) or distinct runner labels per shard.
- Limit hard affinity to signing, GPU, or compliance—everything else defaults soft.
- Dashboard queue depth per label; alert when hard pools sit starved while soft pools idle.
- Game-day: kill one host; verify soft jobs migrate, hard jobs wait with clear UI message.
- Document exceptions in the same repo as OS/Xcode manifests.
- Review quarterly as new chips (M5…) appear—soft pools should absorb experiments.
- Cost check: spreading may need +N Mac minis; compare rental burst vs queue SLO slip.
Anti-patterns
Marking every workflow runs-on: [self-hosted, exact-hostname]—you recreated pets. Using only soft labels but never measuring queue fairness—spread is useless if one repo floods the soft pool. Ignoring thermal throttling on laptops repurposed as runners; M4 minis in cloud metal behave more predictably, which is why teams rent dedicated Region Macs instead of stacking CI on developer desks.
NodeMac rents physical Mac mini M4 and Mac-class hosts with SSH/VNC in Hong Kong, Japan, Korea, Singapore, and the United States so platform teams can stand up additional soft pools for burst without a CapEx committee for every affinity experiment.