A Cost Model for BYOC Runners

A BYOC cost model has exactly two lines: WarpBuild charges $0.002 per runner minute for BYOC GitHub Actions runners, and every instance hour, volume, byte of object storage, and gigabyte of data transfer those runners consume is billed by your own cloud account at your account's rates (pricing page and BYOC documentation, checked on 2026-08-13). Modeling BYOC means fixing the first line with one multiplication and estimating the second one from the runner set configuration you choose.

This page gives the two-line model, the configuration decisions that create each cloud line, a worked month with every assumption stated, and the numbers to re-check once real invoices arrive.

Overview

The first line is arithmetic. Runner minutes multiplied by $0.002 is the entire WarpBuild invoice for BYOC. Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, so a second runner set, a second stack, or a tenth engineer changes nothing except minutes consumed.

BYOC runs on AWS, GCP, and Azure. The macOS fleet is hosted rather than BYOC, so macOS jobs price from the per-minute rates on the pricing page instead of from the two-line model here.

Signup includes $10 free credits, which is 5,000 BYOC runner minutes of WarpBuild fees. That is enough to run a real week of workflows and read both counters before committing a fleet.

Architecture

Every cloud line traces back to a decision made when the stack or the runner set was created, which is why the model is worth building before the stack rather than after the first invoice.

Three of those deserve their own note.

Disk configuration has a floor. The AWS configuration guide puts the minimum at 100GB, 125MBps, and 3000 IOPS, and recommends 150GB, 400MBps, and 4000 IOPS. Provisioned IOPS and throughput above the baseline bill separately from capacity on most providers, so a runner set tuned for a heavy build carries a volume charge that a light one does not.

Object storage is a retention question. The stack's bucket holds artifact cache, container layer cache, runner logs, and other workflow artifacts, and the same guide recommends a 7-day lifecycle policy. Retention is the largest single lever on that line, because GitHub Actions cache entries churn quickly.

Data transfer depends on one toggle. With static IPs disabled, runner instances sit in public subnets, and the BYOC documentation notes that this path avoids ingress transfer charges and usually leaves minimal egress for GitHub Actions workloads. Enabling static IPs moves runners into private subnets behind a NAT gateway, which adds gateway data processing on traffic in both directions plus any inter-region transfer; the documentation puts outbound transfer from a runner to the internet at around $0.45 per GB on AWS and recommends using static IPs sparingly. Two configuration steps cut the same line further: an S3 gateway endpoint on the VPC so cache traffic reaches the bucket without transfer charges, and the ECR VPC endpoints that WarpBuild configures automatically.

Configuration

Here is a full month with every input stated. Substitute your own rates and shape; the structure is what carries over.

The spot assumption sits inside a published range rather than above it. 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). That ceiling is an AWS figure for its own capacity, so treat it as the boundary your realized rate moves within.

Block storage is prorated the same way instance hours are: 4,583.3 instance hours at 150 GB is 687,495 GB-hours, and dividing by 730 hours gives 941.8 GB-months. Volumes attached to standby disks bill continuously instead, since the disk stays while the instance is stopped.

Two reference points make the total readable. The same 250,000 minutes on the hosted warp-ubuntu-latest-x64-4x label bill 250,000 x $0.008 = $2,000.00 with no cloud bill, no capacity planning, and no quota work. On the GitHub-hosted 4-core Linux larger runner they bill 250,000 x $0.012 = $3,000.00; warp-ubuntu-latest-x64-4x costs $0.008 per minute against $0.012 for that runner, 33 percent lower list price (GitHub Actions minute multipliers, checked on 2026-08-13).

Use the model above with your measured job duration and cloud rates. Per-size WarpBuild rates for every label sit on the pricing page.

Routing is what puts each job on the line you modeled, and both label kinds live in one workflow file.

name: build
on: [push]

jobs:
  integration:
    runs-on: warp-custom-ci-linux-4x
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/integration-tests.sh

  docs:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/build-docs.sh

Operations

A model built before the first invoice needs three corrections after it, and all three come from counters you already have.

Instance hours against runner minutes. The 10 percent overhead assumption is the first thing real data contradicts. Divide billed instance hours by job hours from the WarpBuild reports; short jobs push the ratio up because boot and teardown are a fixed cost per job, so a fleet of 90-second jobs carries far more overhead than one of 15-minute jobs. Lengthening jobs by batching steps, or raising pool size so warm capacity absorbs the start, moves that ratio in opposite directions for the same reason.

Spot interruption rework. A reclaimed instance fails the job it was running and the job restarts from its first step, while the minutes already burned stay on both bills. At a 5 percent interruption rate on 150,000 spot minutes with jobs lost halfway through on average, rework adds 3,750 minutes, which is $7.50 in WarpBuild fees plus the matching compute. Long fallback instance type lists and a spread of availability zones are what keep the rate low. The spot instances guide covers which job classes tolerate the trade.

Storage and transfer drift. Cache buckets grow until a lifecycle policy stops them, and transfer climbs when a workflow starts pulling large images from outside your region. Both lines are small in the worked month above and both are the ones that quietly triple.

Reconciling the two invoices is a tagging problem rather than a modeling one. WarpBuild reports break down per job, per repository, and per runner label with execution time and billed time side by side; the cloud bill breaks down by resource tag. Cost allocation tags for BYOC runners covers the default tag keys the stack applies and the join between the two views, and how BYOC billing works is the short version of the split.

The decision the model actually informs is where each job class runs. BYOC wins when the compute line in your own account beats the hosted per-minute rate by more than the operating work costs you, which usually means committed-use discounts you already hold, a spot-tolerant job mix, or large instance shapes where the hourly rate dominates the per-minute fee. Hosted labels win when nobody wants to own quotas, images, and capacity. The total cost of a self-operated runner fleet prices that operating half in engineer hours, and it is the term most first models leave out.

FAQ

Does the WarpBuild BYOC fee change with instance size?

No. BYOC runners cost $0.002 per runner minute whether the runner set launches a 2 vCPU instance or a 64 vCPU instance. Instance size only moves the compute line, which your own cloud account bills at its own rate.

Why are my cloud instance hours higher than my billed runner minutes?

WarpBuild meters the job. Your cloud meters instance wall clock time, which includes boot, runner registration, and teardown around every job, plus any warm pool instances and the volumes attached to standby disks. Budget an overhead factor on top of job time rather than assuming the two counters match.

When does BYOC come out cheaper than hosted runners?

When the compute line in your own account beats the hosted per-minute rate by more than the operating work costs you. Teams with committed-use discounts, a spot-tolerant job mix, or large instance shapes usually clear that bar. Teams without an existing cloud footprint usually start on hosted runners and move later, which is a label change in runs-on.