Runners for GitHub Enterprise Server and Cloud

WarpBuild supports GitHub Enterprise Server and GitHub Enterprise Cloud with data residency on the enterprise plan, through a GitHub App that you register on your own enterprise and then connect to WarpBuild. The app is registered once at the enterprise level and shared across the organizations inside that enterprise, so the second organization to connect runs the install step and nothing else.

This page covers which GitHub deployments need the flow, how the shared app model works, what to gather before you start, the setup steps in the order the dialog asks for them, and how to rotate credentials later without reinstalling the app.

Answer

Three GitHub deployment shapes show up in enterprise runner conversations, and they take different paths.

For the first two rows, WarpBuild cannot use the shared default app, because that app lives on github.com and your enterprise does not. You register a GitHub App on your own enterprise instead. WarpBuild supplies the manifest, so GitHub prefills the app name, webhook URL, callback URL, permissions, and events when you confirm the creation page. Your enterprise owns the resulting app, its credentials, and its installation scope.

For the third row, the enterprise app flow stays available for teams who want their own app rather than the shared one, and the quick start path remains the shorter option.

Two things stay the same across all three rows. The runner labels do not change: a job that runs on warp-ubuntu-latest-x64-4x today keeps the same runs-on value after the enterprise connection. The runner images do not change either, so the preinstalled toolchain your jobs expect behaves the same way on an enterprise-connected organization as it does on a github.com organization.

GitHub Enterprise support is an enterprise plan feature and the setup runs alongside a call with the WarpBuild team, which is where the plan, the host details, and any network constraints get sorted out in one pass. Schedule a call to start that process, and read the GitHub Enterprise App documentation for the screen-by-screen version of the flow below.

How It Works

The app is registered once per enterprise

The app is created at the enterprise level and shared across every organization in that enterprise. The sequence looks like this.

1. The first organization from your enterprise, say acme, opens the setup dialog, enters the enterprise slug and host, creates the app on your enterprise, and installs it on that organization.
2. A later organization from the same acme enterprise enters the same enterprise slug and host. WarpBuild detects the existing app and shows an existing-app notice in the dialog. No second app is created.
3. That organization runs the install step against its own repositories and lands back in WarpBuild with the integration marked Connected.

The app creation and credential steps happen once per enterprise. Every organization after the first is an install, which takes a minute and needs admin rights on the target organization rather than enterprise owner access.

This matters for planning because the two roles are usually different people. An enterprise owner is needed once, at the beginning. Organization admins handle everything after that, and they do not need to re-enter credentials or generate new keys.

What the app is used for

The WarpBuild control plane uses the app to register runners with GitHub, manage runner lifecycle, and make GitHub API calls on your behalf. Those outbound requests leave from three static IP addresses, which is why an enterprise with an IP allow list has to add them before the connection works.

The permissions and events on the app come from the manifest. Leave them as created. Editing them after the fact can cause job runs to fail in ways that are hard to trace back to the change, because the failure shows up as a runner that never registers rather than as a permissions error.

The isolation model underneath is the same one every WarpBuild runner uses, and it is documented on the runner security page. Each runner runs in its own virtual machine, created on demand and destroyed after each build. Each runner gets its own encrypted storage volume with the same lifetime. WarpBuild does not access or store build secrets; secrets stay in your repository and are reachable only from the runner environment while the job runs.

What the connected organizations can run

Once an organization is connected, it gets the full runner catalog. Rates below come from the WarpBuild pricing page, checked on 2026-08-13.

Placement options are unchanged by the enterprise connection. US and EU are the regions WarpBuild names for hosted runners. BYOC runs on AWS, GCP, and Azure, so an enterprise that needs runner instances inside its own cloud account can point a GHES organization at BYOC runners the same way it would on github.com. Terraform support exists for BYOC on AWS, which keeps the runner definitions in the same review path as the rest of your infrastructure code.

Prerequisites

Gather five things before opening the setup dialog.

1. Enterprise owner access to your GHE instance. Registering an enterprise-level app requires it, and no lower role can substitute.
2. Your enterprise slug, which is the path segment in https://<host>/enterprises/<slug>.
3. Your enterprise host, for example acme.ghe.com for GitHub Enterprise Cloud with data residency or github.acme.com for GitHub Enterprise Server.
4. A WarpBuild account on the enterprise plan.
5. Allowlisted control plane egress IPs, if your enterprise uses a GitHub IP allow list or restricts inbound traffic to a GitHub Enterprise Server instance.

The control plane egress IPs are static and documented:

3.13.16.127
3.141.157.169
3.151.226.250

Add these to your GitHub IP allow list or to the inbound rules in front of your GHES instance. You add them; WarpBuild has no way to edit your allow list. Teams that skip this step usually see the setup link fail to generate or the app create successfully and then never register a runner, because the control plane request to your host is dropped at the network edge rather than rejected by GitHub.

