Do Public Repositories Pay for Runners?

Answer

A public repository pays nothing for minutes on standard GitHub-hosted runners, and it pays the machine supplier for everything else. WarpBuild runners can be enabled for public repositories with the documented setup, and the security considerations for pull requests from forks are documented alongside it on the same page.

The enablement step comes first, because until it is done a job pointed at a warp- label in a public repository sits queued with no runner assigned. WarpBuild registers itself as a self-hosted runner in the Default runner group, id 1, for your GitHub organization, and GitHub disables self-hosted runners in public repositories by default. Per the public repositories documentation:

1. Open https://github.com/organizations/[YOUR_ORG]/settings/actions/runner-groups/1.
2. Check the box for Allow public repositories.

GitHub Enterprise supports creation of multiple runner groups, and WarpBuild runners are added to the Default group, id 1, there as well. So on Enterprise the box to check is on that group rather than on a group created for another fleet. Group membership and repository access are covered in GitHub's runner group access documentation.

Once the box is checked, the repository is billed per minute for the jobs that land on warp- labels. The rates below come from the pricing page and the cloud runners catalog, checked on 2026-08-13.

Read the pipeline off that table one job at a time. The free side stays free: minutes and storage on standard GitHub-hosted runners cost a public repository nothing, per GitHub's Actions billing documentation, checked on 2026-08-13. The open source billing answer covers where that free allowance ends.

Detail

What a pull request from a fork can and cannot reach

This is the question that decides whether a maintainer turns managed runners on at all, so it is worth stating in both directions.

What the fork's code reaches: the runner machine it executes on, whatever that machine can reach on the network, and anything an earlier job left on its disk. A pull request is a proposal to run arbitrary code, and the runner runs it.

What it does not reach on the default pull_request trigger: repository secrets are not passed to workflows triggered by a pull request from a fork, and the GITHUB_TOKEN for that run is read-only. Runs from first-time contributors also wait for maintainer approval before any job starts. All three behaviors are described in GitHub's events reference, checked on 2026-08-13.

The exception worth writing down: pull_request_target runs the workflow file from the base branch in the base repository's context, with secrets and a writable token available. A workflow that uses that trigger and then checks out the fork's head commit hands the fork exactly what the default trigger withholds. Public repositories should keep build and test work on pull_request.

Why the machine matters more than the trigger

GitHub's runner group access documentation recommends only using self-hosted runners with private repositories, and the reason is the machine rather than the trigger. A persistent runner holds cloud credentials in its instance profile, caches on local disk, and network routes into a private environment. Contributor code that executes there inherits all of it. The problem sharpens on container fleets such as actions-runner-controller, where workflows share a kernel with the host and node-level credentials sit close to the workload.

WarpBuild answers this with the runner lifecycle, documented on the security page. Each runner runs in its own virtual machine, created on demand and destroyed after the build. The VMs are ephemeral and never reused. Each runner also gets its own encrypted storage volume, created and destroyed on the same cycle, and WarpBuild does not access or store build secrets. One contributor's job cannot read what another contributor's job left behind, because there is nothing left behind. The runners carry the same tools and versions as GitHub-hosted runners, so a public repository's workflow file stays portable between the two labels.

What a public project actually spends in a month

Here is a mid-sized open source project priced job by job, with the assumptions written out so you can substitute your own numbers.

Assumptions:

• 500 workflow runs in the month.
• 350 of them come from fork pull requests and stay on ubuntu-latest.
• 150 come from maintainer branches and merges to main, each running one 9 minute Linux job on warp-ubuntu-latest-x64-8x.
• 20 release runs add a 12 minute macOS leg on warp-macos-latest-arm64-6x.

The arithmetic, at the rates in the table above:

• Fork pull requests: 350 runs on standard GitHub-hosted runners, $0.00.
• Linux: 150 x 9 = 1,350 minutes at $0.016 = $21.60.
• macOS: 20 x 12 = 240 minutes at $0.08 = $19.20.
• Month total: $40.80.

Two structural points sit underneath that total.

A quiet month bills less by the same arithmetic. There is no minimum to hit and no allowance to forfeit, so a project that ships nothing in August pays for the jobs it ran in August.

Public repositories already running warp- labels

Public OSS repositories running warp- labels are citable evidence, and the workflow files are open to read. The bitcoin/bitcoin GitHub Actions workflow routes its Linux jobs across warp- labels sized per job, from warp-ubuntu-latest-x64-2x for lint up to warp-ubuntu-latest-x64-16x for the fuzz and MSan matrices, with compiler caches restored and saved between runs (checked on 2026-08-13). That per-job sizing is the pattern the table above is meant to support: cheap labels for lint and format, large labels for the matrices that actually saturate cores.

The open source projects guide works through the routing side, including how to keep fork pull requests on the free pool while maintainer pushes take the faster labels.

Related Questions

Does a public repository pay for GitHub Actions runners?

Not on standard GitHub-hosted runners, where minutes and storage are free for public repositories (GitHub Actions billing documentation, checked on 2026-08-13). Anything that runs on a larger GitHub-hosted runner or on a managed runner is billed.

How do I turn on managed runners for a public repository?

An organization owner opens the Default runner group, id 1, at github.com/organizations/[YOUR_ORG]/settings/actions/runner-groups/1 and checks Allow public repositories. GitHub Enterprise supports creation of multiple runner groups, and WarpBuild runners are added to the Default group there too, so that is still the group to change. Until the box is checked, a job pointed at a warp- label stays queued with no runner. The public repositories documentation has the screenshot.

What can a pull request from a fork reach on the runner?

The code in the pull request executes on the runner machine, so it reaches that machine, whatever the machine can reach on the network, and anything left on its disk. On the default pull_request trigger it does not receive repository secrets and its GITHUB_TOKEN is read-only (GitHub events reference, checked on 2026-08-13). WarpBuild runs each job in its own virtual machine with its own encrypted volume, both destroyed when the job finishes, per the security documentation.

Enable the Default runner group with the steps in the public repositories documentation, price your own job mix against the table above on the pricing page, and start with $10 in free credits.