Choosing Between Hosted and BYOC Runners

WarpBuild hosted runners bill a single per-minute rate that covers the machine, while BYOC runners bill $0.002 per minute in WarpBuild fees and your own AWS, GCP, or Azure account pays for the instance. Pick hosted when you want no cloud infrastructure to operate, macOS runners, or snapshot runners, and pick BYOC when you need spot instances, static IPs, custom VM images, local SSD, or a region you choose inside your own account.

Diagnosis

The same runner fleet ships in two shapes. Hosted runners live in WarpBuild's cloud and arrive as a label you put in runs-on. BYOC runners live in your cloud account: you grant an IAM role or service account, WarpBuild creates a stack (a region, a VPC, and an object storage bucket for cache, logs, and artifacts), and runner instances start and stop inside that VPC.

Most teams pick by habit rather than by the axes that actually differ. Six axes do the deciding.

Who pays for the compute. On hosted runners the machine is inside the per-minute rate. On BYOC the instance appears on your cloud invoice at whatever your account pays, including any committed-use or enterprise discount you have already negotiated, and WarpBuild charges $0.002 per minute on top.

Region. Hosted runners are offered in US and EU. A BYOC stack pins one region per cloud connection, chosen from the regions your own account supports, which is the axis that decides the question for teams with a data residency requirement.

Spot instances. BYOC only. Spot is the reason the BYOC line can drop far below the hosted line for interruption-tolerant work, and it is the reason to configure fallback instance types.

Static IPs. BYOC only. Enabling them places runners in private subnets behind managed network address translation, which adds data processing charges on every gigabyte the job moves, so they earn their place only where an allowlisted outbound address is a hard requirement.

Snapshot runners. WarpBuild Cloud only, on Linux x64 and Linux ARM64. A snapshot captures a runner VM mid-workflow and later jobs boot from it, which is the fastest way to skip a long dependency or database seeding step.

Custom VM images and local SSD. BYOC only. You can bake your own base image with the toolchain preinstalled, and instance types carrying local NVMe volumes are detected and mounted to the runner work directory at boot on Linux images, with several disks combined into a RAID-0 array.

Decision table

Source: the WarpBuild feature matrix, checked on 2026-08-13.

Per-cloud gaps worth knowing before you commit

BYOC runs on AWS, GCP, and Azure, and the three are not identical today. BYOC on Azure is enabled for East US only. The import flow, which puts runners into a VPC you already operate rather than creating a new one, is supported on AWS only. Windows on BYOC GCP is not generally available. BYOC Windows images are documented for Windows Server 2022, and those instances do not support Hyper-V. Terraform support exists for BYOC on AWS, so if you want the runner fleet declared in the same modules as the rest of your infrastructure, AWS is the mature path. Capacity is bounded by your own cloud quotas rather than by a WarpBuild cap, which is covered in BYOC capacity planning and cloud quotas.

Two things do not change with the choice. Generally available Linux and Windows runners do not have plan-level concurrency caps, and capacity adjusts dynamically.

Fix

Answer four questions in order and stop at the first yes.

1. Does a policy require build compute to run inside your own cloud account? Then BYOC, and the rest of the model is about which region and which instance families. The same answer applies when a workflow needs an allowlisted static outbound IP.
2. Do you need macOS runners? Those jobs run on hosted macOS labels. WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, and macOS is hosted only, so a mobile pipeline is a mixed fleet by construction.
3. Is a long setup step (dependency install, database seeding, toolchain build) the largest block of every job? Snapshot runners remove it, and they are hosted only.
4. Is the bill dominated by long Linux jobs that tolerate interruption? Then BYOC with spot instances is the cheapest shape available, and the cost model below shows the break-even point.

If every answer is no, start hosted. There is no cloud account to connect, no stack to create, and no quota to raise, and you can move a workload to BYOC later without touching anything except one line per job.

The mixed fleet is normal

Nothing forces a repository into one mode. The runner type is chosen per job, so unit tests can run on a hosted Linux runner, integration tests on a BYOC runner sitting next to the database they talk to, and an iOS build on a hosted macOS runner, all in one workflow file.

What migration actually touches

The workflow file changes in exactly one place: the runs-on value. BYOC runner IDs carry the warp-custom- prefix followed by the runner name you chose in the dashboard, so runs-on: warp-ubuntu-latest-x64-8x becomes runs-on: warp-custom-use1-linux-8x and the steps below it stay identical. Actions, caching, container layer caching, the Tailscale network addon, utilization metrics, and the Action Debugger behave the same on both sides. Billing changes: hosted minutes stop, the $0.002 per minute fee starts, and the instance shows up on your cloud invoice.

Plan for the reverse direction too. Keeping a hosted label in the matrix for one job is a cheap way to keep a fallback that needs no cloud capacity.

Configuration

The workflow below runs three jobs across both modes plus a fourth that boots from a snapshot. Only the labels differ.

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

jobs:
  unit-tests:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v5
      - run: npm ci
      - run: npm test

  integration-tests:
    runs-on: warp-custom-use1-linux-8x
    steps:
      - uses: actions/checkout@v5
      - run: ./scripts/integration.sh

  seeded-e2e:
    runs-on: warp-ubuntu-latest-x64-8x;snapshot.key=e2e-base
    steps:
      - uses: actions/checkout@v5
      - run: ./scripts/e2e.sh

  ios-build:
    runs-on: warp-macos-latest-arm64-6x
    steps:
      - uses: actions/checkout@v5
      - run: xcodebuild -scheme App -destination 'generic/platform=iOS' build

