How to Set Up GitHub Larger Runners

Setting up a GitHub larger runner has three parts: create the runner, place it in a runner group with the right repository access, and target it from your workflow.

According to GitHub's docs, larger runners are available on GitHub Team and Enterprise Cloud plans and are created and managed from organization or enterprise settings. This guide follows GitHub's documented flow. Steps and setting names come from GitHub's docs (https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/manage-larger-runners and https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/running-jobs-on-larger-runners); verify against the current UI, which can change.

Create the larger runner

As an organization owner, open Settings, then Actions, then Runners.
Click New runner, then New GitHub-hosted runner.
Set a Name that indicates the hardware and OS, for example ubuntu-24.04-16core (per GitHub's example).
Choose the Platform: Linux x64, Linux ARM64, or Windows x64.
Choose the Image, then a Size (hardware configuration) based on that image.
Set Maximum concurrency for how many jobs can run at once, assign a Runner group, then click Create runner.

Understand runner groups and repository access

According to GitHub's docs, runner groups control which repositories can use the runner. For enterprise-level groups, repositories have no default access and an owner must grant it explicitly. For organization-level groups, repositories have default access and an owner can restrict it. Manage this under Settings, Actions, Runner groups by choosing All repositories or Selected repositories. Source: https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/manage-larger-runners.

Target the runner from a workflow

According to GitHub's docs, a larger runner is automatically assigned a workflow label matching its runner name, and you can also target it by runner group. Combining both applies AND logic, so the runner must satisfy both. Source: https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/running-jobs-on-larger-runners.

.github/workflows/ci.yml

jobs:
  build:
    # Target by the runner's custom label
    runs-on:
      labels: ubuntu-24.04-16core
    steps:
      - uses: actions/checkout@v4
      - run: ./build.sh

  build-scoped:
    # Require both a group AND a label (AND logic)
    runs-on:
      group: ubuntu-runners
      labels: ubuntu-24.04-16core
    steps:
      - uses: actions/checkout@v4
      - run: ./build.sh

Verify it works

Push the workflow and open the run; the job should show it picked up your larger runner label.
If the job stays queued, confirm the runner group grants access to this repository and the label matches the runner name exactly.
Remember included minutes do not apply to larger runners, so billing starts once the job runs (per GitHub docs).

A lower-overhead alternative

If managing runner groups, labels, and per-minute costs becomes a chore, Latchkey runs the same jobs on managed runners with a plain runs-on label swap, no runner-group setup, a lower per-minute rate, and self-healing retries for transient failures. You can trial it on one workflow without changing the rest.