Migrate from GitHub-Hosted to Managed Runners (Without Downtime)

Moving to managed runners is usually a one-line change per job - runs-on: - done gradually so nothing breaks.

You do not have to migrate everything at once. Managed runners attach to your existing workflows by changing the runs-on: label, so you can move high-volume jobs first, verify, and expand.

Migration steps

1. Identify your highest-minute workflows (the biggest cost savings first).
2. Connect the managed-runner provider to your repo or org.
3. Change runs-on: ubuntu-latest to the provider label on one workflow.
4. Run it in parallel and confirm timing and results match.
5. Roll out to remaining workflows by label, monitoring cost and speed.

jobs:
  build:
    runs-on: latchkey-medium   # was: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Why this is low-risk

• It is per-job: revert a single label to roll back.
• Your workflow YAML, actions, and caching are unchanged.
• You can A/B one job before committing the fleet.

What you gain

Roughly 69% lower per-minute cost, built-in caching, and - on Latchkey - self-healing that retries transient failures automatically so you stop paying for re-runs.

Key takeaways

• Migration is a per-job runs-on: label change.
• Move highest-minute jobs first for the biggest savings.
• Roll back instantly by reverting a label.

Related guides