What is installed on ubuntu-latest: the GitHub Actions runner image

By Daniel Zoghalchali·Latchkey

What is installed on ubuntu-latest is whatever the current Ubuntu 24.04 runner image ships, because the ubuntu-latest label resolves to ubuntu-24.04 today. The versions below are from the image README read on 2026-09-20, beside the same commands run on a Latchkey runner the same day.

Two questions bring people here. The first is whether a tool is on the machine already, so a workflow can call it without a setup step. The second is which version, because a job that works on one image release breaks on the next when a major version moves under it.

Both answers change every few weeks. Treat the table below as a snapshot with a date on it, and treat the last section, printing the versions from inside your own job, as the answer that never goes stale.

What ubuntu-latest resolves to today

ubuntu-latest is a label, not an image. It currently points at ubuntu-24.04, which GitHub states in its hosted-runner reference and in the runner-images repository, where the available-images table lists the YAML labels for that image as "ubuntu-latest" or "ubuntu-24.04". Both were read on 2026-09-20.

Behind the label sits a specific build. The Ubuntu 24.04 README on the same day reported OS version 24.04.5 LTS, kernel 6.17.0-1022-azure and image version 20260907.300.1. Those rebuild continuously, which is why a job can start failing without a workflow change: the image moved, not your YAML.

The label itself moves too, and slowly. The runner-images repository says the -latest label is used for the latest OS image version that is generally available, and that the migration is gradual, over one to two months, so workflows can adapt. GitHub's own reference adds the caveat that -latest images are the latest stable images GitHub provides and might not be the most recent version the OS vendor has released.

The versions, side by side

The left column is the GitHub image README read on 2026-09-20. The right is the same tool printed by content/repro/whats-installed-on-ubuntu-latest.sh on a Latchkey latchkey-small runner the same day. They are two different images and the second column is here to make that concrete rather than to claim parity.

What is not on the image

Absent from the Ubuntu 24.04 README on 2026-09-20: pnpm, Bun, Deno and Terraform. pnpm and Bun arrive through Corepack or their own installers. Terraform is the one that catches people, because it shipped on ubuntu-22.04 and does not ship here: actions/runner-images#13876 is the tool request filed when ubuntu-latest moved to 24.04, and a workflow that expects it now needs hashicorp/setup-terraform or an explicit install step.

Present but not running: PostgreSQL 16.15 and MySQL 8.0.46 are installed and disabled at boot, so a job that needs either starts the service itself with sudo systemctl start postgresql.service or the MySQL equivalent. A service container is usually the better answer, because it pins the version.

The general rule is to install what you need rather than assume it. apt-get install in a step works for system packages, the setup-* actions are faster for language runtimes because they resolve from the toolcache, and anything heavier belongs in a container image you control.

- name: Install what the image does not ship
  run: |
    corepack enable pnpm
    sudo apt-get update && sudo apt-get install -y --no-install-recommends libgbm1
- uses: actions/setup-node@v7
  with:
    node-version: 22
    cache: npm

Print the versions from inside your own job

The only list that is true for your run is the one your run prints. Drop this step in front of the job you are debugging: it costs a second, and it turns "the image must have changed" from a theory into a line you can diff against the previous run.

- name: Image and tool versions
  run: |
    cat /etc/os-release | head -2
    echo "image: ${ImageOS:-unknown} ${ImageVersion:-unknown}"
    node --version; npm --version; python3 --version
    go version; java -version; docker --version
    docker compose version; git --version; gh --version | head -1

The same script on a Latchkey runner

A Latchkey runner is not a GitHub-hosted runner, and the point of running the same script on one is to show the difference rather than to imply there is none. The documentation describes the fleet as Ubuntu 24.04 LTS on x86_64, on AWS m6a-class hardware, with a preinstalled toolchain and a GitHub-parity toolcache at /opt/hostedtoolcache, so actions/setup-node and friends resolve instantly instead of downloading.

What that parity does not mean is identical versions. In the run below Node is 20.20.2 rather than 22.23.2, Docker is a major version ahead, and CMake is 4.4.2 against the GitHub image's 3.31.6. If your workflow depends on a default version rather than a setup-* action pinning one, that is the kind of difference that will find you.

image:           Ubuntu 24.04.4 LTS (x86_64, kernel 6.17.0-1019-aws)
node             v20.20.2
npm              10.8.2
yarn             1.22.22
python3          Python 3.12.3
pip3             pip 24.0 from /usr/lib/python3/dist-packages/pip (python 3.12)
ruby             ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux-gnu]
go               go version go1.24.13 linux/amd64
java             openjdk version "17.0.20.1" 2026-08-18
dotnet           10.0.400
php              PHP 8.3.6 (cli) (built: Jul 16 2026 18:30:41) (NTS)
docker           Docker version 29.7.2, build a7dcaa6
docker compose   Docker Compose version v5.5.0
buildx           github.com/docker/buildx v0.36.1 1d8dde89b8aba914e05e45366770736fea1fd690
git              git version 2.55.0
gh               gh version 2.98.0 (2026-08-20)
aws              aws-cli/2.36.31 Python/3.14.6 Linux/6.17.0-1019-aws exe/x86_64.ubuntu.24
gcloud           Google Cloud SDK 582.0.0
kubectl          Client Version: v0.0.0-master+$Format:%H$
gcc              gcc (Ubuntu 14.2.0-4ubuntu2~24.04.1) 14.2.0
cmake            cmake version 4.4.2
chrome           Google Chrome 152.0.7977.64 

The disk all of this is sitting on

A standard GitHub-hosted Linux runner gives the job 14 GB of SSD, with 4 vCPU and 16 GB of RAM on a public repository and 2 vCPU and 8 GB on a private one, per GitHub's hosted-runner reference read on 2026-09-20. The preinstalled toolchain in the table above is sitting in that 14 GB before your job starts.

That is why the two most common failures on this image are about space rather than software. Freeing disk space on GitHub Actions runners measures what each toolchain directory gives back, and no space left on device covers the failure itself, including the variant that reports the same error with a half-empty disk.

Key takeaways

• ubuntu-latest means ubuntu-24.04 today, and the migration to the next release takes one to two months.
• Pin runs-on: ubuntu-24.04 when a version matters; the label will move without asking.
• pnpm, Bun, Deno and Terraform are not on the image; PostgreSQL and MySQL are, but are not running.
• Print ImageOS and ImageVersion in the job so image drift is visible in the log.

Frequently asked questions

Related guides

References

• actions/runner-images: Ubuntu 24.04 image README (read 2026-09-20)
• GitHub-hosted runners: labels and standard specifications
• actions/runner-images: available images and the -latest migration
• Latchkey runner image and software
• actions/runner-images#14254: Ubuntu 22 image deprecation schedule
• GitHub Actions documentation