Windows Runners for GitHub Actions: Sizes and Pricing

WarpBuild runs Windows GitHub Actions runners on Windows Server 2022 and Windows Server 2025 in four x86-64 sizes, from 4 vCPU with 16GB of memory up to 32 vCPU with 128GB, priced from $0.016 to $0.128 per minute. Changing runs-on to a warp-windows- label moves the job, and because the images carry the same tooling as the GitHub-hosted Windows equivalents, the rest of the workflow file stays as it is.

This page lists every Windows label with its image, shape, storage, and alias; sets the per-minute rates against GitHub's published list prices for the equivalent Windows larger runners; and shows the workflow configuration for .NET, MSBuild, and NuGet builds. Rates and catalog rows were checked on 2026-08-13.

Catalog

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners. The Windows fleet is x86-64 only and splits into three image families that share one set of four machine shapes.

Source: WarpBuild cloud runners documentation, checked on 2026-08-13.

Reading the label

A Windows label has four parts: the warp-windows prefix, an image selector (latest, 2025, or 2025-vs2026), the architecture (x64), and the size multiplier (4x, 8x, 16x, 32x). The multiplier tracks vCPU count directly, so 8x is 8 vCPU and 32x is 32 vCPU. Memory scales at 4GB per vCPU across the whole Windows range, and storage is fixed at 256GB of SSD on every size rather than growing with the shape.

The warp-windows-latest-x64- labels currently resolve to Windows Server 2022. The warp-windows-2022-x64- aliases point at the same machines, so a repository that wants to stay pinned to Windows Server 2022 through a future latest rollover should write the dated alias instead of latest.

The three image families

Windows Server 2022 is the default. It is what latest resolves to today and it is the closest match to the GitHub-hosted windows-2022 image, which makes it the low-risk target for a workflow that is being moved over without any other changes.

Windows Server 2025 is the newer platform image and carries Visual Studio 2022, the same Visual Studio generation as the 2022 image. Moving a job from warp-windows-latest-x64-8x to warp-windows-2025-x64-8x changes the operating system underneath the build while leaving the toolset generation alone, which keeps the variable count down when something regresses.

Windows Server 2025 with Visual Studio 2026 uses the same Windows Server 2025 base image with Visual Studio 2026 installed in place of Visual Studio 2022, selected by the warp-windows-2025-vs2026-x64-<size> labels. These labels are transitional. Visual Studio 2026 may become the default for the Windows Server 2025 runners in a later update, which mirrors GitHub's own rollout of the Windows Server 2025 with Visual Studio 2026 image. Treat the vs2026 label as the way to test a Visual Studio 2026 toolset ahead of that switch rather than as a permanent pin.

Shapes that were removed

The 2 vCPU Windows runners were removed on June 8, 2026. Workflows that referenced a 2x Windows label need to move to 4x or larger. Cloud spot runners were removed on the same date, so the *-spot Windows labels are gone as well; spot capacity now comes from BYOC runners in your own cloud account.

What ships on the image

The Windows x86-64 runner images carry the same tooling as the GitHub-hosted equivalents, so dotnet, msbuild, nuget, git, PowerShell, and the Visual Studio build tools are present before the first step runs. The version list for the Windows Server 2022 image is published in the preinstalled software documentation, which links straight to GitHub's own image readme for the same generation. Tailscale is present on every Windows image with the daemon stopped until networking is configured for the runner.

Runner storage is ephemeral. A Windows runner is a fresh virtual machine per job and the 256GB volume is destroyed when the job finishes, so nothing carries over between jobs unless it goes through a cache action or an artifact upload.

One Windows-specific gap is worth planning around: WarpBuild caches are not supported for Windows-based runners. Windows jobs use actions/cache for NuGet packages and build output the same way they would on a GitHub-hosted Windows runner. The configuration section below shows the cache step that matters most for .NET.

Concurrency

Run as many jobs as your workflows need. Generally available Linux and Windows runners do not have plan-level concurrency caps. In practice this matters more on Windows than on Linux, because Windows matrices tend to be wide (several target frameworks times several runtime identifiers) and a queue ceiling turns a wide matrix into a serial one.

Pricing

Windows runner rates run from $0.016 per minute at 4 vCPU to $0.128 per minute at 32 vCPU. The rate depends only on the shape, so a Windows Server 2025 runner and a Visual Studio 2026 runner of the same size cost the same as the Windows Server 2022 runner of that size.

GitHub list prices for the Windows larger runner SKUs come from the GitHub Actions minute multipliers reference and the shapes from the GitHub-hosted runners reference, both checked on 2026-08-13. GitHub also publishes plan-level pricing at github.com/pricing. Every row above pairs a WarpBuild size with the GitHub shape that has the same vCPU and memory, so the comparison is per-minute rate against per-minute rate at equal hardware.

WarpBuild rates for every platform are listed on the WarpBuild pricing page.

