Does BYOC Support Windows Runners?

Answer

Yes. WarpBuild BYOC runs Windows Server 2022 x86-64 GitHub Actions runners as instances inside your own cloud account, and the AWS BYOC configuration guide documents a separate set of minimum infrastructure requirements for Windows that sits above the general minimums a Linux custom runner is created with. Plan for that difference before you copy a Linux runner definition and change the image.

BYOC runs on AWS, GCP, and Azure. Windows coverage is narrower than Linux coverage across those three, and the feature matrix is the row that decides it, checked on 2026-08-13.

The workflow change is the same one Linux BYOC jobs make. A custom runner is a named machine configuration, and the workflow references it by Runner ID, which is the runner name with the warp-custom- prefix.

Detail

The documented Windows minimums

Two numbers move when the guest operating system is Windows Server 2022 rather than Linux, and one more is a recommendation rather than a floor. All four rows come from the AWS BYOC configuration guide, checked on 2026-08-13.

The instance row is the one that surprises teams sizing from the hosted catalog. WarpBuild hosted Windows runners start at 4 vCPU with 16 GB, since the 2 vCPU Windows shapes were removed on June 8, 2026 (see the Windows runner catalog), so a hosted 4 vCPU Windows job has no direct BYOC counterpart under this guidance. Start the BYOC equivalent at 8 vCPU and let the disk numbers follow.

Give the runner more than one instance type in priority order. The workflow still names a single label, and WarpBuild picks from the list by availability, which keeps queued jobs from waiting on one instance family in one availability zone.

Custom Windows images

BYOC runners can boot your own AMI instead of a WarpBuild image, and the custom VM images guide lists what a Windows AMI has to carry. Three requirements are specific to Windows on AWS.

1. aria2 on the system PATH. WarpBuild downloads job artifacts with aria2 because the default Windows method is slow. The guide includes a PowerShell block that unpacks the release into C:\Tools\aria2 and appends that directory to the machine Path variable.
2. A sysprepped instance. The EC2 instance has to be generalized with sysprep before you create an AMI from it, either through the Amazon EC2Launch settings dialog or through the Packer sysprep commands the guide links.
3. The runneradmin user. Jobs run under runneradmin, the same user GitHub's Windows runners use, and WarpBuild adds the account if the image does not have it. User-scoped environment variables baked into some other account will not be visible to the job, so move them to machine scope or set them for runneradmin.

The workflow

A BYOC Windows label and a hosted label can sit in the same workflow file, which is how teams run Windows in their own account while keeping other platforms on hosted capacity. WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners.

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

jobs:
  windows-build:
    runs-on: warp-custom-win2022-use1-8x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4
        with:
          path: ~\AppData\Local\NuGet\v3-cache
          key: nuget-${{ hashFiles('**/packages.lock.json') }}
      - run: dotnet restore
      - run: dotnet build --configuration Release --no-restore
      - run: dotnet test --configuration Release --no-build

  linux-build:
    runs-on: warp-custom-linux-use1-8x
    steps:
      - uses: actions/checkout@v4
      - run: make build

What the Windows minutes cost

BYOC bills $0.002 per runner minute for Windows runners, and your AWS or Azure account bills the instance, the disk, and the data transfer at your own rates.

On the hosted route the arithmetic is (0.042 - 0.032) / 0.042 = 24 percent lower list price, GitHub list price checked on 2026-08-13 at the GitHub Actions billing reference. The BYOC row is a partial bill by design: add what your cloud charges for the instances and the higher-IOPS disks the Windows guidance calls for, since a 6000 IOPS, 500 MBps volume costs more than the 3000 IOPS floor.

Windows BYOC at production scale

SonarQube runs tens of thousands of GitHub Actions jobs per day on WarpBuild BYOC runners in its own AWS account, across Windows and Linux. Their team drives image updates and runner configuration changes through the WarpBuild API rather than the dashboard, which is the pattern to copy once a Windows runner definition is settled and you want the AMI refreshed on a schedule. The SonarQube customer page has the account details.

Related Questions

Which clouds run Windows BYOC runners?

AWS and Azure. BYOC runs on AWS, GCP, and Azure, and the feature matrix marks Windows x86-64 as supported on AWS and Azure and pending on GCP, checked on 2026-08-13. A workflow that needs Windows while its Linux jobs sit on GCP BYOC keeps a hosted warp-windows- label for those jobs, priced on the Windows runners page.

What instance and disk configuration do Windows BYOC runners need on AWS?

The AWS BYOC configuration guide recommends at least 8 vCPU with the m7a series, 6000 IOPS, and 500 MBps of disk throughput for Windows Server 2022 x86-64 runners. The general custom runner minimum is 100 GB, 125 MBps, and 3000 IOPS, so a Windows runner definition copied from a Linux one usually needs its disk settings raised. The AWS BYOC page walks the full stack and runner setup.

Can I run my own Windows AMI on BYOC?

Yes. Linux and Windows AMIs are both supported. A Windows AMI needs aria2 installed and reachable on the system PATH, and the EC2 instance has to be sysprepped before you create the image from it. Jobs run under the runneradmin user, the same user GitHub's Windows runners use, so check where your user-scoped environment variables live. The custom VM images guide carries the PowerShell and the sysprep steps, and Windows BYOC runners on AWS covers the rest of the setup.