Spot Instances for GitHub Actions Runners

Spot instances give GitHub Actions runners interruptible cloud capacity at a discount, and on WarpBuild they come from BYOC runners that launch inside your own cloud account. BYOC runners cost $0.002 per minute in WarpBuild fees and the compute is billed by your own cloud account, where AWS states Spot Instances run at up to a 90 percent discount compared to On-Demand prices (AWS EC2 Spot Instances, checked on 2026-08-13).

One availability fact decides how this page applies to you. BYOC runs on AWS, GCP, and Azure, and spot capacity lives there. Cloud spot runners were removed from WarpBuild Cloud on June 8, 2026, so every *-spot label on the hosted fleet is gone; the cloud runners catalog records the removal, and the BYOC documentation is the path forward.

Diagnosis

Spot capacity is cloud capacity your provider can take back. When it does, the instance stops, the GitHub Actions runner agent stops answering, and the job that was running on it fails. Nothing resumes: the job restarts from its first step on a fresh instance, and any minutes already burned are still billed by your cloud account. That single behavior decides which jobs belong on spot and which do not.

Start by sizing the eligible slice rather than flipping a switch on every runner set. The Reports page breaks WarpBuild billing down to the individual job with repository, runner label, execution time, billed time, and cost, and filters by repository, runner label, stack, and job name. Sort by cost, then walk the top rows against the table below. Teams usually find that a small number of job names carry most of the minutes, and that those jobs split cleanly into retry-safe and side-effecting.

Two constraints narrow the list further. Spot instances are not supported for standby disks, so a runner set cannot have both a warm pool and spot pricing; the standby disks documentation states the reason plainly, which is that a reclaimed instance cannot guarantee a pre-initialized VM is waiting. And spot capacity applies to the platforms BYOC covers: Linux runner sets on AWS, GCP, and Azure, and Windows runner sets on AWS and Azure. The macOS fleet is hosted, so macOS jobs stay on hosted labels and are priced from the pricing page.

The last diagnostic is queue behavior. Spot availability varies by instance type, region, and availability zone, and a runner set pinned to one instance type will park jobs in the queue when that type runs dry. Availability, rather than price, is what usually goes wrong first.

Fix

Work the change in five steps, and keep the spot and on-demand paths as separate runner sets so a rollback is a label edit rather than a reconfiguration.

1. Connect the cloud account and create a stack. BYOC setup is three moves: connect the cloud account so WarpBuild gets an IAM role or service account, create a stack that pins a region, VPC, and object storage bucket, then create custom runners against that stack. The BYOC documentation covers all three, and the AWS configuration guide covers the AWS specifics, including the spot permissions the IAM role carries: ec2:RequestSpotInstances, ec2:CancelSpotInstanceRequests, ec2:DescribeSpotInstanceRequests, ec2:DescribeSpotPriceHistory, and the service-linked role for EC2 Spot. Architecture and IAM detail for the AWS path live on the AWS BYOC page.

2. Create two runner sets, not one. Build a spot runner set for the retry-safe classes in the table and an on-demand runner set at the same instance size for everything else. The workflow chooses between them with the runs-on label, so moving a job back to on-demand after a bad week is a one-line diff.

3. Give the spot set a long fallback instance type list. A runner set accepts several instance types in priority order, and WarpBuild picks an available one at launch time based on availability and price. This is the single most useful spot setting, because a queued job that cannot find capacity costs more than a job that pays on-demand rates. Choose types close in price and performance so job duration stays predictable, for example m7a.xlarge alongside m7i.xlarge.

4. Spread subnets across availability zones. The AWS configuration guide recommends three public and three private subnets in different availability zones, with at least 250 IPs per subnet. Zonal spread widens the pool your fallback list can draw from, which is what turns a longer instance type list into real capacity.

5. Make retries cheap. Shard long suites so an interrupted job loses one shard, and set fail-fast: false on matrix jobs so a reclaimed instance does not cancel the siblings that were about to pass. Watch the success rate and duration percentiles in the Jobs section of the Reports page after the switch; if the interrupted share is high enough to stretch merge times, shorten the jobs before widening the spot footprint.

Standby disks stay on the on-demand set. Snapshot runners, remote Docker builders, CI observability, the MCP server, and the Action Debugger are the wider WarpBuild surface, and every one of them is reachable through the API, so the runner set changes above can be scripted rather than clicked.

Scale is the last thing to check before widening. Run as many jobs as your workflows need. Generally available Linux and Windows runners do not have plan-level concurrency caps. On BYOC the ceiling that actually bites is your own cloud quota for vCPUs, IPs, and volumes in the stack region, and a spot fleet reaches it sooner than an on-demand one because retries add launches.

Configuration

