|

GitLab Runner macOS y Windows 11 VM en un CI híbrido

En pocas palabras: Se instalan dos GitLab Runner con executor shell: uno nativo ARM64 en la Mac Apple Silicon y otro en una VM con Windows 11 (Parallels, UTM o VMware Fusion). Cada uno se registra con tags propios (macos/arm64 y windows/pwsh) y el .gitlab-ci.yml deriva cada job al sistema operativo correcto.

Un GitLab Runner macOS en Apple Silicon más otro runner dentro de una VM con Windows 11 alcanzan para armar un CI híbrido en una sola máquina: cada job llega a su sistema operativo por tags. Lo propone una guía de dev.to del 16 de octubre de 2026.

GitLab Runner es la aplicación que ejecuta los jobs de CI/CD definidos en el .gitlab-ci.yml de un proyecto. Lo instalás en una máquina separada de la que aloja GitLab y lo vinculás con la instancia mediante el registro, que lo habilita para tomar trabajos. Según la documentación oficial, en macOS corre como LaunchAgent del usuario logueado y en Windows como servicio.

En este artículo:

En 30 segundos

  • Dos runners, una instancia: uno nativo ARM64 con executor shell en la Mac y otro en una VM con Windows 11 (Parallels, UTM o VMware Fusion) con shell pwsh.
  • Ruteo por tags: macos y arm64 para el job de Metal, windows y pwsh para el de .NET; un tercer job espera a ambos con needs.
  • Token deprecado: la guía registra con –registration-token, que GitLab planea eliminar en la versión 20.0; los tokens nuevos llevan el prefijo glrt-.
  • Cuidado en macOS: el runner no es root, hay que instalarlo desde una terminal local (no SSH) y activar el login automático.
  • Sin mediciones: los consejos de rendimiento (4 núcleos, 8 GB de RAM) y el ahorro en la nube son afirmaciones del autor, sin cifras.

¿Cómo instalar y registrar GitLab Runner en macOS con Apple Silicon?

Descargás el binario gitlab-runner-darwin-arm64 a /usr/local/bin, le das permiso con chmod +x, lo registrás con executor shell y corrés gitlab-runner install y gitlab-runner start desde una terminal gráfica local, con tu usuario. La documentación de instalación en macOS pide reiniciar el equipo al final.

  • Sudo solo donde hace falta: curl y chmod sobre /usr/local/bin llevan sudo, tanto en la guía como en la doc oficial. Install y start van sin sudo, como el usuario que va a correr los builds.
  • Terminal local, no SSH: el comando install crea un plist en ~/Library/LaunchAgents/gitlab-runner.plist y la configuración queda en ~/.gitlab-runner/config.toml. Por SSH aparece el error “Could not find domain for”.
  • Login automático: el runner arranca cuando el usuario inicia sesión y se detiene cuando la cierra. Para que sobreviva a un reinicio, la documentación indica activar el login automático.
  • Executor shell: la doc lo recomienda para builds de iOS y macOS.

Un detalle: la guía descarga desde gitlab-runner-downloads.s3.amazonaws.com, mientras que la documentación oficial, consultada el 2026-10-16, usa s3.dualstack.us-east-1.amazonaws.com. Copiá la URL de la doc.

El registro de la guía usa –registration-token con –tag-list “macos, arm64, apple-silicon”. Con un token nuevo (glrt-), el equivalente sería esto (adaptación mía del ejemplo no interactivo de la doc, que usa docker; no lo probamos):

gitlab-runner register --non-interactive \
 --url "https://gitlab.com/" \
 --token "$RUNNER_TOKEN" \
 --executor "shell" \
 --description "Apple-Silicon-M-Host"

Eso sí: con un token de autenticación, los tags se definen al crear el runner en la interfaz o la API. Si algo falla con el error “killed: 9” en Apple Silicon, la doc manda a revisar que existan y sean escribibles los directorios de StandardOutPath y StandardErrorPath del plist. Más contexto en la comparativa entre GitHub Actions, GitLab y Jenkins.

¿Cómo configurar un runner de GitLab en una VM con Windows 11?