warp-custom-use1-linux-8x is a Runner ID from the custom runners page in the dashboard. The warp-custom- prefix is part of the ID and is required. The snapshot label uses the semicolon form documented on the snapshot runners page, and it works on hosted Linux runners only.

BYOC setup is three steps, documented in the BYOC guide:

1. Connect the cloud account. This creates the IAM role or service account WarpBuild uses to manage runners. Nothing runs yet.
2. Create a stack. Pick the region, VPC, and network configuration. The stack name, object storage location, and region cannot be changed after creation, so name stacks by product and region, for example payments-use1.
3. Create a custom runner. Choose instance types, disk, and IP configuration. List several instance types with similar performance so a job falls back when one type is unavailable in the region, which matters most on spot. Local NVMe volumes are detected and mounted at boot with no configuration. Leave static IPs off unless an allowlisted address is required.

Step-by-step AWS instructions, including the Terraform path, are in running GitHub Actions runners in your own AWS account. The spot configuration details are in spot instances for GitHub Actions runners.

Cost or Time Model

Hosted rates against GitHub list prices

Linux x64, matched shape for shape. WarpBuild rates come from the runner catalog and GitHub list prices were checked on 2026-08-13 on the GitHub Actions billing reference.

The break-even instance rate

BYOC beats hosted when the hourly rate your cloud account pays for the instance is below the hosted per-minute rate minus the $0.002 BYOC fee, multiplied by 60. That single line decides most of these conversations.

Small runners rarely clear the bar on on-demand pricing: an instance under $0.12 per hour with 2 vCPU and 8 GB is uncommon. Large runners clear it easily, and spot clears it at every size.

A worked month

Assumptions, all substitutable:

The arithmetic:

• Hosted warp-ubuntu-latest-x64-8x: 60,000 times $0.016 equals $960.00.
• The GitHub-hosted 8-core larger runner at list price: 60,000 times $0.022 equals $1,320.00 (GitHub billing reference, checked on 2026-08-13).
• BYOC WarpBuild fee: 60,000 times $0.002 equals $120.00.
• BYOC instance line at the example on-demand rate: 1,000 hours times $0.40 equals $400.00, for $520.00 total.
• BYOC instance line at the AWS published spot ceiling of a 90 percent discount below On-Demand, which is $0.04 per hour against the example rate: $40.00, for $160.00 total.

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 discount checked on 2026-08-13. That is a published ceiling from AWS rather than a WarpBuild measurement, and the rate you see depends on instance family, region, and the hour.

Two lines sit outside the table. The object storage bucket in your stack holds cache, logs, and artifacts, and is billed by your cloud provider. Runners with static IPs sit in private subnets, where AWS charges $0.045 per hour for managed network address translation plus $0.045 per GB processed in US East (N. Virginia) (Amazon VPC pricing, checked on 2026-08-13), which is enough to erase the instance saving on artifact-heavy jobs.

What the model says

At the example inputs, the hosted line is $960.00, the BYOC on-demand line is $520.00, and the BYOC spot line is $160.00, against $1,320.00 for the GitHub-hosted equivalent at list price. These totals apply only to the stated rates and duration; substitute your cloud prices and measured job times before choosing a placement.

Weigh the operational side against the difference. BYOC adds a cloud account to keep quota headroom in, an image to maintain if you go custom, and a stack to upgrade when new features need it. Price that work in hours per month and compare it against the gap between the two lines at your own minute volume, because the gap scales with minutes and the operational work does not. Teams with a residency requirement or a static IP requirement skip the arithmetic, since only one mode meets it.

WarpBuild pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee, on either mode, and the full rate card is on the pricing page. SSO is available for a flat $250 per month, whatever the user count, and it applies the same way to hosted and BYOC. Signup includes $10 free credits, which covers 1,250 minutes on warp-ubuntu-latest-x64-4x at $0.008 per minute and is enough to run both shapes against the same workflow before deciding.

Re-check the AWS and GitHub links before quoting these totals internally. Cloud list prices move, and the break-even table is the part of this page that stays stable.

FAQ

Is BYOC cheaper than hosted runners?

It depends on what your cloud account charges for the instance. The WarpBuild fee on BYOC is $0.002 per minute, so BYOC wins on an 8 vCPU Linux shape once your effective instance rate sits below $0.84 per hour, which is the hosted rate of $0.016 per minute minus the BYOC fee, multiplied by 60. On a 2 vCPU shape the break-even rate is $0.12 per hour, which on-demand instances rarely beat.

Can one repository use hosted and BYOC runners at the same time?

Yes. The runner type is chosen per job by the runs-on label, so a workflow can run unit tests on warp-ubuntu-latest-x64-4x, integration tests on a warp-custom- runner in your own account, and an iOS build on a macOS runner in the same file.

Do snapshot runners work on BYOC?

No. Snapshot runners are a WarpBuild Cloud feature on Linux x64 and Linux ARM64. Spot instances, static IPs, custom VM images, and local SSD auto-mount run the other way and are BYOC only.

Which clouds and regions does BYOC cover?

BYOC runs on AWS, GCP, and Azure. A stack pins one region per cloud account connection, BYOC on Azure is enabled for East US only today, importing an existing VPC is supported on AWS only, Windows on BYOC GCP is not generally available, and BYOC Windows images are documented for Windows Server 2022.