Can I Restrict Which Repositories Use My Runners?

Yes. Repository access to a set of runners is decided by the GitHub runner group those runners belong to, and WarpBuild registers its runners into the Default runner group (id 1) of your organization unless you select another group in the dashboard (public repositories documentation). A second allowlist sits in front of that one: the repository list on your WarpBuild GitHub connection, which decides which repositories the WarpBuild bot serves at all (common issues).

Answer

A job has to pass both allowlists before any runner picks it up, and both are evaluated before label matching happens (common issues). That is what makes restriction reliable: a repository you leave off either list has no eligible runner, whatever runs-on label its workflow names.

Rows come from the common issues guide and the public repositories guide, checked on 2026-08-13.

Two properties of this design are worth stating before the setup path. First, a group covers every runner inside it. One repository access list governs all four platforms at once, so a matrix job that stalls on every leg at the same moment points at access rather than at any one image. Second, the access list decides eligibility rather than capacity, so removing repositories from a group changes who may run jobs rather than how many jobs run in parallel. The parallelism question is answered separately in do runner groups limit concurrency.

Detail

The setup path for a non-default group

GitHub Enterprise supports creating multiple runner groups, and WarpBuild runners land in the Default group (id 1) until you say otherwise (public repositories documentation). The sequence for a narrower list:

1. In GitHub organization settings, open Actions, then Runner groups, and create a group such as warpbuild-runners.
2. Set repository access on that group to selected repositories, and add exactly the repositories that should be allowed to run jobs on WarpBuild runners.
3. Open https://app.warpbuild.com/ci, go to Runners, and set the Default GitHub Runner Group to the group you created so runners register into it (common issues).
4. Push a change in an allowed repository and confirm the job starts. Push one in an excluded repository and confirm it stays queued with an empty log.
5. Keep the list under review through the GitHub REST API for self-hosted runner groups if you would rather version the access list than edit it in a browser tab.

Once the group exists, a workflow can name it directly. GitHub narrows the candidate runners to the group first, then applies the usual label match inside it (common issues):

name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on:
      group: warpbuild-runners
      labels: [warp-ubuntu-latest-x64-4x]
    steps:
      - uses: actions/checkout@v4
      - name: Print runner identity
        run: echo "name=$RUNNER_NAME os=$RUNNER_OS arch=$RUNNER_ARCH"
      - run: make test

  package:
    runs-on:
      group: warpbuild-runners
      labels: [warp-ubuntu-latest-arm64-4x]
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/package.sh

A job that names no group stays eligible for any group the repository can reach, which is why the plain runs-on: warp-ubuntu-latest-x64-4x form keeps working after you create the group. The Print runner identity step is a cheap probe during rollout: if that line never appears in the log, no runner claimed the job and the cause is access.

Workflow restrictions inside a group

A group can be pinned further, to named workflow files at a specific branch, tag, or SHA. Restrictions are written as a full path with a ref:

monalisa/octocat/.github/workflows/cd.yaml@refs/heads/main

That entry allows cd.yaml on main and nothing else. Each entry is an allow rule, so the first one you add excludes every workflow you did not list (common issues). This is the layer that produces the confusing case, where a deploy workflow runs and the pull request check in the same repository queues forever, so record the intent somewhere your reviewers can read it.

The public repository consideration

GitHub disables self-hosted runners, including managed ones such as WarpBuild, in public repositories by default. The switch lives on the default group's settings page at https://github.com/organizations/[YOUR_ORG]/settings/actions/runner-groups/1, as the Allow public repositories checkbox (public repositories documentation). Leaving it unchecked is the coarsest restriction available, and it applies to every public repository in the organization at once.

The reason GitHub ships that default is that a pull request from an outside contributor can run arbitrary code on shared infrastructure (GitHub self-hosted runner security). WarpBuild runs each workflow inside an isolated virtual machine, which is what makes the checkbox safe to turn on here. One documented exception survives the change: for security reasons, Dependabot updates do not run on self-hosted runners in public repositories (GitHub Dependabot on self-hosted runners).

What the allowed repositories cost to run

Access lists change who runs jobs, and the bill still follows minutes. Rates for the labels in the workflow above, from the pricing page, checked on 2026-08-13:

At the 4 vCPU, 16 GB shape, warp-ubuntu-latest-x64-4x costs $0.008 per minute against $0.012 per minute for the GitHub-hosted 4-core Linux larger runner: (0.012 - 0.008) / 0.012, which is 33 percent lower list price (GitHub Actions billing reference, checked on 2026-08-13).

Related Questions

Which runner group do WarpBuild runners join by default?

The Default runner group, id 1, of your GitHub organization. If you want a narrower repository list, create a non-default group, give it a selected-repositories access list, and point WarpBuild at that group under Runners in the dashboard. The full troubleshooting order is in using runner groups with GitHub Actions.

How do I restrict runners to a subset of repositories?

Use both documented layers. The repository list on the WarpBuild GitHub connection decides which repositories the bot serves, and the repository access list on the runner group decides which repositories may claim the runners on the GitHub side. A repository has to pass both, so the stricter of the two lists is the one that takes effect. Runner group, defined covers the GitHub-side object itself.

What does a blocked repository look like in the Actions tab?

The job stays queued with an empty log, because no runner ever claims it and nothing writes to the log. GitHub cancels a job that has been queued for 24 hours (GitHub Actions limits, checked on 2026-08-13), so a policy mistake reports itself a day after the push. Confirm the repository against the common issues checks before adding runner capacity.

Set the group up with the steps above, price the allowed repositories against your own minutes on the pricing page, and hand a reviewer the security review material if the access model needs to be documented.