Migrate from Self-Hosted to Managed Runners (Drop the Ops)

You already run self-hosted to save money or get bigger machines. Managed runners give you both without the ops burden - usually a one-line runs-on: change.

Self-hosted runners mean you own scaling, patching, security, and cleanup. Managed runners take that over while keeping your workflows identical. You move by repointing the runs-on: label, one workflow at a time.

What changes

Before and after

jobs:
  build:
    runs-on: [self-hosted, linux, x64]   # was: your own fleet
    steps:
      - uses: actions/checkout@v4
      - run: make build test

The managed equivalent

jobs:
  build:
    runs-on: latchkey-medium   # managed, ephemeral, self-healing
    steps:
      - uses: actions/checkout@v4
      - run: make build test

Migration steps

1. Pick one workflow currently on self-hosted runners.
2. Connect the managed-runner provider to your org or repo.
3. Swap runs-on: [self-hosted, ...] for the managed label.
4. Run in parallel, confirm timing and results match, then expand.
5. Decommission idle self-hosted hosts once everything is moved.

Gotchas

• If steps assumed persisted workspace or host state, fix that - managed runners are ephemeral (this is usually a latent bug self-hosting masked).
• Recreate any host-installed tools as setup steps or use a custom runner image.
• Map self-hosted labels carefully so jobs land on the right managed size.

What you gain

• Roughly 69% lower per-minute cost than GitHub-hosted runners.
• Warm pools remove queue time - jobs start almost immediately.
• Self-healing detects, fixes, and auto-retries transient and mechanical failures.
• Zero ops: no agents, autoscalers, or controllers to patch and babysit.

Key takeaways

• Migration is a runs-on: label swap, not a rewrite.
• You drop autoscaling, patching, and orphan cleanup.
• Ephemeral + self-healing runners replace fragile long-lived hosts.

Related guides