I'm trying to find a widely recommended reference architecture for deploying Windows self-hosted runners for GitHub Actions on Kubernetes. From what I can tell, the Actions Runner Controller (ARC) may not fully support Windows, or its support may be limited to older APIs. If Kubernetes isn't a practical option, what approaches are people using to run and autoscale Windows runners?
4 Answers
Windows runners can work on Kubernetes, but the setup is fairly involved. You need Windows worker nodes, a custom Windows runner image, and configuration for the Windows pods. It’s technically possible, but it doesn’t seem to be a common or widely standardized architecture.
We run the runner process on Linux and use custom runner-container-hooks to launch workflow pods on Windows nodes. That required quite a bit of customization around copying files and rewriting paths, so it isn’t especially elegant, but it has been stable for us. I’d only choose this route if Kubernetes is a hard requirement and you’re prepared to maintain the integration yourself.
The older ARC Windows setup uses the legacy RunnerDeployment API and requires Windows nodes plus a custom runner image. I wouldn’t treat it as the default reference architecture for newer runner scale sets. For custom autoscaling, the Runner Scale Set Client can support Windows while you manage the underlying VM or host lifecycle yourself.
If Kubernetes isn’t a firm requirement, the simplest approach is usually a Windows VM or physical Windows host with the self-hosted runner installed directly. This gives you a much clearer operational boundary and avoids dealing with mixed-OS node pools and custom container behavior.
That approach sounds useful for teams that need mixed Linux and Windows workloads, but it’s definitely more of an internal platform project than an out-of-the-box ARC deployment.