Are GitHub Actions Free for Open Source Repositories?

Answer

Yes on the default path: GitHub Actions minutes are free on public repositories when the job runs on a standard GitHub-hosted runner, and artifact and cache storage on those repositories is free with them. Managed runners including WarpBuild run public repository jobs as well, once an organization owner checks Allow public repositories on the Default runner group, because GitHub blocks self-hosted and managed runners in public repositories by default.

Three separate questions hide inside "are GitHub Actions free for open source". Answer them in order and the billing picture stops being confusing.

1. Standard GitHub-hosted runners on a public repository. Free. GitHub charges no minutes and no storage for public repositories on the standard ubuntu-latest, windows-latest, and macos-latest labels. GitHub also gives public repositories a larger free shape than private ones get: the standard Linux runner on a public repository is 4 vCPU with 16 GB of RAM, against 2 vCPU and 8 GB on a private repository (GitHub-hosted runner specs, checked on 2026-08-13).

2. Larger GitHub-hosted runners on a public repository. Billed. The free allowance covers standard runners only. A public repository that reaches for an 8-core or 16-core GitHub-hosted label pays the same per-minute rate a private repository pays (GitHub Actions minute multipliers, checked on 2026-08-13).

3. Self-hosted and managed runners on a public repository. GitHub bills nothing for the job itself, because the machine is not theirs. You pay whoever supplies the machine, which is your own cloud bill for a self-hosted fleet or a per-minute rate for a managed fleet. Before any of that, the runner group has to allow public repositories.

That third case is where most maintainers get stuck. 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. An organization owner enables them in two steps, documented on the public repositories setup page:

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

Until that box is checked, a job pointed at a warp- label in a public repository stays queued with no runner assigned. That is the first thing to check in the common issues guide when runners look connected and nothing picks up work.

Pricing is purely usage based.

Detail

What a public repository gets at no charge

The free allowance for public repositories covers the parts of GitHub Actions most open source projects actually use: minutes on standard runners, artifact storage, and Actions cache storage. There is no monthly minute budget to exhaust and no spending limit to raise, which is why a busy project with a hundred contributors can run a full test matrix on every pull request without a payment method on file.

Two limits still apply, and they are not billing limits.

The first is concurrency. Standard GitHub-hosted runners draw from shared pools with a per-account ceiling, and macOS carries a lower sub-ceiling than Linux and Windows (GitHub usage limits, checked on 2026-08-13). A public repository on the Free plan shares that ceiling with every other repository on the account, so a large matrix in one project delays workflows in the others.

The second is job runtime. A single job is capped at 6 hours and a workflow run at 35 days, from the same reference. Long integration suites hit the job cap before they hit any billing wall.

Where the free path ends

Three situations push an open source project off free minutes.

The build outgrew the standard shape. Compile-heavy projects in Rust, C++, and Go, and monorepos with large dependency graphs, saturate 4 vCPU and stay saturated. The GitHub answer is a larger runner label, which is billed on public repositories.

The project needs hardware the free pool does not offer. Linux ARM64 test legs, nested virtualization for Android emulator jobs, and macOS runners with more than the standard core count all sit outside the free standard set.

Queue time is the bottleneck rather than build time. When a release train fans out sixty jobs and the account ceiling admits twenty, the fix is capacity behind a label rather than a faster machine, and self-hosted or managed labels sit outside the GitHub plan ceiling.

Each of those pushes the maintainer toward a runner group decision, which is where the enablement step comes back. The runner groups guide covers how group membership and repository access interact, and the runner group glossary entry defines the term.

Why isolated VMs make public repository builds viable

GitHub's own documentation recommends disabling self-hosted runners on public repositories, and the reason is specific: a pull request from any contributor can execute arbitrary code in the workflow, which reaches whatever the runner machine can reach (self-hosted runner security). A persistent runner registered on a corporate network, holding cloud credentials in its instance profile, is a bad place to execute a stranger's build script.

The risk sharpens with container-based fleets. actions-runner-controller runs workflows in containers on a Kubernetes cluster, and containers share a kernel with the host, so the isolation boundary is thinner than a virtual machine boundary and node-level credentials sit close to the workload.

WarpBuild runners answer the objection with the machine lifecycle. Each runner runs in its own virtual machine, created on demand and destroyed after the build, with an encrypted storage volume that is created and destroyed on the same cycle. The VMs are ephemeral and never reused, so one contributor's job cannot read state left behind by another and cannot outlive its own workflow run. The runners also carry the same tools and versions as GitHub-hosted runners, which keeps a public repository's workflow file portable between the two.

