Get started
Introduction
Understand what Mirage runs, what it stores, and where to start.Mirage routes GitHub Actions onto paired Apple-silicon Macs while GitHub remains the source of truth for checks, logs, artifacts, caches, and secrets.
How Mirage fits
Mirage has two composed layers. The Local Mac backend reserves a machine and starts a disposable runner VM. The CI-provider control layer adapts eligible jobs so you can compare and promote execution targets safely.
GitHub ActionsAuthoritative workflow
Mirage controlRoute or experiment
GitHubLocal MacCloudflare
Start here
1 · Set upQuick start
Connect GitHub, pair a Mac, and route your first Actions job.
→2 · ConfigureWorkflow routingUse attempt-aware runner labels to make local execution fail safe.
→3 · UnderstandLocal Mac executionLearn how Mirage reserves capacity and creates disposable runner VMs.
→OptionalCI providers and experimentsCompare providers safely and promote a successful per-job route.
→Core principles
- GitHub stays authoritative. Runners connect directly to GitHub for CI data.
- Local work is disposable. Every job runs in a fresh Containerization or Tart VM.
- Fallback is explicit. Attempt 2 uses the runner in your workflow expression.
- Installations are isolated. Each GitHub installation owns its repositories and routes.
- Experiments do not gate. Provider comparisons never change the source pipeline.