WarpBuild Control Plane Egress IPs for GitHub

Overview

The WarpBuild control plane makes its outbound requests to GitHub from three static IPv4 addresses: 3.13.16.127, 3.141.157.169, and 3.151.226.250. Allowlist them when a GitHub organization IP allow list or a firewall in front of a GitHub Enterprise Server instance would otherwise drop runner registration, lifecycle management, and GitHub API calls.

The published list lives in one place, the control plane egress IPs section of the GitHub Enterprise App documentation. Read that section before you write or edit a rule. The copy below was checked on 2026-08-13 and is reproduced here so a network team can see the shape of the rule, while the docs anchor stays the canonical source.

Three situations call for the rule:

• A GitHub organization on github.com with IP allow list enforcement enabled.
• A GitHub Enterprise Server instance whose ingress is restricted at a firewall or load balancer.
• GitHub Enterprise Cloud with data residency, for example acme.ghe.com, behind the same kind of restriction.

An organization with no allow list enforcement has nothing to configure. The control plane reaches GitHub over the public internet the way any other API client does, and adding the addresses changes nothing.

The rule is also narrower than teams expect on first read. It governs traffic from WarpBuild toward GitHub. Traffic from a runner toward your own registries, package mirrors, or internal services is a separate concern with a separate source address, covered in outbound traffic controls for BYOC runners.

Architecture

WarpBuild splits into a control plane that WarpBuild operates and a data plane that runs the jobs. Only the first half uses these addresses.

The control plane holds the GitHub App connection, watches the job queue, reconciles runner capacity against queued jobs, and calls the GitHub API on your behalf. Those calls originate from the three documented addresses. The data plane is the runner itself. On BYOC it is an ephemeral VM inside your own cloud account, and BYOC runs on AWS, GCP, and Azure. On WarpBuild-hosted capacity it is a VM in WarpBuild infrastructure. Either way the runner agent opens its own outbound connections and never inherits the control plane addresses.

The second and third rows are the ones that get conflated with this page. A BYOC runner in a private subnet leaves through a NAT gateway, and the AWS configuration guide states that runners with static IPs carry the NAT gateway addresses as their external IP addresses. With static IPs disabled the runners sit in public subnets. Neither shape uses a control plane address, so an allow list built for runner traffic needs your own addresses, and an allow list built for control plane traffic needs the three below.

The list does not vary by runner platform or by cloud. Every one of them registers with GitHub through the same control plane.

Configuration

The three addresses in host form, ready to paste into an allow list that expects CIDR notation:

Checked on 2026-08-13 against the documented list.

For an organization on github.com, add each entry under organization security settings, following GitHub's guide to allowed IP addresses. Give each entry a description that survives a later audit:

3.13.16.127/32    warpbuild-control-plane
3.141.157.169/32  warpbuild-control-plane
3.151.226.250/32  warpbuild-control-plane

For a GitHub Enterprise Server instance, the equivalent is an inbound allow on TCP 443 from those three /32 sources to the host, written wherever your ingress is enforced: a cloud security group, a load balancer policy, or a hardware firewall. Keep the rule in the same version-controlled repository as the rest of your network configuration and reference the docs anchor in a comment so the next reviewer can verify the list without asking anyone.

Order matters. Add the addresses before you enable allow list enforcement, and add them before you run the GitHub Enterprise setup flow, where allowlisted control plane egress IPs are listed as a prerequisite alongside enterprise owner access, the enterprise slug, and the enterprise host. Reversing that order produces a setup link that fails to generate, or an app that is created and then never registers a runner.

Nothing in a workflow file changes. Jobs keep addressing runners by label:

name: build

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

Operations

Treat the address list as a dependency with a review date rather than a one-time setup step.

The review cadence follows this page. It carries a last-verified date of 2026-08-13 and a 180 day verification cadence, so the address list is re-read against the documentation twice a year. Do the same on your side, and add an unscheduled check to two moments: before you enable allow list enforcement, and during any migration that moves your GitHub host, since both are points where a stale rule turns into queued jobs rather than a clear error.

Two facts help scope who owns the change. WarpBuild has no way to edit your allow list, so the entry is always made by your team. The security documentation carries both, alongside the compute isolation and storage controls a reviewer reads next.

None of this affects what you pay. Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, and the pricing page carries the current per-minute rates. For reference, warp-ubuntu-latest-x64-4x costs $0.008 per minute against $0.012 per minute for the 4-core Linux larger runner from GitHub at the same 4 vCPU and 16 GB shape: 33 percent lower list price, with the GitHub list price taken from the GitHub Actions billing reference and checked on 2026-08-13. BYOC adds a WarpBuild fee of $0.002 per runner minute while your own cloud account bills the compute. Signup includes $10 free credits, which is enough to register a runner and watch a first job move through the allow list before an invoice exists.

Once the rule is in place, the rest of the BYOC setup is unchanged: pick a cloud, create the stack, and point a label at it, starting from BYOC runners on AWS.

FAQ

What are the WarpBuild control plane egress IPs?

The control plane makes its outbound requests to GitHub from three static IPv4 addresses: 3.13.16.127, 3.141.157.169, and 3.151.226.250. The published list lives in the GitHub Enterprise App documentation, and that page is the canonical copy to read before you edit a rule.

Do these addresses cover runner traffic as well?

No. They cover the requests WarpBuild makes to GitHub for runner registration, lifecycle management, and GitHub API calls. A BYOC runner sits in your own cloud account and leaves through your own network path, so a rule that has to match runner traffic references your NAT gateway or subnet addresses instead.

When do I need to allowlist them?

When your organization uses a GitHub IP allow list, or when a firewall restricts inbound traffic to a GitHub Enterprise Server instance. Organizations on github.com with no allow list enabled have nothing to configure, because the control plane reaches GitHub over the public internet like any other API client.