Migrate from GitHub-Hosted to Self-Hosted Runners (and Why Managed Is Easier)

By Kaveh Alemi·Latchkey

Teams move to self-hosted for cheaper minutes or bigger machines. Here is the path - and the trade-off you take on.

Self-hosting changes runs-on: to your own labels and hands you the infrastructure: provisioning, scaling, patching, and cleanup. This guide covers the move, then shows where managed runners give the same cost and size wins without the operational tax.

What changes

Before and after

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make build

Self-hosted equivalent

jobs:
  build:
    runs-on: [self-hosted, linux, x64]
    steps:
      - uses: actions/checkout@v4
      - run: make build

Migration steps

1. Register runners on a repo or org (Settings -> Actions -> Runners).
2. Stand up hosts (VMs or containers) and install the runner agent.
3. Add an autoscaler so capacity matches demand (or you pay for idle hosts).
4. Repoint runs-on: to your self-hosted labels.
5. Set up patching, security hardening, and orphan cleanup.

Gotchas

• Idle hosts cost money; without autoscaling self-hosted can be more expensive than hosted.
• Security is on you - never run untrusted PRs on persistent self-hosted runners.
• Long-lived hosts accumulate state; jobs that assume a clean machine can break.

The shortcut: managed runners

Managed runners like Latchkey give you the cost cut (~70% under GitHub-hosted) and bigger machines without standing up hosts, autoscalers, or patch pipelines. You change runs-on: to a managed label and keep the rest of your workflow. Warm pools remove queue time and self-healing auto-retries transient failures.

Key takeaways

• Self-hosting moves runs-on: and the entire ops burden onto you.
• Without autoscaling, idle hosts can erase the savings.
• Managed runners deliver the same wins as a one-line label change.

Frequently asked questions

Related guides

References

• GitHub Actions documentation