Can I Still Build on Windows Server 2022?

Yes. Windows Server 2022 is a current image in the WarpBuild catalog: warp-windows-latest-x64-<size> resolves to Windows Server 2022 today and warp-windows-2022-x64-<size> is the dated alias for the same machines (cloud runners documentation, checked on 2026-08-13). Windows Server 2025 ships beside it on its own labels, and the preinstalled software documentation publishes the Windows Server 2022 x86-64 tooling list for teams mapping a pipeline across the two.

Answer

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners. The Windows line is x86-64 and covers twelve labels across two Windows Server versions and two Visual Studio generations.

Every row comes from the cloud runners documentation, checked on 2026-08-13. The Windows runner catalog page carries the same rows with vCPU, memory, and storage columns.

Staying on Windows Server 2022 is a one line decision in the workflow file:

name: windows-build

on:
  push:
    branches: [main]
  pull_request:

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

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

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

      - run: dotnet restore
      - run: dotnet build --configuration Release --no-restore
      - run: dotnet test --configuration Release --no-build

The rate depends on the machine shape rather than the image, so a Windows Server 2022 runner costs the same as a Windows Server 2025 runner of the same size: $0.016 per minute at 4 vCPU up to $0.128 per minute at 32 vCPU (cloud runners documentation, checked on 2026-08-13).

Detail

Pin the dated alias rather than latest

latest is a pointer, and pointers move. Writing warp-windows-2022-x64-16x keeps a build on Windows Server 2022 through any future rollover of the latest selector, which matters most for release branches that have to reproduce an artifact months later. Two other Windows facts belong in the same review: the 2 vCPU Windows runners were removed on June 8, 2026, so 4 vCPU is the smallest shape available, and WarpBuild caches are not supported on Windows-based runners, so Windows jobs keep using actions/cache (cloud runners documentation).

Migration checklist for a pipeline pinned to an older image

The Windows images carry the same tooling as the GitHub-hosted equivalents, so the differences between generations are the ones GitHub publishes in its image readmes. These rows come from the Windows Server 2022 image readme and the Windows Server 2025 image readme, checked on 2026-08-13.

Work the checklist in three passes.

Toolchain paths. Grep the workflow and every build script for literal C:\ paths. Visual Studio sits at C:\Program Files\Microsoft Visual Studio\2022\Enterprise on both the 2022 and 2025 images, so that path survives the version move and then breaks on the vs2026 labels, where Visual Studio Enterprise 2026 installs to C:\Program Files\Microsoft Visual Studio\18\Enterprise. Resolve the install root with vswhere instead of hardcoding it. PostgreSQL paths move with the major version, so PGBIN, PGDATA, and PGROOT all change.

SDK versions. Pin every toolchain in the workflow rather than inheriting an image default. The default JDK moves from 8 to 17 between the two images, and PyPy 2.7, 3.7, and 3.8 are gone from the 2025 image in favor of PyPy 3.9 and 3.10. On the Visual Studio side, Component.Xamarin, Component.Unreal, Component.Unreal.Android, and Microsoft.Net.Component.4.7.2.SDK are absent from the 2025 image, while the 4.7.2 targeting pack is still installed. A build that needs a missing component installs it in a step or stays on the 2022 label.

Service dependencies. Any step that starts a service by name needs the new name, so net start postgresql-x64-14 becomes postgresql-x64-17. Windows container builds are the sharper edge: process isolation ties the container base image to the host OS version, and the Windows Server 2022 image preloads the ltsc2022 base layers while the 2025 image readme lists no cached container images. Budget for a pull, and check that your Dockerfile tags match the host.

Run both labels in one matrix with fail-fast: false before you move the pin, so the old image keeps producing artifacts while the new one collects failures. Resource utilization metrics and logs are available on Windows runners for that comparison (feature matrix). Snapshot runners cover Linux x64 and Linux ARM64, so the Windows comparison runs on ordinary ephemeral runners.

When you need a specific base image

Teams with a hardened base, a licensed toolchain, or a pinned Windows build number bring their own image through BYOC. That is the requirement worth stating plainly: custom VM images are a BYOC feature, and the cloud runner fleet does not accept a customer-supplied VM image (feature matrix). BYOC runs on AWS, GCP, and Azure, and Windows runners on BYOC are available on AWS and Azure with GCP marked in progress in the same matrix.

A Windows AMI has to meet three documented requirements before WarpBuild can boot it (custom VM images documentation): aria2 present and reachable through the system PATH, because the default Windows download path is slow; the EC2 instance sysprepped before the AMI is captured; and machine-level environment variables rather than user-scoped ones, since jobs run as runneradmin, the same account GitHub's Windows runners use. There is no additional cost for using custom VM images. The custom runner image guide covers the build loop, and Windows runners on BYOC AWS covers the account setup.

Related Questions

Which label gives me a Windows Server 2022 runner?

warp-windows-latest-x64-<size> resolves to Windows Server 2022 today, and warp-windows-2022-x64-<size> is the dated alias for the same machines. Write the dated alias when the version has to stay fixed through a future latest rollover. Full shapes and rates are on the Windows runner catalog page.

What breaks when a pinned pipeline moves to Windows Server 2025?

Default JAVA_HOME moves from JDK 8 to JDK 17, the PostgreSQL service goes from postgresql-x64-14 to postgresql-x64-17, and the Xamarin, Unreal, and .NET Framework 4.7.2 SDK Visual Studio components are absent from the 2025 image. Mercurial, Subversion, and NSIS are absent as well. The table above lists the full set with links to both image readmes.

Can I bring my own Windows image instead?

Yes, through BYOC. Custom VM images are a BYOC feature rather than a cloud runner feature, so the image lives in your own AWS, GCP, or Azure account. A Windows AMI needs aria2 on the system PATH and has to be sysprepped before capture, as described in the custom VM images documentation and the custom runner image guide.

Do WarpBuild caches work on Windows Server 2022 runners?

No. WarpBuild caches are not supported on Windows-based runners (caching documentation). Use actions/cache in the workflow for NuGet packages and MSBuild output, the same way a GitHub-hosted Windows job would.

Pick a label from the Windows runner catalog, price the change against your own job minutes on the pricing page, and move to your own base image with Windows runners on BYOC AWS when the fleet image is nearly right for your build.