What Is the Smallest Windows Runner Size?
The smallest Windows GitHub Actions runner is 4 vCPU with 16GB of memory at $0.016 per minute. The 2 vCPU Windows tier was removed on June 8, 2026.
Last verified:
The smallest Windows GitHub Actions runner size available on WarpBuild is 4 vCPU with 16GB of memory and 256GB of SSD storage, at $0.016 per minute (cloud runners documentation, checked on 2026-08-13). The 2 vCPU Windows tier was removed on June 8, 2026, so warp-windows-latest-x64-4x and its Windows Server 2025 equivalents are the entry shapes on every Windows image family (changelog).
Answer
WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners (cloud runners documentation). The Windows line is x86-64 only and runs four shapes, and the size multiplier in the label tracks vCPU count directly.
| Size | vCPU | Memory | Storage | Per minute | Labels at this size |
|---|---|---|---|---|---|
| 4x | 4 | 16GB | 256GB SSD | $0.016 | warp-windows-latest-x64-4x, warp-windows-2025-x64-4x, warp-windows-2025-vs2026-x64-4x |
| 8x | 8 | 32GB | 256GB SSD | $0.032 | warp-windows-latest-x64-8x, warp-windows-2025-x64-8x, warp-windows-2025-vs2026-x64-8x |
| 16x | 16 | 64GB | 256GB SSD | $0.064 | warp-windows-latest-x64-16x, warp-windows-2025-x64-16x, warp-windows-2025-vs2026-x64-16x |
| 32x | 32 | 128GB | 256GB SSD | $0.128 | warp-windows-latest-x64-32x, warp-windows-2025-x64-32x, warp-windows-2025-vs2026-x64-32x |
Every row comes from the cloud runners documentation, checked on 2026-08-13, and the Windows runner catalog page carries the same rows with the alias column.
Three labels disappeared in the June 2026 removal: warp-windows-latest-x64-2x, warp-windows-2025-x64-2x, and warp-windows-2022-x64-2x (changelog, June 8, 2026). The removal covered all three image families at once, so a job that used to run on a 2 vCPU Windows machine moves up to 4x or larger. Storage holds at 256GB of SSD across the current range, from 4x through 32x, so the disk a build sees does not change when a job moves up a size.
Picking the entry size is one line of YAML:
name: windows-tests
on:
pull_request:
jobs:
test:
runs-on: warp-windows-latest-x64-4x
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 Contoso.sln
- run: dotnet test Contoso.sln --configuration ReleaseRates for every platform are on the pricing page.
Detail
What the entry size costs against the GitHub-hosted equivalent
warp-windows-latest-x64-4x (4 vCPU, 16 GB) costs $0.016 per minute against $0.022 per minute for the 4-core Windows larger runner (4 vCPU, 16 GB): 27 percent lower list price. GitHub list price checked on 2026-08-13 in the GitHub Actions minute multipliers reference, with shapes from the GitHub-hosted runners reference.
At a round monthly volume, 8,000 Windows minutes at the entry size is $128.00 on WarpBuild against $176.00 at the GitHub list rate, a difference of $48.00 a month on identical hardware. The arithmetic holds at each rung of the ladder, and the larger runners cost guide works through the 8x, 16x, and 32x rows the same way.
When 4 vCPU is enough
The entry size fits jobs whose wall-clock time is dominated by input and output rather than compute: NuGet restores, packaging and signing steps, single-project builds, smoke tests, and anything that spends most of its minutes waiting on the network. It also fits fleets that get parallelism from a job matrix, because eight 4 vCPU jobs at $0.016 each cost the same per minute as two 16 vCPU jobs at $0.064 while finishing eight units of work instead of two.
Rates double with each step up the ladder, so a larger runner pays for itself only when it cuts wall-clock time by more than half. A 20 minute job at 4x costs $0.320. The same job needs to finish in under 10 minutes at 8x to cost less, since 12 minutes at $0.032 per minute is $0.384 and 9 minutes is $0.288. Time the job at both sizes on a branch before the change lands on the default lane.
When the build is memory bound rather than CPU bound
Memory scales at 4GB per vCPU across the whole Windows range, so 16GB at 4x, 32GB at 8x, 64GB at 16x, and 128GB at 32x (cloud runners documentation). Buying memory means buying vCPU with it, which is the usual reason a Windows job sits on a size larger than its core count would suggest.
Three symptoms point at memory rather than cores. MSBuild with /m starts one node per core and each node holds its own project state, so a large solution can exhaust 16GB before it saturates 4 vCPU (MSBuild command-line reference). Test runners that fork a process per assembly multiply resident memory the same way. Native link steps and large asset pipelines allocate in single large blocks and fail outright rather than slowing down, which shows up as an exit without a useful log line.
Measure before moving. CI observability records CPU and memory percentiles per job, alongside snapshot runners, remote Docker builders, an MCP server, and the Action Debugger in the product surface (cloud runners documentation). A job holding a 90th percentile memory figure near 16GB on a 4x runner belongs on 8x; a job holding 6GB with CPU pinned at 100 percent belongs on 8x for a different reason and should be timed against the doubling rate first.
One Windows-specific constraint shapes the choice. WarpBuild caches are not supported for Windows-based runners (cloud runners documentation), so Windows jobs use actions/cache in the workflow for NuGet packages and build output, as in the snippet above. Cache restore time counts as billed minutes at whatever size the job runs, which is another argument for keeping restore-heavy jobs at 4x and spending the size budget on the compile step.
Related Questions
What is the smallest Windows GitHub Actions runner size on WarpBuild?
4 vCPU with 16GB of memory and 256GB of SSD storage, at $0.016 per minute. The 2 vCPU Windows runners were removed on June 8, 2026, so 4x is the entry shape in all three Windows image families (cloud runners documentation). The Windows runner catalog lists every label at every size.
Can I still use warp-windows-latest-x64-2x?
No. The warp-windows-latest-x64-2x, warp-windows-2025-x64-2x, and warp-windows-2022-x64-2x labels were removed on June 8, 2026 (changelog). A workflow still naming one of them needs an edit to a 4x or larger label.
Is there a smaller runner than the smallest Windows size?
Yes, on Linux. The catalog starts at 2 vCPU with 8GB on Linux ARM64 at $0.003 per minute and Linux x64 at $0.004 per minute, while the Windows floor is 4 vCPU with 16GB at $0.016 per minute (cloud runners documentation). Jobs with no Windows dependency, such as linting and documentation builds, belong on those Linux labels. The cheapest GitHub Actions runner size answer compares the entry shape on each platform.
Price your own Windows minutes against the ladder on the pricing page, then pick a label from the Windows runner catalog.
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.