Do Managed Runners Change My GitHub Permissions Model?

No. Adopting a managed runner platform adds one GitHub App installation with a scoped, reviewable permission set at the organization or repository level, and it leaves the permissions inside a workflow run alone: the GITHUB_TOKEN your steps use is still minted by GitHub Actions for that run, and it still carries whatever the permissions block in your workflow file resolves to (GitHub workflow syntax reference, checked on 2026-08-13).

Two separate permission surfaces are in play, and the confusion usually comes from treating them as one. The installation surface governs what the platform may do against your GitHub account. The workflow surface governs what your own jobs may do, and adopting managed runners does not touch it.

Answer

Here is each control, who owns it, and whether adopting WarpBuild runners changes it.

The installation row is the only one that adds anything. A GitHub App has its own identity and its own declared permissions, which an installer approves at install time and can inspect afterwards, described further in GitHub App. To manage self-hosted runners, the permission set covers read on repository Metadata, read on repository Actions so the app receives the workflow_job event and reads run state, read and write on repository Administration for repository level runners, and read and write on the organization Self-hosted runners permission for organization level runners and runner groups, per GitHub's permissions required for GitHub Apps reference, checked on 2026-08-13. Repository Contents sits outside that set.

Secrets stay on the GitHub side of the boundary. WarpBuild does not access or store any build secrets; they are stored in your source code repository and reach only your runner environment, documented in the runner security reference.

Detail

What the installation is used for

You sign up, then install the app from the WarpBuild dashboard and pick the repositories it may reach, which is the flow in the quick start. From then on the app has one job: it receives the queued-job webhook, provisions a virtual machine, registers an ephemeral runner against your repository or organization, and tears the machine down when the job ends. Each runner gets its own virtual machine and its own encrypted volume, both destroyed after the build, per the runner security reference.

If your organization uses a GitHub IP allow list, add the three WarpBuild control plane egress IPs, 3.13.16.127, 3.141.157.169, and 3.151.226.250, listed in the GitHub Enterprise docs and checked on 2026-08-13. That is an allow list edit rather than a permission grant.

The workflow-side controls that stay in your hands

A job moved to WarpBuild changes one line. Everything governing what the job may do stays where it was:

name: build

on:
  pull_request:

permissions:
  contents: read
  packages: write
  id-token: write

jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/ci-deploy
          aws-region: us-east-1

The permissions key resolves the same way it did before, and the same replacement rule applies: naming any scope drops every scope left out to none, covered in workflow permissions. The OIDC token requested by id-token: write is issued by GitHub Actions with the repository and ref claims your trust policy already matches on, per GitHub's OIDC hardening guide, checked on 2026-08-13. The runner platform sits outside that exchange.

Runs triggered by a pull request from a fork keep their read only token, per GitHub's events that trigger workflows reference, checked on 2026-08-13, and environment protection rules keep gating deployments the same way GitHub's environments documentation describes, checked on 2026-08-13. This model is identical across all four.

What a reviewer can check afterwards

Repository access and removal stay under your control through GitHub's reviewing installed apps settings, checked on 2026-08-13. If an app later asks for a permission it did not declare, every existing installation has to approve the change before it takes effect, so the permission set cannot widen quietly.

The GitHub Enterprise Server path

On GitHub Enterprise Server and on GitHub Enterprise Cloud with data residency, you register the GitHub App on your own enterprise instead of installing a shared one, on the enterprise plan. WarpBuild supplies a manifest so GitHub prefills the name, webhook URL, callback URL, permissions, and events, and your enterprise owns the resulting app, its App ID, client secret, webhook secret, and private key. Those credentials rotate through the Edit GHE app dialog without reinstalling. Leave the permissions and events as the manifest created them, since editing them can fail job runs. Steps are in the GitHub Enterprise docs and the shape of the rollout is in runners for GitHub Enterprise Server and Cloud.

What the change costs

On a workload of 6,000 minutes a month at 4 vCPU:

WarpBuild rates come from the pricing page. The GitHub rate comes from the GitHub Actions billing reference, checked on 2026-08-13. The arithmetic is (0.012 - 0.008) / 0.012, which is 33 percent lower list price at the same 4 vCPU and 16 GB shape.

Related Questions

Does WarpBuild need write access to our source code?

No. The permission set a GitHub App needs to manage self-hosted runners covers read on repository Metadata, read on repository Actions, read and write on repository Administration for repository level runners, and read and write on the organization Self-hosted runners permission for organization level runners, per GitHub's permissions reference. Repository Contents sits outside that set, and actions/checkout clones with the token GitHub mints for the run, described in GitHub App.

Do we have to change the permissions block in our workflows?

No. The only edit a job needs is the runs-on value. The permissions key, the repository or organization default it falls back to, environment protection rules, and the read only token on pull requests from forks all keep behaving as documented, covered in workflow permissions.

Does OIDC to our cloud account still work?

Yes. The id-token is minted by GitHub Actions for the run, so a trust policy keyed on the repository and ref claims keeps matching. The job still needs id-token: write in its permissions block, the same requirement it had on GitHub-hosted runners.

Who can install or remove the app?

An organization owner or a repository admin, through GitHub's installation settings. Removing the installation revokes its tokens and stops runner provisioning, which is the rollback answer most reviewers ask for. Reviewers working through a formal questionnaire will want the security review material, and enterprise instances follow runners for GitHub Enterprise Server and Cloud.

Review the permission set in the runner security reference, price the move on the pricing page, and install against a single repository first to keep the blast radius small.