Ubuntu Versions on Linux x64 GitHub Actions Runners

WarpBuild runs three Ubuntu lines on its Linux x64 GitHub Actions runners, 22.04, 24.04, and 26.04, and every line is available in all five machine sizes from 2 to 32 vCPU. The warp-ubuntu-latest-x64-<size> labels resolve to Ubuntu 24.04 today, while the dated warp-ubuntu-2204-x64-<size> and warp-ubuntu-2604-x64-<size> labels hold a version in place when that default moves.

This page lists all 15 Linux x64 labels grouped by Ubuntu line, explains what the latest selector tracks and when pinning is the safer choice, prices two sizes against GitHub's published list prices for the same shape, and gives the checklist for moving a job from one Ubuntu line to another. Catalog rows, image versions, and rates were checked on 2026-08-13.

Catalog

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners. On Linux x64, one set of five machine shapes is published across three Ubuntu lines, so a label selects an Ubuntu version and a size independently.

Source: WarpBuild cloud runners documentation, checked on 2026-08-13. Every row carries 150GB SSD regardless of Ubuntu line or size, memory scales at 4GB per vCPU, and runner storage is ephemeral and is deleted when the runner terminates.

What the latest selector resolves to

Each Ubuntu 24.04 label has a dated twin. warp-ubuntu-latest-x64-8x and warp-ubuntu-2404-x64-8x schedule the same machine, and the same pairing holds at 2x, 4x, 16x, and 32x. The Ubuntu 26.04 and Ubuntu 22.04 labels carry no alias, because a dated label already names its version exactly.

The latest selector follows GitHub's default for ubuntu-latest rather than moving to the newest published Ubuntu on its own. The WarpBuild changelog recorded that behavior when Ubuntu 24.04 first shipped: the warp-ubuntu-latest-x64-<size> labels continued to point at Ubuntu 22.04 until GitHub changed the default runner version for ubuntu-latest. That pointer has since moved to Ubuntu 24.04, which is the practical reason to treat latest as a value that changes under a workflow rather than a fixed target.

Why release jobs pin a version

A pull request lane on latest is usually the right default, because it keeps the fleet aligned with the GitHub-hosted baseline your contributors already assume. A release lane is a different job. Anything that signs an artifact, links against system libraries, or produces a binary you support for months should name warp-ubuntu-2404-x64-<size> or warp-ubuntu-2604-x64-<size> directly, so the Ubuntu version that produced the artifact is readable from the workflow file and survives a default switch that lands without a code change.

Image versions and update cadence

Each Ubuntu line is rebuilt from the upstream GitHub runner image releases, and every rebuild is recorded in the WarpBuild changelog. The August 12, 2026 entry lists ubuntu22/20260810.260 for Ubuntu 22.04, ubuntu24/20260810.271 for Ubuntu 24.04, and ubuntu26/20260810.99 for Ubuntu 26.04.

Those strings are the unit to quote in a bug report. A job that passed last week and fails today on an unchanged label usually crossed one of those rebuilds, which turns the question into a diff between two published image manifests instead of an argument about whether Ubuntu changed.

Pricing

The per-minute rate on a Linux x64 runner depends only on the machine shape. Ubuntu 22.04, 24.04, and 26.04 cost the same at every size, so choosing an Ubuntu line is a compatibility decision with no effect on the bill.

GitHub list prices come from the GitHub Actions minute multipliers reference and the shapes from the GitHub-hosted runners reference, both checked on 2026-08-13. Each row pairs a WarpBuild size with the GitHub shape that has the same vCPU count and the same memory, so the comparison is rate against rate at equal hardware. Rates for every size and platform are listed on the WarpBuild pricing page.

Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, so keeping a second Ubuntu line alive as a validation lane costs the minutes it runs and nothing else. Signup includes $10 free credits, which covers 1,250 minutes on the 4 vCPU shape at $0.008 per minute.

Worked model: a nightly three-line matrix

The cheapest way to know whether your repository already builds on the next Ubuntu line is one scheduled matrix across all three. At 14 minutes per leg on the 8 vCPU shape at $0.016 per minute:

• Per night: 3 legs x 14 minutes = 42 minutes, and 42 x $0.016 = $0.672
• Per 30-day month: 30 x $0.672 = $20.16

That buys a daily signal on Ubuntu 22.04, 24.04, and 26.04, and it catches an image rebuild that breaks a build within a day of the rebuild shipping.

Worked model: a pinned release lane

Take 40 release runs per month at 20 minutes each on a pinned warp-ubuntu-2404-x64-16x:

• Minutes per month: 40 x 20 = 800
• At $0.032 per minute: 800 x $0.032 = $25.60
• On the 16-core GitHub-hosted Linux larger runner at $0.042 per minute: 800 x $0.042 = $33.60
• Monthly difference at identical shape and identical minutes: $8.00

Substitute your own release cadence and job duration; the structure holds.

Configuration

Selecting an Ubuntu version is one string in runs-on. This job pins Ubuntu 24.04 at 16 vCPU and records the toolchain that produced the artifact:

name: release

