A GitHub self-hosted runner, without hosting it yourself

A GitHub self-hosted runner gives your workflows the hardware GitHub does not rent you on the standard runners: more cores, more memory, a GPU, a warm cache. The catch is that someone has to host it. cirunner.dev runs managed GitHub Actions runners for teams whose builds have outgrown the standard runners and who have no one to run a runner fleet. Your workflows change by one line, the runs-on label.

Where GitHub-hosted runners stop fitting

The standard GitHub-hosted runners suit most repositories. They are small VMs, and a C++ or Rust build that saturates its cores for half an hour feels that. GitHub's answer is larger runners: bigger Linux and Windows machines, GPU options, static IPs and runner groups. Larger runners need the GitHub Team or Enterprise Cloud plan, bill per minute on public and private repositories, and do not draw from your included minutes.

That works for many teams. Others want a machine size or image that the catalog does not list, a build cache that survives between jobs, or a per-minute rate that fits jobs running an hour at a time. Teams on the Free plan cannot use larger runners at all.

What running your own GitHub self-hosted runner involves

• Download the open source actions/runner agent, register it at repository, organization or enterprise level with a registration token that expires after one hour, and add labels.
• For isolation, register runners as ephemeral or just-in-time (JIT) so each runner takes one job, and pair that with a fresh VM or container per job.
• For scale, run Actions Runner Controller on Kubernetes, or build your own scaler from workflow_job webhooks, a cloud VM API and the JIT endpoint.
• Keep the runner version current. GitHub stops queuing jobs to runners that fall too far behind and refuses registration from old versions.

Our GitHub Actions self-hosted runner guide covers each step, with commands, if you want to run it yourself.

How managed GitHub Actions runners from cirunner.dev work

1. GitHub has no long-lived runner token: registration tokens expire after one hour. Instead, you install the cirunner.dev GitHub App on your organization or on selected repositories. It asks for the Self-hosted runners organization permission (or Administration on repositories, for repository-level runners), which lets it request a just-in-time runner configuration from GitHub for each job. It does not ask for access to your code. You choose a label, for example cirunner.
2. You pick the machine: cores, memory, x86 or ARM, a GPU if you need one, and a base image.
3. You change the jobs that need it to runs-on: [self-hosted, cirunner]. Other jobs stay on GitHub-hosted runners.

We follow the ephemeral pattern from the guide. For each queued job we start a fresh VM, register a single-use runner on it, run your job and destroy the VM. A build cache persists between jobs, so dependency downloads and compiler caches stay warm without leaking files from one job into the next. You pay per compute minute while jobs run. Jobs on self-hosted runners do not count against your GitHub Actions minutes.

An alternative to GitHub larger runners

Who a custom GitHub runner is for

A good fit if:

• Your workflows compile C, C++, Rust, Android/Gradle, a game engine or CUDA code and get faster with more cores and memory.
• You need ARM builds or a GPU and the hosted options do not match your plan or budget.
• You want ephemeral runners without building the autoscaler.

Not a fit if:

• Your workflow finishes in a few minutes on ubuntu-latest. Stay there.
• You already run Actions Runner Controller or your own scaler, and it keeps up.

FAQ

Are there managed GitHub Actions runners I can use with my existing workflows?

Yes. cirunner.dev registers runners in your organization or repository, and your workflows target them with a label in runs-on. The service is in early access and we onboard teams in small batches. Join the list.

Do GitHub self-hosted runners use Actions minutes?

No. Jobs on self-hosted runners do not consume your included minutes. GitHub announced a per-minute platform charge for self-hosted jobs in December 2025 and postponed it two days later. Check GitHub's Actions billing page for the current state.

Is it safe to use a self-hosted runner on a public repository?

GitHub advises against it, because a fork pull request can run code on the machine. If you do it, use ephemeral runners on throwaway VMs and require approval for outside contributors. A fresh VM per job removes the persistence risk; you still decide which workflows get secrets.

Can I build my own custom GitHub runner instead?

Yes. Register with --ephemeral or the JIT API, boot a VM per queued job, and delete it afterwards. The self-hosted runner guide shows the commands and the Actions Runner Controller setup. Use the configurator to compare with a managed runner.