2026 burst-build grid-in: cloud Mac runner registration, network self-checks, and least-privilege tokens in 30–60 minutes

Short-cycle bursts — hotfix lanes, App Store review rebuilds, or a Friday spike in merges — punish anything fuzzy in onboarding. The expensive minute is rarely Xcode itself; it is the first time a fresh cloud Mac touches your control plane: runner labels do not match, Git LFS pulls stall on DNS, or a PAT accidentally ships write access to every repository. This note is a practical 30–60 minute checklist we use to bring a newly provisioned cloud Mac from “SSH works” to “eligible for production jobs,” with explicit network self-checks and token hygiene.

The 30–60 minute timeline (what “done” means)

Split the window into three slices you can parallelize slightly, but never skip: register and label the runner, prove outbound paths with measurements, then attach least-privilege credentials. “Done” means a no-op workflow and a real workflow both succeed on the same labels, and you can paste the proof commands into an incident ticket without redacting half the output.

For pool sizing and when to prefer elastic burst nodes over always-on runners, see 2026 short-cycle CI peaks: self-hosted GitHub Actions macOS runners — elastic cloud Mac pool or always-on nodes? For cache placement after the runner is healthy, pair this checklist with 2026 short-cycle cloud Mac CI: remote build caches vs node-local disk.

Runner registration that survives the first real job

Install the runner under a dedicated macOS user — not the human who ordered the machine — so screen sharing sessions and accidental Keychain prompts do not steal the service context. Pin the runner directory outside synced cloud folders; iCloud Drive or Dropbox under the home directory is a classic source of mysterious file locks during actions-runner upgrades.

Run a disposable workflow first — checkout, print sw_vers, and archive a tiny log artifact — before enabling signing steps. If your platform supports runner groups, place burst nodes in a group that only sees repositories allowed to build on self-hosted hardware.

Network self-check (measure, do not assume)

From the runner account, script four probes: TCP connect + TLS handshake time to your Git host, a 10 MB LFS sample if you use large assets, DNS resolution for any internal registry mirror, and HTTPS to Apple notary or App Store Connect endpoints you actually call in CI. Record median and p95; a runner that “works in Safari” under an admin session is not evidence for the service user.

# Replace hostnames with your real remotes
time git ls-remote https://github.com/org/repo.git HEAD
dig +short github.com git-lfs.github.com api.apple.com
curl -I https://github.com  |  head -n 5

If p95 spikes only from the cloud region, fix routing or add a pull-through cache before you blame Xcode. Keep proxy environment variables (HTTPS_PROXY) identical between interactive shells and the runner service plist; mismatches here produce the dreaded “works locally on the same machine.”

Least-privilege tokens and where they live

Prefer OIDC federation from your CI provider to cloud roles over long-lived PATs. When PATs are unavoidable, use fine-grained tokens scoped to a single repository with read-only contents and read-only metadata, plus a second narrowly scoped token for releases that is injected only on protected branches. Never store organization-level admin tokens in the runner Keychain “for convenience.”

Map secrets to steps: uploading symbols should not reuse the credential that tags a release. For Mac-specific signing, keep certificates in a dedicated keychain unlocked only for the runner user, and avoid copying .p12 bundles into world-readable build trees.

Hand-off to build owners (so ops is not the bottleneck)

Publish a one-page runbook in the repo that links the exact workflow names used for smoke and signing, the label set, and the last known-good network snapshot (median RTT to Git, notary host, and artifact bucket). When a burst starts, on-call should only toggle runner capacity or queue concurrency — not debug DNS from scratch. If you version golden AMIs or cloud images, include the image tag in the runbook footer so developers can diff environment drift without opening a ticket.

FAQ — the questions that arrive during the first burst

Why does the first job succeed and the second fail?

Often a warm dependency cache masked missing credentials: the first build reused a pre-seeded DerivedData tree while the second cold path hit a private registry. Re-run with a clean workspace flag and watch network errors, not compiler errors.

Should the runner auto-update during a sprint?

Defer auto-updates behind a maintenance label. Burst weeks are the wrong time to silently bump the runner patch level; pin the runner version in your golden image and roll forward with a calendar slot.

How do we prove the machine is safe if multiple contractors SSH in?

Rebuild from a known image after elevated access, rotate CI secrets, and compare file integrity baselines for /usr/local and the runner directory. Treat ad-hoc SSH the same as temporary root on a database — it invalidates the “clean room” promise until reprovisioned.