liveBook · Manning

GitHub-hosted runner

As explained in GitHub Actions in Action: Continuous integration and delivery for DevOps

A GitHub-hosted runner is a virtual machine managed by GitHub that executes workflow jobs.

A GitHub-hosted runner provides the managed runtime for a GitHub Actions job: it executes job steps, returns outcomes and logs, and can upload artifacts or cache data. GitHub maintains the operating system, runner software, and preinstalled tools, including security updates, so workflows can start without operating runner infrastructure. section 5.0 section 5.4

Select a hosted environment with a runner label such as ubuntu-latest, windows-latest, or macos-latest, or use an operating-system version label when a workflow depends on a particular version. The latest labels can change meaning; image rollouts, deprecation notices, and the exact image version are visible through runner-image information and job logs. section 5.5 section 5.4

Choose and govern hosted runners with these constraints in mind:

  • Use Linux, Windows, or macOS according to the workflow’s required shell, tools, and platform behavior; default hardware differs by operating system. section 5.16 section 5.9
  • Budget for job duration: hosted runners are billed by minutes rounded up, while Windows consumes minutes at twice the Linux rate and macOS at ten times the rate. section 5.16 section 1.4.4
  • Use larger hosted runners when CPU- or RAM-intensive jobs exceed default capacity, where available. section 5.16 section 5.9
  • Use self-hosted runners when a required hosting region or data residency cannot be met by GitHub-hosted runners. section 5.9 section 1.4.2

Private Azure connectivity

GitHub can host Linux or Windows runners inside an Azure virtual network you configure. Link a runner group to the prepared network and its inbound and outbound rules so jobs can reach private resources while GitHub continues managing the virtual machines and installed software. section 5.12

Table 5.1 Overview of supported runner operating systems (view table figure)

Operating system

Version label available

Ubuntu

ubuntu-24.04

ubuntu-22.04

ubuntu-20.04

Windows

windows-2022

windows-2019

macOS

macos-14

macos-12

macos-11

Compare the available Ubuntu, Windows, and macOS version labels before pinning a workflow to a specific hosted image. section 5.5

How GitHub Actions in Action: Continuous integration and delivery for DevOps covers it

How deep it goes
Explains image maintenance, labels, operating systems, hardware, billing, network placement, and self-hosted tradeoffs rather than runner internals.
Examples
Uses latest and version-specific operating-system labels, an Azure virtual network runner group, and job logs containing image information.
What it assumes
Assumes GitHub Actions job definitions while explaining that runners execute their steps and return workflow results.
What you can do after
Operate/configure GitHub-hosted runners by selecting labels, evaluating capacity and minute costs, and choosing self-hosted alternatives for residency needs.
How it connects
Connects GitHub Actions with self-hosted runners, runner images, runner groups, Azure virtual networks, secrets, and OpenID Connect.
Cover of GitHub Actions in Action: Continuous integration and delivery for DevOps
liveBookmanning.com
Read GitHub Actions in Action: Continuous integration and delivery for DevOps on liveBook Get the book at manning.com

Also explained in

Compare how 2 books explain GitHub-hosted runner →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of GitHub Actions in Action: Continuous integration and delivery for DevOps. The section links point to the parts of the book it draws on.