Lifecycle
Reservations, warm pool, and how sandboxes are reaped.
Reservation
A reservation is a contract for N Mac minis for X hours. You pay up front ($0.25/hr × N × X). Activation binds physical Mac mini IPs to your reservation and mints a mk_live_* API key.
While the reservation is active, the gateway will only schedule sandboxes for you on those Macs. Every other request sees them as occupied.
Warm pool (macOS)
Each Mac mini keeps 2 macOS VMs pre-cloned and pre-booted from a base image. When you call create(), the gateway picks a warm VM on one of your Macs, marks it occupied, and returns a sandbox_id — typically in under a second.
When you destroy() (or your sandbox times out), the gateway throws away the dirty VM and clones a fresh one in the background. The next caller already has a warm VM waiting.
iOS simulators
iOS doesn't have a warm pool yet (WIP) — booting one takes ~45 seconds. Each Mac mini can run up to 2 iOS simulators concurrently. You pick the device type and runtime (or accept iPhone 17 Pro + the latest iOS by default).
Idle reaper
Sandboxes that go ~2 minutes without an HTTP touch, SSH session, or VNC connection are reaped automatically. For long exec or downloads, send a keepalive heartbeat from a sidecar thread.
End of reservation
When end_at passes:
- All your sandboxes are destroyed.
- The API key is revoked.
- The Macs go back into the available pool.
- Your row moves to "Past reservations" in the dashboard.
You can also end a reservation early via the dev-destroy button (dev only).