How Does BYOC Billing Work?
BYOC billing runs on two lines. WarpBuild charges $0.002 per runner minute, and the instances, disks, and data transfer land on your own cloud bill.
Last verified:
BYOC billing has two lines. WarpBuild charges a per-minute platform fee of $0.002 per runner minute for BYOC runners, and the compute those runners use is billed by your own cloud account at whatever rate that account pays for the instance (pricing page and BYOC documentation, checked on 2026-08-13).
Answer
The split follows the architecture. Runners launch inside your AWS, GCP, or Azure account against a WarpBuild stack that pins a region, a VPC, and an object storage bucket, per the BYOC documentation. WarpBuild meters the runner minutes and invoices the platform fee. Your cloud provider meters the instances, volumes, storage, and network traffic those runners consume and invoices them on your existing cloud bill.
| Line | Who bills it | Rate | Where it lands |
|---|---|---|---|
| BYOC Linux runners on AWS, GCP, or Azure | WarpBuild | $0.002 per runner minute | WarpBuild invoice |
| BYOC Windows runners on AWS or Azure | WarpBuild | $0.002 per runner minute | WarpBuild invoice |
| Instance compute for those runners | Your cloud account | your on-demand, spot, or committed rate | Your cloud bill |
| Runner disks and standby disk volumes | Your cloud account | provider block storage rates | Your cloud bill |
| Object storage for cache, logs, and artifacts | Your cloud account | provider object storage rates | Your cloud bill |
| Data transfer and NAT gateway processing | Your cloud account | around $0.45 per GB on AWS | Your cloud bill |
WarpBuild rates come from the pricing page, and the data transfer figures come from the BYOC documentation, both checked on 2026-08-13.
Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, so the WarpBuild line is runner minutes multiplied by $0.002 and nothing else. Signup includes $10 free credits, which covers 5,000 BYOC runner minutes of WarpBuild fees while you measure a real month.
Detail
What the $0.002 line covers
The fee is the same for every BYOC instance shape. A 4 vCPU runner and a 64 vCPU runner both bill $0.002 per runner minute to WarpBuild, because the size only changes what your cloud account charges for the instance. Cache storage and cache operations, which cost $0.20 per GB-month and $0.0001 per operation on hosted runners (pricing page), are included on BYOC runners, since the cache lives in the object storage bucket the stack created in your account.
BYOC runs on AWS, GCP, and Azure. The macOS fleet is hosted, so macOS jobs stay on hosted labels and price from the pricing page rather than from the BYOC line.
A worked month makes the shape obvious. Take 60,000 BYOC Linux runner minutes on an 8 vCPU shape:
| Component | Volume | Rate | Cost |
|---|---|---|---|
| WarpBuild BYOC fee | 60,000 runner minutes | $0.002/min | $120.00 |
| Cache storage and operations | included on BYOC | $0.00 | $0.00 |
| Seats, base subscription, platform fee | 1 account | none | $0.00 |
| EC2 instance hours | 1,000 instance hours | your account rate | your cloud bill |
The first three rows are fixed by the price list. The fourth is the one you model, and it swings with instance family, region, spot ratio, and any committed-use discounts you already hold. The BYOC cost model walks through that half against a real month of workflow minutes.
What lands on the cloud bill besides compute
Four items sit alongside instance hours, and teams that only model compute underestimate the cloud half.
Block storage is the first. Every runner carries a root volume, and standby disks add more. A standby disk is a VM of the runner's instance type that is booted once and then shut down so a job can start on warm networking and machine setup. WarpBuild does not charge for standby disks; the stopped VM stops billing compute in your account while its volume keeps billing storage, per the BYOC documentation.
Object storage is the second. The bucket the stack creates holds the artifact cache under <bucket_name>/<org_id>/artifact_cache/... and runner telemetry under <bucket_name>/runner/logs/..., per the AWS configuration guide. That guide recommends an S3 lifecycle policy with 7 days of retention, which is the single largest lever on the storage line.
Data transfer is the third, and it is the item most likely to surprise. The BYOC documentation puts outbound data transfer from a runner to the internet at around $0.45 per GB on AWS. Runners in public subnets, which is the default when static IPs are disabled, avoid the gateway path entirely and usually carry minimal egress for GitHub Actions workloads.
Gateway processing is the fourth. Enabling static IPs moves runners into private subnets behind a NAT gateway, which adds NAT data processing fees of around $0.45 per GB for inbound and outbound traffic, plus any inter-region transfer between the subnets and the gateway. The BYOC documentation recommends using static IPs sparingly for that reason. The AWS configuration guide also recommends an S3 gateway endpoint on the VPC so cache traffic to the bucket does not take a chargeable transfer path.
Spot instances and the compute half
Spot changes the cloud line and leaves the WarpBuild line alone. 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 published ceiling is an AWS figure for its own capacity, so treat it as the range your compute rate moves within rather than a realized result.
Two operational facts belong in the model. A reclaimed spot instance fails the job it was running, and the job restarts from its first step while the minutes already burned stay on both bills. Spot instances are also unsupported for standby disks, so a runner set gets either a warm pool or spot pricing. The spot instances guide covers which jobs suit that trade and how to configure fallback instance types so availability stops stranding queued jobs.
Reading both bills together
The WarpBuild side breaks down per job, per repository, and per runner label in the billing reports, with execution time and billed time side by side. The cloud side breaks down through your provider's own cost tooling, which is where instance hours, volumes, storage, and transfer separate. Tagging runner resources at the stack level is what lets those two views reconcile against the same workflows. Architecture, IAM detail, and the AWS specifics of that setup are on the BYOC on AWS page.
Related Questions
Does WarpBuild charge for cache or networking on BYOC runners?
No. Cache storage and cache operations are included on BYOC runners, and the object storage bucket that holds the cache sits in your own cloud account, so your cloud provider bills that storage instead. The hosted-runner rates for the same items, $0.20 per GB-month and $0.0001 per operation, are on the pricing page.
Do spot instances change the WarpBuild BYOC fee?
No. The WarpBuild fee stays $0.002 per runner minute whether the instance is on-demand or spot. 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 discount applies to the compute half of the bill in your own account. The spot instances guide covers the interruption behavior that comes with it.
Which clouds and platforms does the $0.002 BYOC fee cover?
BYOC runs on AWS, GCP, and Azure. Linux runners are billed at $0.002 per minute on all three, Windows runners at $0.002 per minute on AWS and Azure, per the pricing page. macOS runners are hosted by WarpBuild and priced from the standard per-minute rate list. Setup detail for the largest of the three paths is on the BYOC on AWS page, and the full model sits on the BYOC cost model page.
Start with $10 in free credits
Change the runner label in your workflow and keep the rest of your GitHub Actions setup. Runner time is billed per minute.