Visual Studio Images on Windows GitHub Actions Runners

Visual Studio 2026 runs on WarpBuild Windows GitHub Actions runners through the warp-windows-2025-vs2026-x64-<size> labels, which boot the Windows Server 2025 base image with Visual Studio 2026 installed in place of Visual Studio 2022. Every other Windows label, warp-windows-latest-x64-<size> on Windows Server 2022 and warp-windows-2025-x64-<size> on Windows Server 2025, still carries Visual Studio 2022, so the toolset a job compiles with is chosen by the string in runs-on.

This page maps each Windows label to its Windows Server generation and its Visual Studio generation, prices every size against GitHub's published Windows larger runner list prices, and shows the workflow configuration for pinning an image and for moving a job off Windows Server 2022 without changing two variables at once. Catalog rows and rates were checked on 2026-08-13.

Catalog

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners. The Windows fleet is x86-64 and splits into three image families over one set of four machine shapes, so a single label selects a Windows Server generation, a Visual Studio generation, and a size.

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

How the label encodes the image

A Windows label has four parts: the warp-windows prefix, an image selector, the x64 architecture, and a size multiplier. The image selector is the only part that decides which Visual Studio generation is installed. latest resolves to Windows Server 2022, 2025 selects Windows Server 2025 with Visual Studio 2022, and 2025-vs2026 selects Windows Server 2025 with Visual Studio 2026.

The size multiplier changes hardware only. A 4x runner and a 32x runner built from the same image carry an identical toolset, so a compatibility problem that appears when you resize a job points at memory, disk, or build parallelism instead of at a different Visual Studio installation.

The Visual Studio 2022 images

Two labels give you Visual Studio 2022 on different Windows Server generations. warp-windows-latest-x64-<size> runs Windows Server 2022 and is the closest match to the GitHub-hosted windows-2022 image. warp-windows-2025-x64-<size> runs Windows Server 2025 with the same Visual Studio generation, which is what makes it a useful intermediate step: the operating system moves while the compiler, the MSVC runtime, and the MSBuild version stay put.

The Visual Studio 2026 image and its transitional caveat

warp-windows-2025-vs2026-x64-<size> uses the Windows Server 2025 base image with Visual Studio 2026 installed instead of Visual Studio 2022. The documentation is explicit that these labels are transitional: they include Visual Studio 2026 while the warp-windows-2025-x64-<size> labels still include Visual Studio 2022, and Visual Studio 2026 may become the default for the Windows Server 2025 runners in a later update. That reflects GitHub's own rollout process for the Windows Server 2025 with Visual Studio 2026 image.

Two consequences follow for a workflow author. A job pinned to warp-windows-2025-x64-16x today compiles with Visual Studio 2022 and could compile with Visual Studio 2026 after that default switch lands. A job pinned to warp-windows-2025-vs2026-x64-16x gets Visual Studio 2026 now and keeps getting it after the switch, because the selector names the toolset directly. Decide which side of the switch each lane belongs on before it happens rather than after a red build tells you.

Image versions and update cadence

Windows images are rebuilt from the upstream GitHub runner image releases and every rebuild is recorded in the WarpBuild changelog. The August 12, 2026 entry lists win22/20260809.268 for Windows Server 2022, win25/20260809.223 for Windows Server 2025, and win25-vs2026/20260810.198 for the Windows Server 2025 with Visual Studio 2026 image.

Those version strings are the unit to quote in a bug report. A build that worked last week and fails today on the same label usually moved across one of those rebuilds, and naming the version string turns the question from "Windows is broken" into a diff between two published image manifests.

Shapes, storage, and removed sizes

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. That storage figure matters on Visual Studio work because a full solution build plus test result files, PDBs, and an installer payload all land on the same volume. Runner storage is ephemeral and is deleted when the runner terminates.

The 2 vCPU Windows runners were removed on June 8, 2026, so 4 vCPU is the smallest available Windows shape and any workflow still naming a 2x Windows label needs to move up.