Compliance evidence for that posture is SOC 2 Type 2, with the report and current control status published at trust.warpbuild.com.

Dependabot is the one caveat to plan around

GitHub does not run Dependabot updates on public repositories when self-hosted runners are in use. Managed runners register as self-hosted runners, so the restriction applies to them. This is a GitHub security decision documented in managing Dependabot on self-hosted runners.

The practical answer is to leave Dependabot workflows on GitHub-hosted labels. Dependency update jobs are short and light, so the standard free public repository runner handles them, and the rest of the matrix can point at warp- labels.

A workflow that keeps fork pull requests on GitHub-hosted runners

Many maintainers want the faster machines for trusted work and the free pool for pull requests from forks. One job resolves the label and the rest of the workflow consumes it.

name: ci

on:
  push:
    branches: [main]
  pull_request:

jobs:
  pick-runner:
    runs-on: ubuntu-latest
    outputs:
      linux: ${{ steps.choose.outputs.linux }}
    steps:
      - id: choose
        env:
          IS_FORK: ${{ github.event.pull_request.head.repo.fork }}
        run: |
          if [ "$IS_FORK" = "true" ]; then
            echo "linux=ubuntu-latest" >> "$GITHUB_OUTPUT"
          else
            echo "linux=warp-ubuntu-latest-x64-8x" >> "$GITHUB_OUTPUT"
          fi

  test:
    needs: pick-runner
    runs-on: ${{ needs.pick-runner.outputs.linux }}
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - run: npm ci

      - run: npm test

  macos-test:
    if: github.event_name == 'push'
    runs-on: warp-macos-latest-arm64-6x
    steps:
      - uses: actions/checkout@v4

      - run: xcodebuild -scheme App -destination 'platform=macOS' test

The pick-runner job costs a few seconds on a free standard runner. Fork pull requests stay on ubuntu-latest, branch pushes from maintainers land on warp-ubuntu-latest-x64-8x, and the macOS leg runs only after merge.

What the paid path costs on a public repository

The comparison below only matters for jobs that outgrew the free standard runner. WarpBuild rates come from the pricing page. GitHub rates come from the GitHub Actions minute multipliers reference and shapes from the runner specs page, both checked on 2026-08-13.

The macOS row compares the nearest GitHub ARM64 macOS shape. The WarpBuild runner in that row carries one more vCPU and 8 GB more RAM at the lower rate.

Worked model: an open source project that outgrew the free pool. The repository merges enough work to run 300 builds a month. Each build runs one Linux job of 8 minutes on an 8 vCPU machine and one macOS job of 10 minutes.

• Linux: 300 x 8 = 2,400 minutes. GitHub 8-core Linux larger runner at $0.022 per minute is $52.80 a month. warp-ubuntu-latest-x64-8x at $0.016 per minute is $38.40 a month.
• macOS: 300 x 10 = 3,000 minutes. The largest GitHub-hosted macOS ARM64 runner at $0.102 per minute is $306.00 a month. warp-macos-latest-arm64-6x at $0.08 per minute is $240.00 a month.
• Monthly total: $358.80 against $278.40, a difference of $80.40 a month and $964.80 over twelve months at list prices checked on 2026-08-13.

Jobs that stayed on standard GitHub-hosted runners still cost nothing, so a mixed workflow like the one above pays only for the legs that moved.

Related Questions

Are GitHub Actions minutes free on public repositories?

Minutes on standard GitHub-hosted runners are free on public repositories, and so is artifact and cache storage. Larger GitHub-hosted runners are billed on public repositories at the same per-minute rates as private ones, so the free path ends the moment a job asks for more cores. The private repository answer covers how the included-minutes allowance works on the other side.

Why do managed runners not pick up jobs in my public repository?

GitHub disables self-hosted and managed runners in public repositories by default. An organization owner has to check Allow public repositories on the Default runner group, id 1, at github.com/organizations/YOUR_ORG/settings/actions/runner-groups/1. Until that box is checked the job sits queued. The public repositories documentation has the screenshot, and the runner groups guide covers non-default groups and workflow restrictions.

Is it safe to run pull requests from strangers on managed runners?

WarpBuild jobs run inside a virtual machine created for that job and destroyed when the job finishes, with an encrypted storage volume that is destroyed with it. Nothing from one contributor's pull request survives into the next job, which is what makes public repository use viable. The runner security answer goes through the threat model in more depth.

Does Dependabot work on public repositories with self-hosted runners?

No. GitHub does not run Dependabot updates on public repositories when self-hosted runners are in use, and managed runners register as self-hosted runners. Keep Dependabot workflows on GitHub-hosted labels in public repositories and point the rest of the matrix at warp- labels.

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