Registra tu runner en 10 minutos

Tu máquina está en una red privada de Tailscale y no en internet. No hay ningún puerto SSH abierto que encontrar ni nada que blindar. Para entrar necesitas dos cosas, una sola vez.

Instala Tailscale desde tailscale.com/download e inicia sesión. Es gratis para uso personal y para los tamaños de cuenta que necesitan la mayoría de los equipos aquí. Funciona en macOS, Linux y Windows. Después acepta la invitación que te enviamos cuando tu máquina está lista. Te da acceso a esa máquina y a nada más de nuestra red.

Tu portal muestra el comando exacto, con la dirección de tu máquina ya puesta:

ssh runner@100.x.x.x

No hay contraseña ni clave que gestionar: Tailscale se encarga de la autenticación. Si tu cuenta de Tailscale usa un email distinto del de facturación, pide en tu portal que se comparta con ese email.

Tus jobs de CI no necesitan Tailscale. GitHub Actions llega al runner mediante la conexión saliente del propio GitHub. Esto es solo para cuando quieras una shell en la máquina.

SSH cubre el CI. Para cuando un log no basta, puedes llegar a la misma máquina con pantalla compartida por la misma red privada. Así Instruments, el Simulator y la interfaz de Xcode funcionan como en local. Tu portal muestra la dirección, el usuario runner y una contraseña única para tu alquiler.

En un Mac, abre Finder y luego Ir → Conectarse al servidor (⌘K):

vnc://100.x.x.x

En Windows, instala RealVNC Viewer o TightVNC y conéctate a 100.x.x.x:5900. En Linux, funcionan tanto Remmina como TigerVNC, con la misma dirección. Si tu cliente solo pide una contraseña, deja el usuario en blanco.

Esto es lo que la mayoría de los servicios de CI no pueden hacer. Un runner alojado te da logs y nada más. Un fallo que solo se reproduce con Instruments es un fallo que no puedes investigar.

En tu repositorio (u organización) ve a Settings → Actions → Runners → New runner. GitHub muestra un token de un solo uso. Lo pegarás en el comando de abajo. Los runners de organización se comparten entre todos los repositorios de la organización.

Entra por SSH como antes y ejecuta el comando de configuración de tu portal (ya incluye la etiqueta de tu equipo):

cd ~/actions-runner
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO \
  --token <RUNNER_TOKEN> \
  --labels self-hosted,macOS,macrun-unit-01 \
  --unattended

# start it as a service (survives reboots)
./svc.sh install && ./svc.sh start

El daemon runner-agent mantiene este servicio vivo automáticamente. Si se cae, se reinicia en menos de 30 segundos.

Apunta tu workflow al runner. Ese es todo el diff:

 jobs:
   build:
-    runs-on: macos-latest
+    runs-on: [self-hosted, macOS, macrun-unit-01]

Todo lo demás en tu pipeline queda exactamente igual.

Las versiones recientes de Xcode vienen preinstaladas y fijadas con xcodes. Elige una en tu job, o pide una versión nueva desde tu portal (normalmente el mismo día):

- run: sudo xcodes select 26.6
- run: xcodebuild -version

Como la máquina es tuya, las cachés se conservan entre ejecuciones en el disco local. No pagas el peaje de volver a descargarlo todo. Rutas habituales:

~/Library/Developer/Xcode/DerivedData   # build cache
~/Library/Caches/CocoaPods              # pods
~/.gradle  ~/.npm  ~/.gem               # toolchain caches
~/Library/Caches/org.swift.swiftpm      # SwiftPM

Puedes seguir usando actions/cache si quieres claves de restauración deterministas. Pero en la mayoría de los builds de iOS, lo que marca la diferencia es el disco local caliente.

Reinicia, pide versiones de Xcode y gestiona la facturación desde tu portal. ¿Necesitas otra cosa? Responde a cualquier email de MacRun y te contestará una persona.