01 / Contexto
Cuándo tiene sentido un runner propio
Control del entorno
Puedes trabajar con hardware, SDK, herramientas y servicios locales que no están disponibles en un runner alojado por GitHub.
Responsabilidad local
El sistema operativo, las dependencias, el espacio en disco y la higiene de la máquina pasan a ser responsabilidad tuya.
No es una máquina limpia por job
Un self-hosted runner puede conservar estado entre ejecuciones. No debe asumirse el mismo aislamiento que ofrece una máquina efímera nueva.
Windows es una plataforma soportada
GitHub documenta runners self-hosted para Windows y permite configurarlos de forma interactiva o como servicio.
02 / Instalación
Instalación y servicio en Windows
GitHub genera desde Settings → Actions → Runners las órdenes de descarga, configuración y registro para el repositorio u organización. El token de registro es temporal. En Windows, si quieres instalar el runner como servicio, la configuración debe ejecutarse con privilegios de administrador.
- Descarga el paquete y ejecuta la configuración desde las instrucciones del repositorio u organización que debe recibir el runner.
- Si el runner funcionará como servicio de Windows, decídelo durante la configuración inicial; cambiarlo después puede requerir volver a configurarlo.
- Mantén Windows y el software instalado actualizados. GitHub actualiza la aplicación del runner, pero no administra el resto de la máquina.
- No copies tokens de registro ni credenciales del runner a herramientas de monitorización, capturas o archivos de configuración externos.
03 / Cola y etiquetas
Cómo se asignan y esperan los jobs
GitHub busca un runner online y libre que coincida con los labels y grupos declarados en runs-on. Si no existe ninguno, el job queda en cola hasta que aparezca un runner compatible. Esta lógica importa cuando tienes varios runners locales o no quieres mantenerlos todos conectados a la vez.
Qué conviene observar en una máquina con varios runners
- Qué runners están READY, BUSY, STOPPED o con error.
- Si los labels y el destino GitHub del runner coinciden con los jobs que esperas ejecutar.
- CPU, memoria y disco del host cuando dos jobs compiten por los mismos recursos.
- Logs locales del runner cuando un job no arranca, queda bloqueado o termina sin un resultado claro.
04 / Gestión local
Dónde entra NRS Workbench
NRS Workbench no registra runners en GitHub ni sustituye la configuración oficial. Trabaja sobre runners locales ya configurados y concentra su estado, control, diagnóstico e historial local en una aplicación Windows.
- Inicio, parada y reinicio de runners interactivos o configurados como servicio.
- Estados locales READY, BUSY y STOPPED, además de diagnóstico a partir de los archivos del runner.
- Smart Queue opcional para mantener uno o dos runners conectados y rotar runners inactivos sin interrumpir intencionadamente jobs activos.
- Historial basado en Worker logs locales: es historial de jobs procesados por el runner, no un historial completo de la cuenta de GitHub.
- CPU, RAM y disco del host junto a la actividad de los runners.
05 / Comprobación
Checklist antes de dejarlo trabajando
- 01
Confirma que el runner aparece online en GitHub y que sus labels son los que usa el workflow.
- 02
Decide si debe funcionar de forma interactiva o como servicio de Windows.
- 03
Limita quién puede ejecutar workflows sobre esa máquina.
- 04
Evita que dos jobs pesados saturen CPU, RAM o disco si comparten host.
- 05
Revisa periódicamente logs, espacio libre, actualizaciones y credenciales expuestas al workflow.
06 / Seguridad
Seguridad: el límite más importante
GitHub advierte de que un runner self-hosted persistente puede quedar comprometido si ejecuta código no fiable y recomienda extremar la precaución con repositorios públicos. NRS Workbench no crea aislamiento ni convierte en seguro ejecutar pull requests desconocidas. La política del workflow sigue siendo la primera barrera.