on:
  push:
    tags: ["v*"]

jobs:
  build:
    runs-on: warp-ubuntu-2404-x64-16x
    steps:
      - uses: actions/checkout@v4

      - name: Record the image baseline
        run: |
          . /etc/os-release && echo "$PRETTY_NAME"
          ldd --version | head -1
          gcc --version | head -1

      - uses: actions/setup-node@v4
        with:
          node-version: "22"

      - name: Cache the package store
        uses: actions/cache@v4
        with:
          path: ~/.npm
          key: npm-${{ env.UBUNTU_LINE }}-${{ hashFiles('**/package-lock.json') }}
        env:
          UBUNTU_LINE: ubuntu-2404

      - run: npm ci
      - run: npm run build

The baseline step is worth keeping permanently. It writes the Ubuntu release, the C library version, and the compiler version into the job log, so every archived run records the image that produced its artifacts.

Keep the Ubuntu line in the cache key

runner.os evaluates to Linux on all three Ubuntu lines, so a cache key built from runner.os alone lets a 22.04 job restore an entry written by a 26.04 job. Compiled dependencies and native modules restored across that boundary fail at link time or at import time, often several steps later. Put the Ubuntu line into the key directly, as the UBUNTU_LINE value above does, and the two lines keep separate entries.

Validate a move before you make it

A scheduled matrix runs the candidate lines beside the current one and gives you the evidence for the move without touching the pull request lane:

name: ubuntu-line-compat

on:
  schedule:
    - cron: "0 5 * * *"
  workflow_dispatch:

jobs:
  compat:
    strategy:
      fail-fast: false
      matrix:
        image:
          - warp-ubuntu-2204-x64-8x
          - warp-ubuntu-2404-x64-8x
          - warp-ubuntu-2604-x64-8x
    runs-on: ${{ matrix.image }}
    steps:
      - uses: actions/checkout@v4
      - name: Toolchain defaults on this image
        run: |
          . /etc/os-release && echo "$PRETTY_NAME"
          python3 --version
          node --version
          go version || true
          java -version 2>&1 | head -1
          openssl version
      - run: make test

fail-fast: false keeps the other legs running when one image fails, which is the point of the matrix.

Migration checklist between Ubuntu lines

Work through these in order before switching a lane:

1. Diff the published software lists. Each line has its own inventory: Ubuntu 22.04, Ubuntu 24.04, and Ubuntu 26.04. The preinstalled software documentation states that the tooling on each WarpBuild Ubuntu x86-64 image is the same as the GitHub-hosted runner for that Ubuntu version, so the upstream document is the accurate diff. Preinstalled software on WarpBuild runner images maps the lists to the labels.
2. Print the toolchain defaults on both lines. The compat matrix above does this. Default python3, java, and gcc versions move with the Ubuntu release, and a step that relied on the image default rather than a setup-* action is where the first failure usually appears.
3. Pin the language runtimes you care about. Replace a bare python3 or node with actions/setup-python or actions/setup-node at an explicit version. That removes the Ubuntu line as a variable for everything except compiled dependencies.
4. Check the system libraries you link against. Compare ldd --version, openssl version, and the specific dpkg -l entries your build needs. Anything compiled on one line and cached for another has to be rebuilt.
5. Split the caches. Any key using runner.os alone needs the Ubuntu line added, as above.
6. Reinstall rather than assume for apt packages. A package present by default on one line may need an explicit apt-get install on another; make the install step unconditional so it works on all three.
7. Run the candidate line on a schedule for a week before moving the pull request lane, then move the release lane last.

If the checklist ends with a dependency the stock image cannot carry, building a custom runner image for GitHub Actions covers baking it in instead of installing it on every run.

Where to go next

• Linux x64 runners for GitHub Actions, sizes and pricing covers the full x64 fleet, its shapes, and its dynamic label modifiers.
• Preinstalled software on WarpBuild runner images lists what ships on each image.
• What operating systems can GitHub Actions run covers the platform choice above the Ubuntu choice.
• The cloud runners documentation is the source of record for every label above.

FAQ

Which Ubuntu versions run on WarpBuild Linux x64 GitHub Actions runners?

Ubuntu 24.04, Ubuntu 26.04, and Ubuntu 22.04, each in all five sizes: 2, 4, 8, 16, and 32 vCPU. That is 15 Linux x64 labels in total, all on 150GB SSD, and the rate depends on the size rather than the Ubuntu version.

What does warp-ubuntu-latest-x64-8x resolve to?

Ubuntu 24.04 with 8 vCPU and 32GB of memory. Its explicit alias is warp-ubuntu-2404-x64-8x, and both labels schedule the same machine. The latest selector follows GitHub's default for ubuntu-latest, so it has moved before and will move again.

Should release jobs use a latest label or a dated label?

Use a dated label such as warp-ubuntu-2404-x64-16x or warp-ubuntu-2604-x64-16x on any job that signs, publishes, or produces a binary you support. The dated label keeps the Ubuntu version fixed through an upstream default switch, so a release artifact stays reproducible from the workflow file alone.