Compare completed work, not nominal runner minutes
Take one representative month and count jobs by workflow and operating system. Include failed attempts and reruns. Record the hosted charges those jobs actually incur after your plan’s allowances, alongside storage and other services you would still need.
GitHub currently provides free standard hosted-runner usage for public repositories and plan-dependent allowances for private repositories. A public project with no compute bill has no runner-minute spend to eliminate. Use the current GitHub Actions billing documentation and your own invoice instead of a pricing table copied from an old comparison.
A job that takes five minutes on one machine may take a different amount of time on another. Compare the same commit, tests and outputs on both candidates. An inexpensive minute is not useful if it takes more minutes or retries to finish the work.
Build a monthly cost model for your own hardware
| Input | What to count |
|---|---|
| Hardware | Rental or a monthly allocation of purchase and replacement costs. |
| Power and hosting | Measured average power, electricity, rack space and networking. |
| Operations | Time maintaining hosts, images, credentials and incident recovery. |
| Storage and services | Image hosting, caches, artifacts, backups and applicable software fees. |
| Spare capacity | Headroom and any additional machine needed during maintenance or failure. |
For power, multiply average measured watts by powered-on hours, divide by 1,000 and multiply by your price per kWh. Use average draw across idle and busy periods rather than the power supply’s maximum rating.
Already owning a Mac changes the immediate cash outlay, but it does not make replacement, electricity or operating time disappear. Keep an incremental cash view and a full-cost view if the existing machine would otherwise sit unused.
A worked break-even example
The following numbers are fictional inputs to show the calculation. They are not Baremetal or GitHub prices, measured results, or a savings forecast.
- Fixed monthly cost of the self-hosted setup: $120.
- Additional self-hosted cost per job: $0.02.
- Hosted cost per equivalent job that migration would avoid: $0.10.
Self-hosted monthly cost = 120 + (jobs × 0.02)
Avoided hosted cost = jobs × 0.10
Break-even job count = 120 / (0.10 - 0.02)
= 1,500 jobs per monthAt 1,000 jobs, the example self-hosted cost is $140 against $100 avoided. At 3,000 jobs, it is $180 against $300 avoided. The comparison assumes the hardware can complete that work with acceptable wait times, and that the fixed amount includes the operating effort you chose to count.
If the hosted cost you can avoid is no greater than the extra self-hosted cost per job, there is no break-even point in this model. Included hosted minutes, different job mixes and a need to buy another machine can also change the result. Recalculate by workload instead of applying one average to every Linux and macOS job.
Peak demand decides whether the model is usable
A month of job minutes hides the busiest hour. Record how many jobs arrive together when pull requests merge, release branches build or scheduled tests start. A fleet that is cheap on average may create a long queue at exactly the time developers need feedback.
With Baremetal, VM capacity comes from the hosts you supply. Each Mac is capped at two concurrent VMs, and available memory and host reserves can lower practical capacity. Linux capacity also depends on guest sizing and host resources. Autoscaling runners within those limits does not buy additional hardware.
Separate direct spending from developer delay. Report queue time and end-to-end feedback time alongside the bill; do not assume every minute saved is a minute of salary recovered.
Run a small, repeatable comparison
- Choose a real workflow and pin the commit, toolchain and test scope.
- Record CPU, memory, image version and cache configuration for each runner.
- Run several trials with a cold cache, then with the cache state typical of a normal edit.
- Record queue time, execution time, cache transfer time and success or failure.
- Repeat during a normal busy period to expose contention and capacity limits.
Compare the median and the slower runs, keeping failures visible. Change one major variable at a time so a faster machine is not accidentally credited for a cache change. Upload the same artifacts and perform the same checks on both sides.
Where Baremetal fits
Baremetal manages ephemeral runner registration, VM lifecycle and scheduling on your Macs and Linux hosts. It is free during beta and does not charge for compute minutes on your hardware. Future paid-plan pricing has not been set, so a long-term budget should allow for that uncertainty.
You still supply and maintain the machines and toolchain images. This approach is worth evaluating when you have suitable hardware, repeatable demand and someone who can own those responsibilities. Hosted capacity may fit better when demand is infrequent or highly variable, or when operating machines would distract from your work.
Use the macOS setup guide or bare-metal runner guide to build a small trial before committing more capacity.