A BYOC runner is addressed by its Runner ID, which is the runner name with the warp-custom- prefix. The two-set pattern reads like this:

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

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  unit-tests:
    runs-on: warp-custom-linux-8x-spot
    strategy:
      fail-fast: false
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v4
      - run: make test SHARD=${{ matrix.shard }}

  publish:
    needs: unit-tests
    if: github.ref == 'refs/heads/main'
    runs-on: warp-custom-linux-8x-ondemand
    steps:
      - uses: actions/checkout@v4
      - run: make publish

The sharded test job runs on spot with fail-fast: false, so a reclaimed instance costs one shard and a re-run of that shard. The publish job runs on the on-demand set because a partial publish is expensive to clean up. Both labels point at runner sets in the same stack, so they share the region, VPC, and cache bucket.

The runner set settings that matter on spot, from the AWS configuration guide:

Two more configuration notes. Static IPs place runners in private subnets and add data transfer charges to your cloud bill, so enable them only for the runner sets that need a fixed egress address, and keep the spot set without them where your network policy allows. Terraform support exists for BYOC on AWS, so the two runner sets, their instance type lists, and their disk settings can live in the same module as the rest of your AWS infrastructure and be reviewed in a pull request.

Cost or Time Model

The WarpBuild half of a BYOC bill is a flat per-minute fee that does not change with the instance purchase option. The compute half is your own cloud bill, and that is the half spot moves. Rates below come from the pricing page, checked on 2026-08-13.

Take a fleet of 200,000 Linux runner minutes per month on an 8 vCPU shape. The WarpBuild fee is 200,000 x $0.002 = $400 per month, and it stays $400 whether every instance is on-demand or every instance is spot. On top of that sits your cloud bill for the instances, volumes, and data transfer those jobs consumed. AWS states Spot Instances run at up to a 90 percent discount compared to On-Demand prices (AWS EC2 Spot Instances, checked on 2026-08-13), and that published ceiling is what the compute half moves against. The realized figure depends on your instance mix, your region, your zonal spread, and any committed-use discounts you already hold, so model it against a real month of workflow minutes before migrating.

Interruptions push the other way, and the arithmetic is worth doing before the switch. Suppose the spot set carries 120,000 of those 200,000 minutes, average job length is 6 minutes, and reclaimed jobs are lost halfway through on average. An interrupted job bills the 3 minutes it burned plus a full 6-minute retry, so it costs 9 minutes where a clean run costs 6: half a job extra each time. At a 5 percent interruption rate the spot slice adds 0.05 x 120,000 x 0.5 = 3,000 minutes, which is $6 in WarpBuild fees plus the matching compute in your cloud account. At 15 percent it adds 9,000 minutes. The break-even point is the interruption rate at which those added minutes cost more than the spot discount returns, and a long fallback instance type list plus zonal spread is what keeps you below it.

Compare that against staying on the hosted fleet. The same 200,000 minutes on warp-ubuntu-latest-x64-8x bill 200,000 x $0.016 = $3,200 per month with no cloud bill attached, no capacity planning, and no interruption handling. BYOC with spot trades that simplicity for a lower compute rate you manage yourself. Teams with an existing cloud footprint, committed-use discounts, and an operations team usually come out ahead; teams without one usually do not.

Treat a provider's advertised spot discount as an instance-price ceiling, not a prediction of total CI savings. Model interruptions, job duration, cloud rates, and the WarpBuild fees on the pricing page together.

Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, and signup includes $10 free credits, which is enough to run a spot runner set against a real workflow before committing to the migration. The choice between the two routes is worked through in more depth in hosted runners compared with BYOC runners, and the capacity side, including the cloud quotas a spot fleet hits first, is covered in BYOC capacity planning and cloud quotas.

FAQ

Can I still use the WarpBuild Cloud spot runner labels?

No. All *-spot runner labels on WarpBuild Cloud were removed on June 8, 2026. Spot capacity now comes from BYOC runners on AWS, GCP, or Azure, where the instances launch in your own cloud account.

What happens to a GitHub Actions job when the cloud reclaims a spot instance?

The runner disappears mid-job and GitHub Actions marks that job failed, so the work has to run again. WarpBuild launches a replacement instance from your runner set's ordered instance type list, which is why a longer fallback list matters on spot.

Can spot runners use standby disks?

No. Spot instances are not supported for standby disks, because a reclaimed instance breaks the guarantee that a pre-initialized VM is waiting. Keep standby disk pools on an on-demand runner set and give the spot set a pool size of zero.

What does WarpBuild charge for spot BYOC runners?

BYOC runners cost $0.002 per runner minute in WarpBuild fees on both Linux and Windows, and your cloud account is billed for the compute at whatever spot rate it pays. Pricing is purely usage based, with no base subscription fee, no platform fee, and no seat fee.