Can I Run Docker on Windows Runners?

Yes, for Windows containers. A Windows GitHub Actions runner carries a Docker daemon in Windows container mode, so docker build against a Windows base image works on a warp-windows- label, while a Linux container image needs a Linux runner or a remote Docker builder because Linux containers need a Linux kernel underneath (WarpBuild cloud runners documentation, checked on 2026-08-13).

Answer

The Windows runner images carry the same tooling as the GitHub-hosted Windows runners (cloud runners documentation), which includes Docker, and the package list is published in actions/runner-images. What that daemon can build is the part that surprises teams: it serves Windows containers, and it has no Linux virtual machine behind it to serve Linux images.

Route the work by the image you are producing.

Rates come from the cloud runners documentation and the Docker builders documentation, checked on 2026-08-13. WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, so both halves of a split workflow live under the same account and the same bill.

Three GitHub Actions features are Linux-only whatever provider runs the machine: the container: job key, the services: block, and actions that declare runs.using: docker (GitHub Actions workflow syntax reference, checked on 2026-08-13). A Windows job that needs Postgres for an integration test installs it on the runner or talks to a service started by a Linux job in the same workflow.

Here is the split. The Windows work stays on Windows, and the image build goes to a remote Docker builder through a second job:

name: build

on:
  push:
    branches: [main]
  pull_request:

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

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

      - name: Build and test
        run: |
          dotnet build --configuration Release
          dotnet test --configuration Release --no-build

      - name: Publish the service
        run: dotnet publish src/Api -c Release -o out

      - uses: actions/upload-artifact@v4
        with:
          name: api-publish
          path: out/

  image:
    needs: windows-build
    runs-on: warp-ubuntu-latest-x64-2x
    steps:
      - uses: actions/checkout@v4

      - uses: actions/download-artifact@v4
        with:
          name: api-publish
          path: out/

      - name: Build and push on the remote builder
        uses: Warpbuilds/build-push-action@v6
        with:
          context: .
          push: true
          tags: registry.example.com/api:${{ github.sha }}
          profile-name: api-builder

The image job sits on a 2 vCPU Linux runner because the build itself executes on the builder virtual machine while the runner only drives it. Keep that driving step on a Linux job: the WarpBuild builder actions are documented against Linux runner labels, and the Windows job in this workflow needs no Docker daemon at all.

One caveat to plan around before you write the caching steps: WarpBuild cache is available on Linux-based runners and is not supported on Windows-based runners (caching documentation, repeated on the cloud runners documentation). A Windows job caches through actions/cache@v4 instead.

Detail

Why a Windows container is pinned to the host release

Windows containers share the host kernel, so the base image build number and the host build number have to line up. Process isolation requires a matching pair; anything else needs Hyper-V isolation, which runs the container in its own lightweight virtual machine (Microsoft container version compatibility reference, checked on 2026-08-13).

Hyper-V isolation needs nested virtualization on the host, and the WarpBuild support matrix records nested virtualization as unavailable on cloud Windows runners (nested virtualization documentation). The practical rule is one line: pick the label whose Windows Server release matches your base image tag. warp-windows-latest-x64-<size> resolves to Windows Server 2022 for ltsc2022 images, and warp-windows-2025-x64-<size> runs Windows Server 2025 for ltsc2025 images. Both families cover 4, 8, 16, and 32 vCPU with 256GB SSD storage, at $0.016, $0.032, $0.064, and $0.128 per minute (cloud runners documentation, checked on 2026-08-13).

What the remote builder changes

A remote Docker builder is a dedicated build virtual machine with a persistent layer cache on its own disk, reached over the Buildx remote driver with TLS certificates that the action fetches for the job (Docker builders documentation).

Two properties matter when a Windows pipeline hands off an image build. Billing runs per session, measured from the first job start to the last job completion on a profile, so a fan-out of parallel image builds sharing one profile produces one billable stretch rather than one per job. And builder profiles reach 192 vCPU with 384GB of memory, well past the 32 vCPU ceiling of the runner catalog, so a heavy image build does not force you to size the runner for it (Docker builders documentation, checked on 2026-08-13).

What each route costs

Take a repository that merges 400 pull requests a month. Every run compiles and tests on Windows for 8 minutes, then produces a Linux image. Rates below come from the pricing page and the documentation linked above, checked on 2026-08-13.

• Windows build and test on warp-windows-latest-x64-8x: 400 x 8 x $0.032 = $102.40 per month.
• Image built on a Linux runner's local daemon, 6 minutes cold on warp-ubuntu-latest-x64-4x: 400 x 6 x $0.008 = $19.20 per month.
• Image built on a 16 vCPU builder profile in 3 minutes, driven from warp-ubuntu-latest-x64-2x: runner 400 x 3 x $0.004 = $4.80, builder 400 x 3 x $0.06 = $72.00, for $76.80 per month.

The builder line buys the persistent layer cache and the session billing above it. Two image builds that run in parallel on the same profile share one session, so a monorepo that pushes three images per run does not triple that $72.00.

Related Questions

Can a Windows GitHub Actions runner build a Linux container image?

Not with its local daemon, which serves Windows containers. Put the Linux image build in a second job on a Linux label such as warp-ubuntu-latest-x64-4x, or send it to a remote Docker builder driven from that job.

Do the container and services workflow keys work on a Windows runner?

No. GitHub Actions restricts the container: job key, the services: block, and Docker container actions to Linux runners (workflow syntax reference). Install the dependency on the Windows runner, or move those steps to a Linux job.

Which Windows base image tag matches a WarpBuild Windows runner?

Match the tag to the host release: ltsc2022 on the warp-windows-latest-x64 labels and ltsc2025 on the warp-windows-2025-x64 labels. The full label list with sizes and rates is on the Windows runner page.

Does the WarpBuild cache work on a Windows Docker build?

No. WarpBuild cache covers Linux-based runners, and Windows-based runners are outside it, as covered in whether caches work on Windows runners. Use actions/cache@v4 for Windows build state, and let the builder profile hold the layer cache for Linux images.

Start with the labels and rates on the Windows runner page, price the split against your own job minutes on the pricing page, and set up the image half with the Docker builders documentation.