Is Visual Studio Preinstalled on Windows Runners?

Yes, every WarpBuild Windows runner image ships a full Visual Studio Enterprise install, and the runs-on label decides which edition you get: the warp-windows-2025-vs2026-x64-<size> labels carry Visual Studio 2026, while the Windows Server 2022 labels and the other Windows Server 2025 labels carry Visual Studio 2022 (cloud runners documentation, checked on 2026-08-13). The images carry the same tooling as the GitHub-hosted Windows images, so the Visual Studio install, MSBuild, the Windows SDKs, and the MSVC toolsets are on the machine before your first step runs (preinstalled software documentation).

Answer

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

Labels, images, and rates come from the cloud runners documentation, checked on 2026-08-13. Every size carries 256GB of SSD storage, and the 2 vCPU Windows tier was removed on June 8, 2026, so 4 vCPU is the smallest Windows shape. The Windows runner hub lists the aliases and the rest of the fleet detail.

Two things follow from that table. Price does not move with the Visual Studio version, so choosing the image your solution needs is a toolset decision rather than a budget decision. And warp-windows-latest-x64-<size> resolves to Windows Server 2022 today, so a job that names latest is asking for Visual Studio 2022 whether or not that was the intent.

The vs2026 labels are transitional. They run the same Windows Server 2025 base image with Visual Studio 2026 installed in place of Visual Studio 2022, and Visual Studio 2026 may become the default on the Windows Server 2025 labels in a later update, tracking GitHub's rollout of the Windows Server 2025 with Visual Studio 2026 image. Pin the explicit label when the toolset version decides whether your build compiles.

Detail

The edition and the install path differ between the two families

Both families install the Enterprise edition, and they install it in different places. The upstream image readmes record the exact instance, and WarpBuild tracks those images.

Version numbers advance with each image release, so treat the readmes as the per-build inventory and this table as the shape of the answer. The path is the part that breaks workflows. Visual Studio 2026 installs under a major-version directory, 18, rather than a year directory, so any step with a hardcoded \2022\Enterprise path, including a vcvarsall.bat call or a direct MSBuild.exe path, stops resolving the moment the job moves to a vs2026 label. Resolve the path at run time instead of writing it into the workflow.

Component coverage also differs, and three differences account for most first-run failures on a new label:

• The Windows Server 2022 image lists Microsoft.VisualStudio.Component.Windows10SDK.19041 and Microsoft.VisualStudio.Component.Windows11SDK.22621 alongside Windows11SDK.26100. Both Windows Server 2025 images list Windows11SDK.26100 without those two, so a project pinned to an older WindowsTargetPlatformVersion needs either an SDK install step or the Windows Server 2022 label.
• The Visual Studio 2026 image adds Microsoft.VisualStudio.Component.VC.14.44.17.14.x86.x64, which puts the 17.14 MSVC toolset on the machine side by side with the 2026 default. A solution that pins v143 can build on the 2026 image through that component.
• Microsoft.VisualStudio.Component.VC.Tools.ARM, the 32-bit ARM MSVC toolset, is listed on both Visual Studio 2022 images and is absent from the Visual Studio 2026 readme. Cross-compiling to that target keeps the job on a Visual Studio 2022 label.

The Visual Studio image page tracks these per-image differences as the readmes change, and the preinstalled software page links the readme for every WarpBuild image in one place.

Check the workloads from inside the job with vswhere

Reading a readme tells you what the image shipped with. vswhere.exe tells you what is on the machine your job actually booted, and it is the check to run before you assume a component exists. Microsoft ships it with the installer at a fixed path, %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe, on every install of Visual Studio 2017 version 15.2 and later (microsoft/vswhere). The Windows Server 2025 images list vswhere 3.1.7 in their tool inventory.

name: windows-build
on:
  pull_request:
    branches: [main]

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

      - name: Record the Visual Studio instance in the job log
        shell: pwsh
        run: |
          $vswhere = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe"
          & $vswhere -latest -products * -format json |
            ConvertFrom-Json |
            Select-Object displayName, installationVersion, installationPath

      - name: Fail early when the MSVC workload is missing
        shell: pwsh
        run: |
          $vswhere = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe"
          $root = & $vswhere -latest -products * `
            -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 `
            -property installationPath
          if (-not $root) {
            throw "The x86 and x64 MSVC toolset is not installed on this image"
          }
          "VSINSTALLROOT=$root" >> $env:GITHUB_ENV

      - name: Build
        shell: pwsh
        run: |
          & "$env:VSINSTALLROOT\MSBuild\Current\Bin\MSBuild.exe" App.sln `
            /m /p:Configuration=Release

Three flags carry the work. -products * widens the search past the Community, Professional, and Enterprise IDEs so Build Tools installs are found as well. -requires <component ID> filters to instances that carry a component, taking the same IDs the image readmes list. -property installationPath prints the root instead of the full record, which is what a later step wants for building a path. Add -prerelease when the instance you need comes from a preview channel, because vswhere skips prerelease instances by default. The -find flag matches file patterns under the selected instances, so -find MSBuild\**\Bin\MSBuild.exe resolves the compiler binary without you writing the version directory yourself.

Running that check as its own step costs a few seconds and puts the toolset that compiled the artifact in the log, which is the record you want when a build starts failing after an image release.

Installing a missing workload at job time is a recurring bill

Runners are ephemeral. Storage is deleted when the runner terminates (cloud runners documentation), so a Visual Studio workload installed by a workflow step is installed again on the next job, and again on every job after that. The cost is the runner rate multiplied by the install time multiplied by the job count.

Read a row as the monthly cost of one minute of install time. A workflow that spends four minutes running vs_installer.exe modify on the 8 vCPU label across 1,000 jobs a month pays $128.00 a month for the install alone, on top of the build it was trying to run, and those four minutes also sit on the wall clock of every pull request.

Selecting the label that already carries the component costs nothing extra, because all three image families price identically at each size. Between warp-windows-2025-x64-8x and warp-windows-2025-vs2026-x64-8x the bill is $0.032 per minute either way. That is the reason to spend the vswhere check once, learn which family your solution needs, and encode it in runs-on rather than in an install step. Where a standalone toolchain is still the right call, such as a container image you build yourself, the Build Tools guide covers that path.

Related Questions

Which Visual Studio edition is preinstalled on the Windows runner images?

Enterprise. The Windows Server 2022 and Windows Server 2025 images carry Visual Studio Enterprise 2022 under C:\Program Files\Microsoft Visual Studio\2022\Enterprise, and the vs2026 images carry Visual Studio Enterprise 2026 under C:\Program Files\Microsoft Visual Studio\18\Enterprise. Per-image component lists are on the Visual Studio image page.

Does the Visual Studio 2026 image cost more per minute?

No. All three Windows image families are priced the same at each size, from $0.016 per minute at 4 vCPU to $0.128 per minute at 32 vCPU, so moving a job from warp-windows-2025-x64-8x to warp-windows-2025-vs2026-x64-8x changes the toolset while the rate stays the same. Sizes and rates are on the Windows runner hub.

How do I check which workloads are installed before the build step runs?

Run vswhere.exe from C:\Program Files (x86)\Microsoft Visual Studio\Installer with -requires and the component ID you need. It prints the installation path when the component is present and nothing when it is absent, so the job can fail in seconds instead of failing inside MSBuild several minutes later.

Pick a Windows label on the Windows runner hub, confirm the components on the Visual Studio image page, and price your own Windows minutes on the pricing page.