Skip to contentCECO LabDigital lab / web engineering
CAESEN
Request proposal
NRS Workbench

Guide / GitHub Actions

How to work with GitHub Actions self-hosted runners on Windows

A self-hosted runner is a machine you deploy and manage to execute GitHub Actions jobs. On Windows that can be a development PC, server or dedicated host. You gain control over hardware, tools and network access, but you also own maintenance, availability and security.

Editorial author · CECO LabUpdated · 30/09/2026Windows · GitHub Actions

01 / Context

When a self-hosted runner makes sense

01

Environment control

You can use hardware, SDKs, tools and local services that are not available on a GitHub-hosted runner.

02

Local responsibility

Operating-system updates, dependencies, disk space and machine hygiene become your responsibility.

03

Not a clean machine per job

A self-hosted runner can retain state between jobs. Do not assume the same isolation as a fresh ephemeral hosted runner.

04

Windows is supported

GitHub documents self-hosted runners on Windows and lets you configure them interactively or as a Windows service.

02 / Setup

Setup and service mode on Windows

GitHub generates the download, configuration and registration commands under Settings → Actions → Runners for the target repository or organization. The registration token is time-limited. On Windows, configuring the runner as a service requires an administrator shell.

  • Download and configure the runner from the instructions generated for the repository or organization that should receive it.
  • If the runner should operate as a Windows service, choose that during initial configuration; changing it later may require reconfiguration.
  • Keep Windows and installed software patched. GitHub updates the runner application, but it does not maintain the rest of the host.
  • Do not copy registration tokens or runner credentials into monitoring tools, screenshots or external configuration files.
GitHub Docs: self-hosted runnersGitHub Docs: adding a self-hosted runnerGitHub Docs: secure use of GitHub Actions

03 / Queue and labels

How jobs are routed and queued

GitHub looks for an online, idle runner that matches the labels and groups declared in runs-on. If none is available, the job remains queued until a compatible runner comes online. This matters when you have several local runners or deliberately keep only part of the pool connected.

What to watch on a host with several runners

  • Which runners are READY, BUSY, STOPPED or in an error state.
  • Whether runner labels and GitHub target match the jobs you expect it to receive.
  • Host CPU, memory and disk use when two jobs compete for the same machine.
  • Local runner logs when a job does not start, stalls or ends without a trustworthy terminal result.

04 / Local management

Where NRS Workbench fits

NRS Workbench does not register runners with GitHub and does not replace GitHub's setup flow. It works with already configured local runners and brings state, control, diagnostics and retained local history into one Windows application.

  • Start, stop and restart interactive runners or runners configured as Windows services.
  • Local READY, BUSY and STOPPED states plus diagnostics from runner files.
  • Optional Smart Queue that can keep one or two runners connected and rotate idle runners without intentionally interrupting active jobs.
  • History derived from local Worker logs: it is runner-processed job history, not complete GitHub account history.
  • Host CPU, RAM and disk use alongside runner activity.
View the NRS Workbench technical sheetDownload NRS Workbench

05 / Checklist

Checklist before leaving it unattended

  1. 01

    Confirm the runner is online in GitHub and its labels match the workflow.

  2. 02

    Decide whether it should run interactively or as a Windows service.

  3. 03

    Limit who is allowed to execute workflows on that machine.

  4. 04

    Avoid letting two heavy jobs exhaust CPU, RAM or disk on a shared host.

  5. 05

    Review logs, free disk space, updates and workflow-exposed credentials periodically.

06 / Security

Security: the most important boundary

GitHub warns that a persistent self-hosted runner can be compromised by untrusted workflow code and recommends extreme caution with public repositories. NRS Workbench does not sandbox jobs or make unknown pull-request code safe to execute. Workflow policy remains the first line of defence.