Disk Types for BYOC Runners on GCP

A GCP BYOC runner configuration attaches one persistent disk to every Compute Engine instance it launches, and the disk type field takes one of five values: pd-balanced, pd-ssd, pd-standard, hyperdisk-balanced, and hyperdisk-extreme, with pd-balanced as the default, 100GB as the minimum size, and 150GB as the documented starting point (GCP BYOC configuration documentation, checked on 2026-08-13). Local SSD sits on a separate axis: it arrives with the machine type rather than with the disk fields, and WarpBuild mounts it at the runner work directory automatically on Linux images.

This page lists the five types with the tradeoff documented for each, the machine types that carry bundled local SSD, and a mapping from job shape to the disk that is worth paying for. The stack, service account, and quota work that comes before any of it is on BYOC runners on GCP.

Overview

Every row below comes from the GCP BYOC configuration documentation, checked on 2026-08-13.

Two mechanics separate the families, and they change how you size a runner.

On the three pd-* types, GCP manages IOPS and throughput and scales them with disk size, which Google documents on its block storage performance page. A 100GB pd-balanced volume and a 500GB pd-balanced volume are different performance objects, so the size field is a performance lever on these types even when the job never fills the disk.

On the two hyperdisk-* types, you set provisioned IOPS directly in the runner creation form, and provisioned throughput as well on hyperdisk-balanced. Performance stops tracking capacity and starts tracking what you asked for, which makes the numbers predictable and makes the regional quota a hard gate. hyperdisk-extreme has no throughput field at all, so it fits jobs bounded by random read and write operations rather than by sequential transfer.

Architecture

The disk under a BYOC runner holds one job and then goes away. WarpBuild creates a Compute Engine instance per job in your own project, the runner work directory lives on that instance, and the instance is terminated when the job finishes. Everything a job writes, including the checkout, restored dependency caches, container layers, and build output, lands on the same volume, which is why disk type shows up in job duration on pipelines that never touch the CPU limit.

Durable state sits elsewhere. The cache, the container image layer cache, and telemetry go to the Cloud Storage bucket your stack created in your project, and BYOC add-ons including cache are covered by the per-minute fee. BYOC runs on AWS, GCP, and Azure, so the same split applies on the other two clouds with their own storage products underneath.

Local SSD comes with the machine type

A runner configuration also takes one or more Compute Engine machine types in priority order. When those machine types ship bundled local SSDs, such as the c3-standard-88-lssd and c4a-standard-4-lssd families, WarpBuild detects the local NVMe devices during boot, creates a RAID-0 array when there is more than one, formats with ext4, and mounts the result at the runner work directory. The whole sequence runs in cloud-init and finishes before the job starts, and no field in the runner form switches it on (local SSD documentation, checked on 2026-08-13).

Google documents local SSD as ephemeral, with data lost when the instance stops or terminates, which costs nothing here because the runner is discarded after the job anyway. RAID-0 gives capacity and sequential throughput with no redundancy, and for a workspace that lives for one job that is the right trade. On GCP the BYOC guests are Linux, so Windows and macOS jobs keep hosted warp- labels in the same workflow file.

Configuration

Disk type and disk size are set per custom runner in the WarpBuild dashboard, alongside the machine type list and the spot setting. Nothing in the workflow file changes when you edit them, so a disk change is a runner configuration change and a rerun.

Three rules keep the configuration stable:

• Keep every machine type inside one runner configuration on the same storage shape. WarpBuild picks by availability, so a list that mixes an -lssd type with a plain type gives the same workflow local SSD on some runs and the persistent disk on others, and job duration moves with it.
• Start hyperdisk-balanced at 3,000 IOPS and 140 MiB/s, which is the documented starting configuration, then raise it against observed performance rather than against a guess.
• Set the disk size from the workspace the job writes, with 150GB as the floor. On pd-* types that size is also buying IOPS.

Match the disk type to the job shape

The workflow addresses each configuration by its Runner ID, which is the runner name prefixed with warp-custom-. Splitting a pipeline across two disk shapes is a label change:

name: ci
on:
  push:
    branches: [main]
  pull_request:

jobs:
  lint:
    runs-on: warp-custom-gcp-use-linux-4x
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint

  image:
    runs-on: warp-custom-gcp-use-hyper-16x
    steps:
      - name: Record the volume behind the workspace
        run: |
          lsblk
          df -h "${GITHUB_WORKSPACE}"
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - run: docker build -t app:${{ github.sha }} .

The lint job stays on the default disk because it never fills one. The image job runs on the hyperdisk configuration, and the two commands in the first step confirm which volume the workspace sits on before you trust any before and after comparison. Run them once per new runner configuration, then drop them.

Operations

Hyperdisk carries its own quotas. Provisioned IOPS and provisioned throughput are separate quota lines from disk capacity, both are regional, and Google documents the limits under Hyperdisk quotas. A runner configuration that asks for more provisioned IOPS than the stack region grants fails at instance creation, which surfaces as jobs that never start rather than as a disk error. Raise the quota in the stack region before you move a fleet, and raise persistent disk capacity alongside it, sized at your peak concurrent jobs multiplied by the disk size per job.

Read the change from the job itself. Hold the workflow constant, move one runner configuration to the new disk type, and compare the step durations that touch the filesystem the most: checkout, cache restore, the build step, and cache save. A pipeline that shows no movement across those four steps was never disk bound, and the extra provisioned IOPS is a line on your Google bill for nothing.

The billing split is clean. WarpBuild charges $0.002 per minute for BYOC Linux runners whatever disk type they use, and Google bills your project for the disk, the provisioned IOPS, the provisioned throughput, and the instance at your own rates (WarpBuild pricing page, checked on 2026-08-13). Price the exact disk configuration on Google's Compute Engine pricing page before you roll it out fleet-wide.

Where the disk work is more than the pipeline justifies, a WarpBuild-hosted label skips it: warp-ubuntu-latest-x64-4x (4 vCPU, 16 GB) runs at $0.008 per minute on 150GB SSD storage with no stack, quota, or disk decision at all (WarpBuild pricing page, checked on 2026-08-13). Mixed fleets are normal, and the label in runs-on is the whole switch.

For the storage question that sits next to this one, does BYOC on GCP support local SSD walks the machine type side in detail, and runners with local SSD storage covers it across all three clouds.

FAQ

Which disk type should a GCP BYOC runner start on?

pd-balanced at 150GB, which is the documented default and the documented recommended starting size. Move a runner configuration to hyperdisk-balanced at 3,000 provisioned IOPS and 140 MiB/s of provisioned throughput when the jobs on it are large builds, container image operations, or heavy test suites, then raise those two numbers against what the jobs report.

What is the minimum disk size for a GCP BYOC runner?

100GB is the documented minimum disk configuration and 150GB is the documented recommended starting point (GCP BYOC configuration documentation). Size above that against the workspace the job actually writes, since checkout, dependency caches, container layers, and build output all land on the same volume.

Does the disk type field control local SSD?

No. Local SSD arrives with the Compute Engine machine type, so an -lssd machine type carries it and the disk type field still governs the persistent disk on the same instance. WarpBuild detects the NVMe devices at boot, stripes several into a RAID-0 array, formats, and mounts them at the runner work directory on Linux images. Local SSD, defined sets out the difference between instance-attached storage and network-attached disks.