Ephemeral or dedicated: which cloud Mac should your agent use?
A disposable Mac per task or one machine you keep: the trade-offs in cost, clean state, secrets, caches and speed, and how to decide.
· 7 min read
Need a Mac for this? NoMac gives your agent full macOS with Xcode, from $9.99 a month, billed by the second. Start now →
There are two ways to give an agent a Mac. You can rent one machine and keep it, like a second laptop in a data centre. Or you can start a fresh one for each task and throw it away afterwards. Both are reasonable. They fail in different ways, and the right choice depends on what your agent does and how often.
The core trade: a dedicated Mac is fast because it remembers everything. An ephemeral Mac is safe and predictable because it remembers nothing.
What a dedicated Mac gives you
- ·Warm caches. DerivedData, SwiftPM checkouts, CocoaPods and Homebrew stay put. The second build is much faster than the first.
- ·Whole-machine performance. All the cores and memory are yours.
- ·Persistence. Files, simulators and configuration survive between sessions, so long-running services and self-hosted CI runners work.
- ·Predictable monthly cost, whether you use it or not.
What an ephemeral Mac gives you
- ·A clean state every time. No leftover keychain entries, stale caches, half-installed tools or a
~/.gitconfigan agent edited last Tuesday. If a build works, it works from scratch, which is what your CI and App Store builds need. - ·Secrets that do not linger. Anything sent to the machine, including a signing certificate or a token, is gone when the VM is deleted.
- ·Agents cannot break it permanently. Root access is safe to hand over when the worst case is “start a new one.” On a dedicated Mac, an agent that uninstalls the wrong Ruby has broken your machine until a human fixes it.
- ·Cost that follows usage. You pay for the minutes the Mac exists.
Where each one hurts
| Problem | Dedicated | Ephemeral |
|---|---|---|
| Cold builds | Rare | Every session starts cold |
| Drift and mystery state | Grows over time | None |
| Leaked credentials | Persist until someone cleans up | Deleted with the VM |
| Agent breaks the toolchain | A human repairs it | Start another |
| Idle cost | You pay for every idle hour | None |
| Availability | Always there once rented | Start can queue at peak times |
| Long-running services | Yes | No, sessions end |
Making ephemeral Macs fast enough
The cold-start penalty is real but manageable:
- ·Keep one session for a burst of work. Start a Mac, do the build, the fixes and the tests in the same session, then stop. Caches warm up within the session.
- ·Start from a rich image. Xcode, simulator runtimes and common toolchains should already be there. Installing Xcode per session would take longer than most tasks.
- ·Resolve dependencies once per session and commit lockfiles (
Package.resolved,Podfile.lock) so resolution is quick and reproducible. - ·Build what you changed. Build one scheme and one destination, not the whole matrix, until the change is ready.
How to decide
- ·Choose dedicated if the Mac is busy most of the day, you run a self-hosted runner or service on it, or build time dominates everything else.
- ·Choose ephemeral if an agent does the work in bursts, you want every build to prove it works from scratch, or you would rather not trust a long-lived machine with credentials.
- ·Use both if you are a team: a dedicated runner for CI, disposable sessions for agents and debugging.
NoMac is the ephemeral kind: a fresh macOS VM with root and Xcode, billed by the second, deleted on stop. For dedicated options, see RentAMac and Scaleway, and for how secrets behave on each, read signing secrets on a rented Mac.