Concurrency

Generally available Windows runners do not have plan-level concurrency caps, and capacity adjusts dynamically. That makes a three-image validation matrix practical to run on a schedule without a plan limit serializing its legs.

Pricing

The per-minute rate on a Windows runner depends only on the machine shape. A Visual Studio 2026 runner costs the same as the Windows Server 2022 runner of the same size, so adopting the newer toolset is a scheduling decision rather than a budget one.

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. Each row pairs a WarpBuild size with the GitHub shape that has the same vCPU count and the same memory, so the comparison is rate against rate at equal hardware. The same rates apply to the warp-windows-latest-x64-<size> and warp-windows-2025-x64-<size> labels and are listed for every platform 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, so a Visual Studio 2026 pilot that only a few engineers touch adds nothing to the bill beyond the minutes it runs. Signup includes $10 free credits, which covers 312 minutes on the 8 vCPU Windows shape at $0.032 per minute before any card is charged.

SSO is available for a flat $250 per month, whatever the user count.

Worked model: a Visual Studio 2026 shadow lane

The usual way to adopt a new toolset without risking the merge queue is a shadow job: the production lane stays on the current image and a second job compiles the same commit on the candidate image with continue-on-error set.

Take 25 pull request events per working day, one shadow job each, 12 minutes per job on the 8 vCPU shape:

• Minutes per day: 25 jobs x 12 minutes = 300 minutes
• Minutes per month at 21 working days: 300 x 21 = 6,300 minutes
• On warp-windows-2025-vs2026-x64-8x at $0.032 per minute: 6,300 x $0.032 = $201.60
• On the 8-core GitHub-hosted Windows larger runner at $0.042 per minute: 6,300 x $0.042 = $264.60
• Monthly difference at identical shape and identical minutes: $63.00

Substitute your own pull request volume and job duration; the structure holds. The shadow lane is temporary by design, so the number that matters is the cost of carrying it for the weeks between the first green run and the cutover.

Worked model: a nightly three-image matrix

A cheaper alternative to a per-pull-request shadow job is one nightly matrix across all three images. At 18 minutes per leg on the 16 vCPU shape:

• Per night: 3 legs x 18 minutes = 54 minutes, and 54 x $0.064 = $3.46
• Per 30-day month: $103.68

That buys a daily signal on Windows Server 2022, Windows Server 2025 with Visual Studio 2022, and Windows Server 2025 with Visual Studio 2026 for about the price of one engineer-hour, and it catches an image rebuild that breaks a build within a day of the rebuild shipping.

Windows runners in your own cloud

BYOC runs on AWS, GCP, and Azure, and Terraform support exists for BYOC on AWS, so a Windows pool can be declared in the same configuration as the rest of the account. Compute is billed by your cloud account and the WarpBuild fee is charged per runner minute on top.

Configuration

Selecting a Visual Studio generation is a one-line change in runs-on. This job compiles a solution with Visual Studio 2026 on a 16 vCPU Windows Server 2025 runner:

name: windows-build

on:
  push:
    branches: [main]
  pull_request:

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

      - name: Record the Visual Studio toolset
        shell: pwsh
        run: |
          $vswhere = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe"
          & $vswhere -latest -property catalog_productDisplayVersion
          & $vswhere -latest -property installationPath

      - 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: nuget restore Contoso.sln
      - run: msbuild Contoso.sln /p:Configuration=Release /m /verbosity:minimal

The vswhere step is worth keeping permanently. It writes the installed Visual Studio version into the job log, so when the transitional labels eventually change what warp-windows-2025-x64-<size> means, every archived run already records which toolset produced its artifacts.

Pin the image label rather than the alias

warp-windows-latest-x64-<size> and its warp-windows-2022-x64-<size> alias point at the same machines today. The dated form is the safer one to commit, because latest moves when the default image generation moves and the dated label does not.