What the rate covers

Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee. You are billed for runner minutes, so adding a tenth engineer to the organization changes the bill only through the jobs they queue. Signup includes $10 free credits, which at the 8 vCPU Windows rate covers roughly 312 runner minutes before any card is charged ($10 / $0.032 = 312.5 minutes).

SSO is a flat $250 per month, whatever the user count, listed alongside the runner rates on the pricing page.

Worked model: a Windows build fleet

Take a repository whose Windows lane runs 300 jobs per working day at an average of 9 minutes each, on the 8 vCPU shape.

• Minutes per day: 300 jobs x 9 minutes = 2,700 minutes
• Minutes per month at 21 working days: 2,700 x 21 = 56,700 minutes
• On warp-windows-latest-x64-8x at $0.032 per minute: 56,700 x $0.032 = $1,814.40
• On the 8-core GitHub-hosted Windows larger runner at $0.042 per minute: 56,700 x $0.042 = $2,381.40
• Monthly difference at identical shape and identical minutes: $567.00

The same arithmetic at a flat 10,000 Windows minutes per month, which is easier to scale to your own volume:

GitHub rates in both models are the published list prices checked on 2026-08-13 at the link above. Both models hold minutes constant on each side, which is the conservative comparison. Substitute your own monthly Windows minutes from the Actions usage report to get your number; the structure of the model does not change.

Worked model: choosing a size

Windows rates double with each step up the size ladder, so a larger runner pays for itself only when it cuts wall-clock time by more than half. The break-even rule for a step from 4x to 8x is:

cost_4x = duration_on_4x x $0.016
cost_8x = duration_on_8x x $0.032

Plug in your own measured durations from two runs of the same commit. Worked with an example pair of 14 minutes on 4 vCPU and 9 minutes on 8 vCPU:

• 4x: 14 minutes x $0.016 = $0.224 per job
• 8x: 9 minutes x $0.032 = $0.288 per job
• Delta: $0.064 more per job to return 5 minutes of wall-clock time per job

At 300 jobs per day and 21 working days that is $403.20 more per month and 525 engineer-hours per month of pull request feedback returned (6,300 jobs x 5 minutes). Whether that trade is worth taking is a question for the team; the point is that both sides of it are computable from the per-minute table, and per-minute billing means a job that finishes early stops costing money at the moment it finishes.

MSBuild parallelism is what decides where a solution lands on that curve. A solution with a deep project dependency chain will not use 32 vCPU no matter what /m is set to, and paying the 32 vCPU rate for a chain that saturates 8 cores burns the difference for nothing. Measure at 8x first, then step up only for solutions that show the cores being used.

BYOC Windows runners

BYOC runs on AWS, GCP, and Azure across the WarpBuild platform. For the Windows fleet specifically, BYOC is available on AWS and Azure. Windows 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. Terraform support exists for BYOC on AWS, so the runner pool can be declared in the same configuration as the rest of the account.

Configuration

A Windows job moves by editing one line. The label goes in runs-on and everything else in the workflow stays as it is.

name: windows-build

on:
  push:
    branches: [main]
  pull_request:

jobs:
  build:
    runs-on: warp-windows-latest-x64-8x
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: 8.0.x

      - name: Cache NuGet packages
        uses: actions/cache@v4
        with:
          path: ~\.nuget\packages
          key: nuget-${{ runner.os }}-${{ hashFiles('**/packages.lock.json') }}
          restore-keys: |
            nuget-${{ runner.os }}-

      - run: dotnet restore Contoso.sln --locked-mode
      - run: dotnet build Contoso.sln --configuration Release --no-restore
      - run: dotnet test Contoso.sln --configuration Release --no-build --logger trx

Selecting an image

Start on warp-windows-latest-x64-<size> when moving an existing workflow. It resolves to Windows Server 2022, which is the closest match to the GitHub-hosted windows-2022 image, so a red build after the switch points at the machine size or the runner environment rather than at an operating system upgrade.

Move to warp-windows-2025-x64-<size> when the build needs the Windows Server 2025 platform. The Visual Studio generation stays at 2022 on this image, so the only variable that changes is the operating system.

Use warp-windows-2025-vs2026-x64-<size> when the build needs Visual Studio 2026. Because these labels are transitional, run them on a branch or a scheduled job first and keep the production lane on a dated label until the toolset is proven.

A matrix is the cheapest way to prove an image migration before committing to it. Run the same job across all three images at the smallest size and compare:

name: windows-image-compat

on:
  schedule:
    - cron: "0 6 * * 1"
  workflow_dispatch:

jobs:
  compat:
    strategy:
      fail-fast: false
      matrix:
        image:
          - warp-windows-latest-x64-4x
          - warp-windows-2025-x64-4x
          - warp-windows-2025-vs2026-x64-4x
    runs-on: ${{ matrix.image }}
    steps:
      - uses: actions/checkout@v4
      - run: dotnet --info
      - run: dotnet restore Contoso.sln --locked-mode
      - run: dotnet test Contoso.sln --configuration Release

