7.1 GitHub-Hosted Runners & Larger Runners

GitHub-Hosted Runners & Larger Runners

In GitHub Actions, the runner is the compute engine that executes the jobs defined in your workflow files. GitHub provides two primary deployment models for runner infrastructure: GitHub-hosted runners (fully managed by GitHub) and self-hosted runners (managed by your organization).

For organizations seeking zero infrastructure management overhead, GitHub-hosted runners offer instantly available, fully managed, secure virtual environments. Understanding the hardware specifications, pre-installed toolcache, lifecycle guarantees, and enterprise-grade Larger Runners is essential for optimizing build speed, controlling costs, and passing the GitHub Actions Certification (GH-200) exam.

---

1. Standard GitHub-Hosted Runner Architecture & Lifecycle

Standard Linux and Windows GitHub-hosted runners are Azure virtual machines managed entirely by GitHub; macOS runners run in GitHub's own macOS cloud. When a workflow job specifies a standard runner label (such as runs-on: ubuntu-latest), GitHub provisions a fresh virtual machine exclusively for that job. GitHub does not publish the underlying Azure VM SKU, so size your jobs from the published CPU/RAM/SSD table below rather than from an assumed instance family.

+-----------------------------------------------------------------------------+
|                 GITHUB-HOSTED RUNNER EPHEMERAL VM LIFECYCLE                 |
|                                                                             |
|   [1. Job Queued]        ─── Workflow triggers; GitHub schedules job       |
|   [2. VM Provisioning]   ─── Clean Azure VM spawned from golden image       |
|   [3. Daemon Bootstrap]  ─── Runner listener initiates outbound HTTPS poll  |
|   [4. Job Execution]     ─── Steps run with passwordless sudo / Admin privs |
|   [5. Disk Wipe & Kill]  ─── VM is permanently destroyed; state discarded   |
+-----------------------------------------------------------------------------+

Ephemeral Isolation Model

Every standard GitHub-hosted runner operates under a strict ephemeral lifecycle:

• Single-Job Longevity: A virtual machine executes exactly one workflow job. It is never reused for subsequent jobs, even within the same workflow run or repository.
• Zero Cross-Job Contamination: Residual files, modified system binaries, environment variables, downloaded dependencies, and credentials created during job execution are permanently destroyed when the VM is de-provisioned.
• Administrative Access: Jobs execute with administrative privileges (sudo without a password on Linux and macOS; full Administrator privileges on Windows), allowing workflows to install system packages, run Docker containers, and modify kernel parameters without privilege escalation barriers.
• Execution Limits: A single job can run for up to 6 hours (360 minutes). If a job exceeds this duration, GitHub Actions automatically terminates the execution.

Standard Hardware & OS Specifications

Repository visibility changes the hardware. This is a favourite exam distinction: the same runs-on: ubuntu-latest label gives you a 4-vCPU machine in a public repository and a 2-vCPU machine in a private one.

Standard runners for public repositories (free and unlimited)

Standard runners for private repositories (consume included minutes, then billed)

[!NOTE] ubuntu-slim is a container, not a VM. Single-CPU runners execute inside an unprivileged container on a shared VM, so Docker-in-Docker, filesystem mounts, and other privileged operations are unsupported. They also carry a 15-minute job timeout instead of the usual 6 hours, which makes them suitable for issue automation and other lightweight tasks rather than full builds.

Runner Image Changes: Why -latest Is a Moving Target

The January 2026 blueprint calls out runner image migration explicitly, because a -latest label silently changes the operating system underneath your jobs.

[!WARNING] The exam scenario to recognize: a workflow that has run unchanged for a year suddenly fails after GitHub repoints a -latest label. The fix is not to retry the job - it is to pin an explicit image label (ubuntu-24.04, windows-2022) while you remediate, then move forward deliberately. Preview images (ubuntu-26.04, windows-11-vs2026-arm) are excluded from the service level agreement and should never gate production.

---

2. Pre-Installed Software & The Toolcache Acceleration Model

GitHub-hosted runners are packaged with hundreds of pre-installed developer tools, compilers, CLI utilities, and SDKs. This includes Docker, git, kubectl, helm, aws-cli, azure-cli, gh, build utilities (make, cmake, gcc), and multiple versions of major programming language runtimes.

How the Local Toolcache Works

Rather than downloading language runtimes over the public internet on every workflow run, GitHub maintains a local directory called the toolcache (/opt/hostedtoolcache on Linux/macOS, C:\hostedtoolcache\windows on Windows).

When you use an official setup action, such as actions/setup-node, actions/setup-python, actions/setup-go, or actions/setup-java, the action executes the following resolution logic:

   Workflow Step: uses: actions/setup-node@v4 with: node-version: '20'
                                   │
                                   ▼
                   Does Node.js 20 exist locally in
                     /opt/hostedtoolcache/node/ ?
                                ╱     ╲
                              YES      NO
                              ╱         ╲
                             ▼           ▼
               Symlink binary to PATH    Download runtime from
               (Execution time: ~1s)     GitHub dist mirrors (~15s)

# Example: Leveraging pre-installed toolcache for instant initialization
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      # Resolves from local /opt/hostedtoolcache in < 2 seconds
      - name: Setup Node.js Runtime
        uses: actions/setup-node@v4
        with:
          node-version: '20.x'
          cache: 'npm'

      # Resolves from local /opt/hostedtoolcache in < 2 seconds
      - name: Setup Python Environment
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'
          cache: 'pip'

