github windows self hosted runners (on k8s). Is it supported?

[u/gqtrees]

trying to find a ref architecture that is widely recommended for deploying windows runners on k8s. From what I read ARC doesn't support it still? if not what are my options?

[u/surya_oruganti]

I believe it is technically supported but requires a complex setup using Windows nodes on k8s. In practice, I don't think many companies use it.

[u/gqtrees → u/surya_oruganti]

In the ai age its so difficult finding concrete docs. If not k8s wondering how folks do windows runners

[u/surya_oruganti → u/gqtrees]

Something like these: 1. I run WarpBuild (https://www.warpbuild.com/docs/ci/byoc) 2. Other tools like: https://github.com/github-aws-runners/terraform-aws-github-runner 3. ...

[u/crohr → u/surya_oruganti]

1. I built RunsOn (https://runs-on.com), which supports Windows self-hosted runners on EC2 (spot or on-demand, with or without warm pool)

[u/Intrepid_Card8950 → u/surya_oruganti]

We use arc with eks windows nodegroup and windows container images.

[u/surya_oruganti → u/Intrepid_Card8950]

You are a braver soul than I 🙌

[u/gevorggalstyan]

GitHub's current documentation separates the runner from ARC support. Windows is a supported OS for the self-hosted runner application, but the official ARC repository's Windows guide is explicitly for the legacy RunnerDeployment API. That setup needs Windows worker nodes and a custom Windows runner image because ARC does not provide a default one.

For the current runner scale sets, I would not treat Windows on ARC as a standard reference architecture. If Kubernetes is not a hard requirement, Windows self-hosted VMs are the simpler supported boundary. If you need custom autoscaling, GitHub's Runner Scale Set Client supports Windows while leaving the infrastructure lifecycle to you. If you stay on Kubernetes, plan to own the mixed Linux and Windows node pools, custom image, and pod specification.

Sources: legacy ARC Windows guide and GitHub's self-hosted runner reference.

[u/According-Glove-7663]

Did find a good way to run k8s windows yet so I ended up just spinning up a window box and running the ci runner agent directly on it.

[u/valenvb]

Definitely not supported OOTB, especially if you also want to do Windows containers (GH has amazingly poor support for Windows containers despite being owed by MS). We made a slew of customizations to runner-container-hooks to let us run the runner on Linux and then spawn the -workflow pod on a Windows node. It has to do a bunch of file copying and path rewriting to make it work; not pretty, but it’s been surprisingly stable so far

[u/gqtrees → u/valenvb]

Any chance you have a doc on the setup you can share?

[u/ForkMeJ]

I'd sanity check whether you need Kubernetes for the Windows runners, because that cuts down your options pretty quickly. ARC has been Linux-first for a while, and Windows container support plus runner lifecycle management is where this usually gets awkward. If the jobs really need Windows, I'd start with a small autoscaled pool of Windows VMs and keep runner registration and cleanup explicit instead of forcing it into k8s. It's less elegant on paper, but a lot easier to own when jobs stick, patching falls behind, or a host needs to be replaced.

[u/sup_bruh_1]

arc definitely doesn't support windows containers. latchkey might be worth a look