The same reasoning applies one level up for Visual Studio. A lane that must stay on Visual Studio 2022 should name warp-windows-2025-x64-<size> only while that label carries Visual Studio 2022, and should move to warp-windows-latest-x64-<size> once the default switch is announced in the changelog. A lane that must have Visual Studio 2026 should name the vs2026 label, which is stable through the switch.

Moving a job from Windows Server 2022 to Windows Server 2025

Change one variable per step. Move to warp-windows-2025-x64-<size> first, which upgrades the operating system while holding Visual Studio at 2022. When that lane has been green for a week, move to warp-windows-2025-vs2026-x64-<size> to change the toolset. A failure after the first step points at the operating system; a failure after the second points at the compiler or the SDK.

A scheduled matrix runs both candidate steps beside the current one, which gives you the evidence for both moves at once:

name: windows-image-compat

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

jobs:
  compat:
    strategy:
      fail-fast: false
      matrix:
        image:
          - warp-windows-latest-x64-16x
          - warp-windows-2025-x64-16x
          - warp-windows-2025-vs2026-x64-16x
    runs-on: ${{ matrix.image }}
    steps:
      - uses: actions/checkout@v4
      - uses: microsoft/setup-msbuild@v2
      - run: msbuild Contoso.sln /p:Configuration=Release /m
      - run: dotnet test Contoso.sln --configuration Release

fail-fast: false keeps the other legs running when one image fails, which is the point of the matrix. Set /m on every MSBuild invocation, because without it MSBuild builds one project at a time and a 16 vCPU or 32 vCPU runner mostly buys idle cores.

Rolling back is one line in runs-on, and because the images are separate rather than versioned in place, the old lane is still there to roll back to.

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. Key the NuGet cache on a committed lock file with hashFiles('**/packages.lock.json') so the key changes only when the resolved dependency graph changes, and cache the global packages folder at ~\.nuget\packages rather than per-project folders. MSBuild caching on GitHub Actions Windows runners goes through the rest of the Windows caching surface.

Watching the switch

Two tools help here. CI observability gives you per-job duration across the image labels, so the nightly matrix produces a trend rather than a pass or fail. The Action Debugger opens a session on the runner for the failure that only reproduces on one image.

Where to go next

• Windows runners for GitHub Actions, sizes and pricing covers the full Windows fleet, its shapes, and its rates.
• MSBuild caching on GitHub Actions Windows runners covers NuGet and build output caching in detail.
• Run .NET builds and tests on GitHub Actions walks the full .NET workflow across platforms.
• Build Unity projects on GitHub Actions covers the Windows editor and build toolchain.
• The cloud runners documentation is the source of record for every label above.

FAQ

Which WarpBuild runner label gives me Visual Studio 2026?

The warp-windows-2025-vs2026-x64-<size> labels, in sizes 4x, 8x, 16x, and 32x. They run the Windows Server 2025 base image with Visual Studio 2026 installed in place of Visual Studio 2022. Every other Windows label carries Visual Studio 2022.

Are the vs2026 labels permanent?

They are transitional. The documentation states that Visual Studio 2026 may become the default for the Windows Server 2025 runners in a later update, which follows GitHub's own rollout of the Windows Server 2025 with Visual Studio 2026 image. Pin the label you want and watch the changelog for the default switch.

Does a Visual Studio 2026 runner cost more than a Visual Studio 2022 runner?

No. The rate depends only on the machine shape: $0.016 per minute at 4 vCPU, $0.032 at 8 vCPU, $0.064 at 16 vCPU, and $0.128 at 32 vCPU, across all three Windows image families.

How do I move a job from Windows Server 2022 to Windows Server 2025 safely?

Move to warp-windows-2025-x64-<size> first, which changes the operating system while keeping Visual Studio 2022. Once that lane is green, switch to warp-windows-2025-vs2026-x64-<size> to change the toolset. Two moves keep one variable in play at a time.