GitHub-hosted vs self-hosted vs managed runners: cost, effort and security

Updated 24 Oct 2026 · prices and specs read on 24 Oct 2026

GitHub-hosted runners cost per minute and need no upkeep; self-hosted runners cost nothing in GitHub minutes but you pay for and maintain the machines, and GitHub advises they should almost never serve public repositories; managed runners (Blacksmith, Ubicloud, FlameWill and others) are self-hosted runners someone else runs, priced per minute below GitHub's.

The three ways to run a job

What self-hosting really costs

The machines are the cheap part. RunsOn, which runs runners in your own cloud account, publishes about $0.0009 a minute for 2 arm64 CPUs on spot capacity, plus its yearly license from €300. The rest is work you take on:

• Scaling to zero and back. Machines that wait for jobs cost money while idle; machines started per job add start-up time. GitHub’s Actions Runner Controller does this on Kubernetes; other projects do it on a cloud provider’s own services.
• The image. Runners need the tools your jobs expect (GitHub’s hosted image comes with a long list preinstalled), kept up to date: GitHub says you are responsible for updating the operating system and all other software.
• Capacity. Spot or preemptible machines are cheapest and can be taken back mid-job; something has to notice and re-run the job.
• Security (below), which is the part that hurts when it is wrong.

Security: one job, one fresh machine

GitHub’s own advice on self-hosted runners, from its secure-use reference:

• self-hosted runners “should almost never be used for public repositories”, because anyone can open a pull request and compromise the environment;
• they “can be persistently compromised by untrusted code in a workflow”, and there is no way to guarantee a reused runner only runs one job;
• just-in-time runners run at most one job, but re-using the hardware can still expose what the last job left.

So a safe self-hosted setup gives every job a just-in-time runner on a machine that is destroyed after the job, and puts the runners in a runner group that does not allow public repositories. That is how FlameWill runs: one job per machine, destroyed after it, no inbound network, and runner groups that never serve public repositories.

Which to choose

• Public open-source project: GitHub-hosted standard runners. They are free there, and self-hosted runners should not take pull requests from forks.
• Private repositories, light CI: GitHub-hosted, within your plan’s included minutes.
• Private repositories, heavy or memory-hungry CI: managed runners. Per minute they cost a fraction of GitHub’s larger runners at the same memory (see runner pricing and the cost calculator), with no machines to run.
• Everything must stay in your own cloud account: self-host with an autoscaler, and budget the time.

Trying a managed runner takes one line:

jobs:
  test:
    runs-on: flamewill-2vcpu-8gb-ubuntu-2404   # was: ubuntu-latest