Two more items are worth confirming in the same sitting. WarpBuild has to be able to reach your enterprise host over the network, which is the common blocker for GHES instances behind a corporate VPN with no public ingress. And the organization you plan to install against needs an admin who can approve the installation and pick the repositories it covers.

Setup

The dialog lives in the WarpBuild dashboard under Settings, then Account. Under Products, then Runners, click the chevron next to Setup Runners and choose Setup for GHE. The GitHub Enterprise App documentation carries the same steps with screenshots.

1. Enter your enterprise details. Fill in the enterprise slug and the host. The host auto-fills as <slug>.ghe.com, so edit it for GHES, for example to github.acme.com. If no app exists for the host, the form expands with credential fields. If one exists already, the dialog shows the existing-app notice and you skip ahead to the install step.
2. Create the GitHub App on your enterprise. Click the link in the dialog. GitHub opens the app creation page on your enterprise with the manifest applied, covering the name, webhook URL, callback URL, permissions, and events. Confirm to create it. GitHub then shows the new app's settings page. Keep that tab open.
3. Copy the credentials back into WarpBuild. Six values move from the GitHub tab to the WarpBuild form.
4. Install the app on your organization. Click Setup runners. WarpBuild saves the app and redirects you to the GHE install flow, where you pick the organization, choose repositories, and confirm.
5. Point a workflow at a runner label. You land back in WarpBuild with the integration marked Connected, and the Configure Runners button deep-links to the app's installation settings on your enterprise host for adjusting repository access later.

The six credentials in step 3, and where each one comes from:

After the install, workflows in the connected organization use the standard labels:

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

jobs:
  unit-tests:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

  arm-packages:
    runs-on: warp-ubuntu-latest-arm64-8x
    steps:
      - uses: actions/checkout@v4
      - run: make package ARCH=arm64

  windows-integration:
    runs-on: warp-windows-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/integration.ps1

  ios-build:
    runs-on: warp-macos-26-arm64-6x
    steps:
      - uses: actions/checkout@v4
      - run: xcodebuild -scheme App -destination 'generic/platform=iOS' build

Rotating credentials

Three of the six values rotate on a schedule in most enterprises: the client secret, the webhook secret, and the private key. All three rotate without reinstalling the app.

On the Products page, click Edit GHE app next to the Runners integration. Generate fresh credentials on the GitHub App settings page, using the Edit GitHub App link in the dialog to jump straight there. Paste the new values into the dialog and click Update app. Fields left blank keep their existing value, so a private key rotation does not force you to re-enter the client secret. The app installation on each organization survives the rotation, and repository access stays as configured.

Leave the permissions and events alone during any rotation. The manifest set them, and the app depends on them staying as created.

When something fails

Three failures cover most cases. A message about the setup link failing to generate points at a wrong slug or host, or at a host WarpBuild cannot reach. An app that creates but fails to install is usually an org-level app where an enterprise-level one is needed, or an account without admin rights on the target organization. Missing webhook deliveries mean the webhook secret in WarpBuild differs from the one on the app, which the Edit GHE app dialog fixes in one step.

Cost and rollout

Start with one organization and one real pipeline. Per-minute rates for every size are on the pricing page.

Two enterprise line items are worth knowing during the same conversation. SSO is available for a flat $250 per month, whatever the user count, which keeps the number stable as more organizations from the enterprise connect.

For adjacent enterprise questions, SSO for GitHub Actions runner access covers identity, US data residency for GitHub Actions runners covers placement, and the security review checklist collects the answers a reviewer asks for. Teams that want runners inside their own account can start with running GitHub Actions runners in your own AWS account.

FAQ

Which GitHub Enterprise deployments does WarpBuild support?

GitHub Enterprise Server (self-hosted, for example github.acme.com) and GitHub Enterprise Cloud with data residency (for example acme.ghe.com), on the enterprise plan, through a GitHub App you register on your own enterprise. For enterprise accounts on github.com the same flow is available and optional.

Do we register a separate GitHub App for each organization?

No. The app is registered once at the enterprise level and shared across the organizations in that enterprise. A second organization enters the same enterprise slug and host, WarpBuild detects the existing app, and that organization runs the install step only.

What do we need before starting the setup?

Enterprise owner access to the GHE instance, your enterprise slug, your enterprise host, a WarpBuild account, and, if your enterprise uses an IP allow list, the three documented control plane egress IPs added to that list.

Can we rotate the app credentials later?

Yes. The client secret, webhook secret, and private key rotate through the Edit GHE app dialog without reinstalling the app, and fields left blank keep their existing value. Leave the app permissions and events as the manifest created them.