Migrate from GitHub Larger Runners to Latchkey
GitHub larger runners give heavy jobs more cores natively. If the per-minute bill is the pain, moving those jobs to Latchkey is mostly a runs-on change.
GitHub larger runners are first-party managed VMs with more cores, RAM, and disk than standard runners. According to GitHub's docs, they are billed at a per-minute rate and included minutes cannot be used for them. Latchkey runs the same jobs on managed runners reached by a runs-on change, typically at a lower per-minute rate, and adds self-healing so transient failures retry automatically. Here is what a migration looks like and where each option is stronger. Verify current GitHub pricing on their site, as vendor pricing changes.
What changes when you migrate
| GitHub larger runners | Latchkey | |
|---|---|---|
| Runner model | First-party managed VMs | Third-party managed runners |
| How you target | Runner group + custom label | runs-on label swap |
| Included/free minutes apply | No (per GitHub docs) | Included free tier |
| Self-healing transient failures | No | Yes (auto detect/fix/retry) |
| Runner-group / label management | You manage it | Not required |
| GitHub-native integration | Deepest (built in) | Standard runner integration |
What stays the same
Your workflow YAML, actions, secrets, and job graph are unchanged. You are still running GitHub Actions; you are only changing which runner the heavy jobs land on.
What changes
- Targeting: instead of a runner-group name plus a custom larger-runner label, you point runs-on at a Latchkey label.
- Billing: larger runners bill per minute with no included-minute allowance (per GitHub docs). Latchkey applies its own pricing with an included free tier.
- Reliability: transient and mechanical failures (OOM kills, disk-full, registry timeouts) self-heal and retry on Latchkey instead of failing the run.
Where GitHub larger runners remain the stronger fit
If you want zero third-party involvement, the deepest GitHub integration, or features tied to GitHub Enterprise Cloud such as static IP ranges for larger runners, staying on first-party larger runners is a legitimate choice. The trade-off is a higher per-minute rate and no self-healing.
A safe migration path
- Pick one heavy workflow currently on a larger runner.
- Duplicate it and swap runs-on to a Latchkey label on the copy.
- Run both for a week and compare wall-clock time, per-minute cost, and re-run count.
- Roll out the rest once the numbers hold for your real builds.
The verdict
If your heavy jobs run often and the larger-runner per-minute bill is the pain, migrating those jobs to Latchkey usually lowers cost and removes flaky re-runs while keeping your workflows intact. If native integration and first-party billing matter more than per-minute price, GitHub larger runners are a reasonable place to stay. Start free and compare against your real builds.