At $0.016 per minute per leg, a weekly three-way compatibility matrix of 10-minute jobs costs $0.48 per week.

MSBuild and Visual Studio solutions

Solutions that build through MSBuild rather than the .NET SDK need the Visual Studio developer environment on PATH. The setup action resolves the installed Visual Studio instance on the image, which is why the same workflow file works on the Visual Studio 2022 images and the Visual Studio 2026 image without a version pin in the workflow:

jobs:
  msbuild:
    runs-on: warp-windows-2025-vs2026-x64-16x
    steps:
      - uses: actions/checkout@v4
      - uses: microsoft/setup-msbuild@v2
      - uses: nuget/setup-nuget@v2

      - name: Cache NuGet packages
        uses: actions/cache@v4
        with:
          path: ~\.nuget\packages
          key: nuget-${{ runner.os }}-${{ hashFiles('**/packages.lock.json') }}

      - run: nuget restore Contoso.sln
      - run: msbuild Contoso.sln /p:Configuration=Release /m /verbosity:minimal
      - run: msbuild Contoso.sln /t:Pack /p:Configuration=Release

/m lets MSBuild build independent projects in parallel and is what makes the 16 vCPU and 32 vCPU sizes worth their rate. Without it MSBuild builds one project at a time and a larger runner mostly buys idle cores.

NuGet caching on Windows

WarpBuild caches are not supported for Windows-based runners, so Windows jobs restore packages through actions/cache exactly as they would on a GitHub-hosted Windows runner. Three details decide whether the cache actually hits:

Cache the global packages folder rather than the project folders. The path is ~\.nuget\packages on Windows. Setting NUGET_PACKAGES to a workspace path and caching that path instead also works and makes the location explicit:

env:
  NUGET_PACKAGES: ${{ github.workspace }}\.nuget\packages

Key on a lock file. hashFiles('**/packages.lock.json') produces a key that changes only when the resolved dependency graph changes. Committing lock files and running dotnet restore --locked-mode also turns a silent dependency drift into a failed restore, which is the behavior you want in a pull request.

Restore before build, then build with --no-restore. Letting dotnet build run its own implicit restore after a cache hit re-resolves packages and undoes part of what the cache saved.

For test output, --logger trx writes result files that upload cleanly with actions/upload-artifact, and the 256GB volume gives large integration test runs room for result files and crash dumps without a disk pressure failure.

Job-level sizing

Sizes are per job, so a workflow can put the expensive compile on a large runner and keep the cheap jobs small. This is usually a bigger lever on the bill than picking one size for the whole repository:

jobs:
  lint:
    runs-on: warp-windows-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - run: dotnet format --verify-no-changes

  build-and-test:
    runs-on: warp-windows-latest-x64-16x
    steps:
      - uses: actions/checkout@v4
      - run: dotnet restore Contoso.sln --locked-mode
      - run: dotnet build Contoso.sln --configuration Release --no-restore /m
      - run: dotnet test Contoso.sln --configuration Release --no-build

Shells and paths

Windows jobs default to PowerShell for run steps. Add shell: bash on a step when a script depends on the Git bash environment, and keep path separators consistent inside each step; mixing \ and / in the same script is the usual cause of a step that passes locally and fails on the runner.

Managing runners programmatically

For the full runner reference including the other platforms, see the cloud runners documentation. For image tooling versions, see the preinstalled software documentation.

Where to go next

• Cut wall-clock time on Windows GitHub Actions jobs covers the sizing, caching, and matrix changes that move Windows job duration.
• Run .NET builds and tests on GitHub Actions walks the full .NET workflow across platforms.
• Model the cost of GitHub Actions larger runners generalizes the per-minute arithmetic above across every runner size.
• Diagnose GitHub Actions queue times covers what to check when jobs sit queued rather than running slowly.

FAQ

What Windows runner sizes does WarpBuild offer?

Four sizes on x86-64: 4 vCPU with 16GB, 8 vCPU with 32GB, 16 vCPU with 64GB, and 32 vCPU with 128GB. Every size carries 256GB of SSD storage. The 2 vCPU Windows runners were removed on June 8, 2026, so 4 vCPU is the smallest available shape.

What does a Windows runner cost per minute?

$0.016 per minute at 4 vCPU, $0.032 at 8 vCPU, $0.064 at 16 vCPU, and $0.128 at 32 vCPU. Billing is per minute of runner time with no base subscription fee, no platform fee, and no seat fee, and signup includes $10 free credits.

Which Windows image should I pick?

warp-windows-latest-x64-<size> resolves to Windows Server 2022 and is the safe default for an existing workflow. Use warp-windows-2025-x64-<size> for Windows Server 2025 with Visual Studio 2022, and warp-windows-2025-vs2026-x64-<size> when the build needs Visual Studio 2026.

Does the WarpBuild cache work on Windows runners?

No. WarpBuild caches are not supported for Windows-based runners. Use actions/cache in the workflow for NuGet packages, MSBuild output, and other Windows build state.