Dentro de la VM creás C:\GitLab-Runner, descargás gitlab-runner-windows-amd64.exe, corrés install y start en un PowerShell como administrador y registrás con executor shell, shell pwsh y los tags windows, win11 y pwsh. El runner queda como servicio de Windows.

La documentación para Windows suma requisitos que la guía no menciona:

  • Git instalado y la configuración regional del sistema en inglés de Estados Unidos, para evitar problemas de codificación.
  • Permisos de escritura restringidos sobre la carpeta y el ejecutable. Sin eso, un usuario común puede reemplazar el .exe y ejecutar código con privilegios elevados.
  • Cuenta del servicio: la doc recomienda la cuenta integrada del sistema (Built-in System Account).

Ahora bien, hay una inconsistencia para revisar. La guía descarga el binario amd64 y rotula el runner como x86_64, pero la doc también tiene un binario ARM 64-bit, y una VM sobre Apple Silicon suele ser un invitado ARM. Es una inferencia mía, no un dato de la fuente. El propio job de la guía imprime OsArchitecture, así que ahí lo confirmás.

Otro límite: los servicios de Windows no tienen escritorio interactivo. Si tus workflows de RPA o tus pruebas de GUI necesitan escritorio visible, la doc indica iniciar sesión en la VM y correr gitlab-runner.exe run en primer plano, con un tag aparte como windows-gui. Ya lo cubrimos antes en costo y control de los runners autohospedados.

¿Cómo mandar cada job al runner correcto con tags en .gitlab-ci.yml?

Cada job declara los tags del runner que lo debe ejecutar, y GitLab lo asigna al que los tenga todos. En la guía, macos_engine_compile lleva macos y arm64, y windows_rpa_compile lleva windows y pwsh.

DatoRunner macOSRunner Windows 11 VM
Binariogitlab-runner-darwin-arm64gitlab-runner-windows-amd64.exe
Tags de registromacos, arm64, apple-siliconwindows, win11, pwsh
Executorshellshell (shell pwsh)
Tarea en la guíaShaders Metal, Swift y XcodeCompilación .NET/C#, flujos UiPath
gitlab runner macos diagrama explicativo

El job de macOS compila Shaders.metal con xcrun metal, genera Default.metallib con metallib y lo publica como artefacto por una semana. El de Windows corre dotnet build de src\Engine.csproj en Release y publica .\bin\Release\net8.0\*. El tercero, audit_complete, usa needs para esperar a los dos.

Dos observaciones propias. Los jobs están en stages distintos (build_macos y build_windows), así que GitLab los corre en orden, no en paralelo; si querés paralelismo, ponelos en el mismo stage. Y audit_complete no lleva tags: la guía no aclara qué runner lo agarra, y si ninguno acepta jobs sin tag, queda pendiente. Te puede servir nuestra cobertura de cambios en runners ARM64 y macOS.

¿Qué consejos de rendimiento da la guía para la VM de Windows?

La guía da tres consejos para la VM, todos sin mediciones: carpeta compartida para cachear dependencias, arranque headless y reserva de recursos.

  • Carpeta compartida: montar /Volumes/Shared como Z:\ para cachear NuGet y pip entre corridas.
  • Arranque headless: prlctl start “Win11” –headless, un comando de Parallels.
  • Recursos fijos: 4 núcleos de rendimiento y 8 GB de RAM para la VM, así no ahogás el host durante builds paralelos.

Son recomendaciones del autor. Tomalas como punto de partida y medí en tu hardware.

¿Qué limitaciones tiene esta guía antes de usarla en producción?

Tiene cuatro límites: usa un método de registro deprecado, el executor shell no aísla los jobs, las promesas de ahorro no traen números y la Mac de escritorio no es infraestructura de alta disponibilidad. Relacionado: virtualización ligera en Mac con Apple Silicon.

  • Registro deprecado: según la doc de registro, los registration tokens están previstos para su remoción en GitLab 20.0. Desde GitLab Runner 15.0, además, hay que usar una versión de runner compatible con la de GitLab.
  • Sin aislamiento: el shell executor corre los jobs directo en la máquina, con los permisos del usuario del runner (en macOS, con acceso a su keychain). La doc remite a una sección de seguridad que la guía ignora.
  • Promesas sin cifras: la guía habla de “Massive Cloud Savings” y de “No emulation overhead”, pero no trae costos ni tiempos. No hay un número que citar.
  • Mantenimiento ausente: no cubre seguridad, rotación de tokens ni actualizaciones.

