Does BYOC on GCP Support Local SSD?

Answer

Yes. GCP BYOC runners support Local SSD, and the mount is automatic: when the Compute Engine machine types on a runner configuration ship bundled Local SSDs, such as the -lssd machine types, WarpBuild detects the NVMe devices during boot, formats them, and mounts them to the runner work directory on Linux images (GCP BYOC configuration documentation, checked on 2026-08-13). No field in the runner form switches it on, so the machine type you select is the decision that produces the storage.

That splits the storage settings on a GCP runner configuration into two independent things. The disk type and size fields control the persistent disk attached to the instance, and the GCP configuration documentation lists five disk types with a 100GB minimum size and a 150GB recommended starting point. Local SSD arrives with the machine type instead, so it appears in the machine type list rather than in the disk fields.

BYOC runs on AWS, GCP, and Azure, and the automatic mount behaves the same way on all three for Linux images (local SSD documentation, checked on 2026-08-13). WarpBuild bills BYOC Linux runners at $0.002 per minute and Google bills the instance, which on an -lssd machine type already includes the Local SSD capacity in the machine type rate.

Detail

The machine type has to be one that carries the storage

Google publishes Local SSD as a property of the machine type: each Local SSD disk provides 375 GiB, and the -lssd machine types come with a predetermined number of disks that you cannot customize (Google Local SSD documentation, checked on 2026-08-13). The capacity a runner gets is therefore the disk count of the machine type multiplied by 375 GiB.

The WarpBuild configuration documentation names the c3-standard-88-lssd and c4a-standard-4-lssd families as examples of what to select. Disk counts differ per machine type, so check the exact count for the type you plan to run in Google's table before you size the work directory against it.

One selection detail catches teams out. A runner configuration takes one or more machine types in priority order, and WarpBuild picks by availability, so a shortfall on the first type falls through to the second instead of leaving the job queued. If the first type is an -lssd type and the fallback is not, the same workflow gets Local SSD on some runs and the persistent disk on others, and job duration moves with it. Keep every machine type inside one runner configuration on the same storage shape, and give the mixed shapes their own runner configuration and their own warp-custom- label.

What the runner does at boot

The sequence runs during cloud-init and finishes before any job starts: detect every local NVMe device, create a RAID-0 array if there is more than one, format the device or the array with ext4, and mount it at the runner work directory such as /home/runner/work. For BYOC custom images, mdadm is installed automatically when it is missing, which covers Ubuntu, Amazon Linux, and other common distributions.

The Linux restriction matters on GCP for a second reason: GCP BYOC runners are Linux Compute Engine instances, and snapshot runners are not available on BYOC GCP (GCP BYOC configuration documentation). Windows and macOS jobs stay on hosted warp- labels in the same workflow file and get their regular volumes there.

Local SSD is ephemeral on both sides

Google states that all data on a Local SSD may be lost if the instance stops or is terminated for any reason. WarpBuild runners are ephemeral anyway, so the runner terminating after the job takes the disk with it. Nothing changes about where durable state lives: caches and artifacts go to the Cloud Storage bucket your stack created in your own project, and BYOC add-ons including cache are covered by the per-minute fee.

RAID-0 gives throughput and capacity with no redundancy. For a build workspace that is discarded at the end of the job, that is the right trade, and it is the reason the runner stripes rather than mirrors.

The workloads that gain the most

Local SSD pays off where a job spends real time waiting on the filesystem rather than on the CPU:

• Large checkouts. A full-history clone of a monorepo writes hundreds of thousands of small files, and actions/checkout with fetch-depth: 0 is one of the heaviest I/O steps in a typical pipeline.
• Cache-heavy builds. Restoring a large dependency cache, unpacking node_modules or a Gradle cache, and writing it back at the end are all extract-and-write workloads.
• Container image work. Layer unpack and image build write and delete large trees quickly.
• Test suites that restore a database dump or a fixture set before every run.

A workflow that lands on such a runner needs no special steps, and two commands confirm the mount on the first run:

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

jobs:
  build:
    runs-on: warp-custom-gcp-use-lssd-16x
    steps:
      - name: Confirm the work directory is on the local NVMe array
        run: |
          lsblk
          df -h "${GITHUB_WORKSPACE}"

      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

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

      - run: npm ci
      - run: npm test

lsblk shows the NVMe devices and the md array when several were striped, and df -h on the workspace shows which volume the work directory actually sits on. Run both once when you create the runner configuration, then drop them.

When no -lssd machine type is available in your stack region, or the quota conversation is going to take a while, hyperdisk-balanced is the other lever: it takes provisioned IOPS from 3,000 to 160,000 and provisioned throughput from 140 to 2,400 MiB/s, set in the runner creation form. Disk types for BYOC runners on GCP compares the five options and the quota lines each one needs, and BYOC runners on GCP covers the stack, service account, and quota work that comes before either choice.

Related Questions

Do I have to configure anything to use Local SSD on a GCP BYOC runner?

No. If the machine type carries bundled Local SSDs, the runner detects the NVMe devices at boot, formats them, and mounts them to the work directory before the job starts. A single device is mounted directly and several are combined into a RAID-0 array first (local SSD documentation). The only choice you make is the machine type, which runners with local SSD storage covers across all three clouds.

What happens if only some machine types in my fallback list have Local SSD?

The job takes whichever type was available that morning, so it lands on Local SSD some runs and on the persistent disk on others, and duration moves with it. Keep every machine type inside one runner configuration on the same storage shape, and split the mixed shapes into separate runner configurations with separate warp-custom- labels. The GCP BYOC configuration documentation covers the priority order and the fallback behavior.

Does data on a Local SSD survive the job?

No. Google documents Local SSD as ephemeral storage whose data may be lost whenever the instance stops or terminates (Google Local SSD documentation, checked on 2026-08-13), and WarpBuild runners terminate after the job. Caches and artifacts belong in the Cloud Storage bucket your stack created, which the $0.002 per minute BYOC fee already covers. Local SSD, defined sets out the difference between instance-attached storage and network-attached disks, and the pricing page has the rest of the rate card, checked on 2026-08-13.