Toolcache vs. actions/cache

• Toolcache: Read-only, pre-baked runtime directory included directly in the runner's base OS image. Maintained by GitHub; instantly symlinks standard binaries to $GITHUB_PATH.
• actions/cache: Dynamic workflow-level caching mechanism that compresses, uploads, and downloads project-specific dependencies (such as node_modules, ~/.m2, or ~/.cache/pip) across workflow runs via GitHub's cloud cache storage.

---

3. GitHub-Hosted Larger Runners for Enterprise & Team

For enterprise workloads requiring intensive compute (such as large C++/Rust compilations, extensive test suites, mobile app builds, or AI/ML model validation), standard 4-vCPU runners can become a build-time bottleneck. Furthermore, enterprise security policies often require deterministic IP allowlisting for corporate firewalls or direct connectivity into private cloud networks.

To solve these challenges, GitHub provides Larger Runners for organizations on GitHub Team and GitHub Enterprise Cloud (GHEC).

+-----------------------------------------------------------------------------+
|                      LARGER RUNNER SCALING SPECS                            |
|                                                                             |
|   [Linux only]       ─── 2 vCPU  │ 8 GB RAM   │ 75 GB SSD                   |
|   [Small]            ─── 4 vCPU  │ 16 GB RAM  │ 150 GB SSD                  |
|   [Medium]           ─── 8 vCPU  │ 32 GB RAM  │ 300 GB SSD                  |
|   [Large]            ─── 16 vCPU │ 64 GB RAM  │ 600 GB SSD                  |
|   [X-Large]          ─── 32 vCPU │ 128 GB RAM │ 1,200 GB SSD                |
|   [2X-Large x64]     ─── 64 vCPU │ 256 GB RAM │ 2,040 GB SSD                |
|   [2X-Large arm64]   ─── 64 vCPU │ 208 GB RAM │ 2,040 GB SSD                |
|   [3X-Large]         ─── 96 vCPU │ 384 GB RAM │ 2,040 GB SSD                |
|   [GPU Accelerated]  ─── 4 vCPU  │ 28 GB RAM  │ 1x Tesla T4 (16 GB VRAM)    |
+-----------------------------------------------------------------------------+

Key Features of Larger Runners

1. Advanced Compute & Memory: Linux and Windows sizes run from 2 vCPUs / 8 GB RAM up to 96 vCPUs / 384 GB RAM, with SSD capacity up to 2,040 GB. Linux is the only platform offered at the 2-vCPU size.
2. GPU Acceleration: A single published GPU size - 4 vCPUs, 28 GB RAM, one NVIDIA Tesla T4 with 16 GB of VRAM, and 176 GB of SSD - with NVIDIA drivers preinstalled for machine-learning and rendering pipelines. Note that GPU capacity comes with modest CPU and memory, not the largest CPU tiers.
3. macOS Larger Runners: two published sizes - Large (Intel): 12 vCPUs, 30 GB RAM and XLarge (arm64/M2): 5 vCPUs with 8-core GPU acceleration, 14 GB RAM. macOS larger runners do not support Azure private networking or static IP assignment.
4. Autoscaling & Concurrency Limits: Administrators set maximum autoscaling thresholds per runner group to cap billing exposure while scaling from zero on queue demand. Up to 10 larger-runner pools can be configured with static IP address ranges.

---

4. Static IP Allowlisting & Azure VNet Private Networking

One of the primary historical drivers for managing on-premises self-hosted runners was network perimeter security: corporate firewalls, internal package registries, and staging databases could not open their ingress ports to the massive, dynamic public IP range used by standard GitHub-hosted runners.

Larger Runners eliminate this limitation through two enterprise networking capabilities:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     LARGER RUNNER NETWORKING TOPOLOGIES                     │
│                                                                             │
│  1. STATIC PUBLIC IP POOL:                                                  │
│     [Larger Runner] ──(Fixed Public IP: 20.x.x.x)──> [Corporate Firewall]   │
│                                                                             │
│  2. AZURE VNET PRIVATE INJECTION:                                           │
│     [Larger Runner] ──(Private VNet Peering/Subnet)─> [Internal DB / VPC]   │
└─────────────────────────────────────────────────────────────────────────────┘

1. Static IP Address Pools

When you assign a Larger Runner group a Static IP configuration, GitHub allocates a dedicated, contiguous range of static public IPv4 addresses for that runner group. All outbound internet traffic originating from jobs executed on these runners egresses through these fixed IPs.

• Firewall Integration: Security teams add the assigned static IP range to corporate perimeter firewalls, AWS Security Groups, or database ingress rules.
• No Bastion / VPN Maintenance: Eliminates the operational overhead of running self-hosted forward proxies or VPN gateways solely for CI/CD traffic.

2. Azure Private VNet Integration

For organizations hosting workloads in Microsoft Azure or connected hybrid clouds (via Azure ExpressRoute), Larger Runners can be injected directly into a dedicated Azure Virtual Network (VNet) subnet.

• Zero Public Exposure: The runner interfaces directly with the organization's private subnet. Outbound traffic to internal databases, internal artifact repositories (such as Artifactory or Nexus), and private APIs routes entirely over private IP space without traversing the public internet.
• Network Security Group (NSG) Governance: Network administrators enforce custom NSG rules and route tables directly on the runner subnet.

---

5. Architectural Comparison: Standard vs. Larger Runners