Si necesitás un runner Linux que no dependa de una Mac prendida, un servidor virtual de donweb.com es una opción a evaluar para esa parte del pipeline.

¿Qué está confirmado y qué no?

Confirmado por la documentación oficial de GitLab:

  • Los comandos y binarios de descarga para macOS (arm64) y Windows.
  • El modo LaunchAgent en macOS y la ausencia de escritorio interactivo en servicios de Windows.
  • La deprecación de los registration tokens, con remoción prevista en GitLab 20.0.

Sin confirmar:

  • Cuánto se ahorra frente a runners en la nube.
  • El rendimiento de la VM con 4 núcleos y 8 GB.
  • La arquitectura real del invitado Windows (amd64 o ARM).

Propuesta editorial de verificación, que no viene de la guía y no probamos: antes de mandar builds reales, corré un pipeline de humo con un job por runner que imprima la arquitectura (uname -m en la Mac, Get-ComputerInfo en Windows) y un job sin tags para ver quién lo toma.

Errores comunes al armar el runner híbrido

  • Administrar el servicio por SSH: ponele que abrís SSH a la Mac desde tu notebook, corrés gitlab-runner install, te tira “Could not find domain for”, buscás en foros, probás otro binario, reiniciás y seguís igual, cuando la doc dice que ese error aparece justo por usar SSH y se arregla en una terminal de la propia Mac.
  • Pasar tags con un token glrt-: en el modo compatible, GitLab ignora –tag-list, –locked, –access-level y –run-untagged. Definilos al crear el runner.
  • Esperar escritorio en el servicio de Windows: los jobs de GUI fallan o se cuelgan. Usá el runner en primer plano con sesión abierta.
  • Olvidar los prerrequisitos: el job de macOS necesita las herramientas de Xcode y el de Windows el SDK de .NET. La guía no explica cómo instalarlos.

Preguntas Frecuentes

¿Se puede usar una VM con Windows 11 como runner de GitLab CI?

Sí. Instalás GitLab Runner dentro de la VM como servicio de Windows, lo registrás y le asignás tags. La guía lo hace en Parallels Desktop, UTM o VMware Fusion con executor shell y shell pwsh.

¿Qué diferencia hay entre registration token y runner authentication token?

El registration token está deprecado y GitLab planea quitarlo en la versión 20.0. El runner authentication token lleva el prefijo glrt-, se obtiene al crear el runner en la interfaz o la API, y es el método recomendado por la documentación.

¿Qué executor conviene para un runner de GitLab en macOS?

El shell. La documentación oficial indica usarlo para builds de iOS y macOS. Tiene un costo: no aísla los jobs del sistema, que corren con los permisos del usuario del runner.

¿El runner de macOS sigue activo si reinicio la Mac?

Solo si el usuario inicia sesión. El runner es un LaunchAgent que arranca al loguearse y se detiene al cerrar sesión, por eso la documentación indica activar el login automático.

¿Sirve el mismo binario para M1, M2 y M3?

La documentación lista un único binario para Apple Silicon (darwin-arm64) y no distingue por generación de chip. Las fuentes no dicen más sobre M1, M2 o M3.

Conclusión

La idea de la guía sirve: un GitLab Runner macOS nativo más una VM Windows, separados por tags, es un patrón claro para equipos con builds en ambos sistemas. Lo que no sirve tal cual es el registro con –registration-token, que ya tiene fecha de caducidad, ni la omisión de seguridad y de sesión interactiva. Copiá la estructura de tags y el pipeline, registrá con tokens glrt-, verificá la arquitectura de la VM y no cuentes ahorros que nadie midió.

Fuentes

Te puede interesar...