GitHub Actions self-hosted runner: guía completa de despliegue en entorno privado

En marzo de 2026 GitHub publicó un aviso discreto: los self-hosted runners en repos privados pasan a cobrarse a $0,002/min. Parece poco, pero son $0,12/hora y $12 por 100 horas al mes.

Muchos se quedaron pensando: ¿no eran gratis? Al mismo tiempo, GitHub-hosted bajó ~40%. Equipos empezaron a recalcular: ¿self-hosted o hosted?

El precio es una pieza. Si el código debe tocar una BD interna o el build necesita 32 GB de RAM, GitHub-hosted no alcanza. Ahí self-hosted no es opción, es requisito.

Este artículo compara tres despliegues (servidor, Docker, Kubernetes), seguridad y la herramienta Runner Fleet. Tanto si buscas ahorro, control o cumplimiento.

¿Por qué self-hosted runner?

Qué es

En resumen: tu máquina (física, VM o incluso Raspberry Pi) ejecutando jobs de GitHub Actions. GitHub-hosted es entorno cloud desechable; self-hosted es tu escenario, tus reglas.

El runner es open source en actions/runner. Lo instalas, lo registras en repo u organización, y GitHub envía tareas.

Diferencia con GitHub-hosted

No es solo «quién pone el servidor».

GitHub-hosted: entorno nuevo cada build, destruido al terminar. Limpio y seguro, pero arranque frío lento y software limitado. ¿Compilador raro? No. ¿BD de pruebas en intranet? Imposible.

Self-hosted: entorno persistente, software a medida, caché local, builds más rápidos. Pero tú operas y depuras.

Dimensión	GitHub-hosted	Self-hosted
Entorno	Nuevo cada vez	Persistente
Arranque frío	1-2 min	Segundos
Personalización	Limitada	Total
Seguridad	Aislamiento gestionado	Debes endurecer
Costo	Por minuto	Hardware + operaciones

Precios 2026

Antes de marzo 2026, self-hosted en privados era gratis. Después: $0,002/min en repos privados.

50 CI/día × 10 min = 15.000 min/mes ≈ $30. Un año ≈ $360, precio de un buen VPS.

Paralelamente, GitHub-hosted bajó ~40%. ¿Empujar a la nube? No tan rápido: en repos públicos self-hosted sigue gratis.

Cuándo tiene sentido

Acceso a intranet: CI que toca BD, API o registry privados.

Hardware especial: GPU, 128 GB RAM. Estándar hosted: 7 GB, 2 vCPU.

Mucho volumen de CI: cientos de runs/día; máquinas propias pueden compensar.

Cumplimiento: finanzas, salud — build solo en red propia.

Equipos pequeños con poco CI: GitHub-hosted suele bastar. Si encajas en los casos anteriores, self-hosted entra en agenda.

Tres esquemas de despliegue

Esquema 1: servidor tradicional

Lo más directo: Linux, descargar runner, configurar, ejecutar.

Mi primer despliegue: CentOS 7, SSH, documentación de GitHub. Media hora y «Online» en la UI.

Pros: simple, sin Docker/K8s, estable.

Contras: mantenimiento manual, reinicios, escalado = nueva máquina.

Ideal: 1-2 runners, presupuesto ajustado.

Esquema 2: Docker

Runner en contenedor; tras cada job, contenedor nuevo. Más seguro — si un script rompe el entorno, borras y recreas.

Modos: contenedor único o Docker-in-Docker (DinD). DinD permite builds de imágenes pero con riesgos; GitHub pide cautela.

Pros: aislamiento, limpieza fácil, Compose para varios runners.

Contras: riesgo DinD, orquestación parcialmente manual.

Ideal: escala media, equipo con Docker.

Esquema 3: Kubernetes + ARC

Recomendación oficial a gran escala. Actions Runner Controller (ARC) es un Operator que gestiona el ciclo de vida.

Defines cuántos runners; crea Pods, ejecuta, destruye. Escala con cola, reduce en idle.

AWS lo documentó en enero 2025 para empresas en su nube.

Pros: autoescalado, menor operación a largo plazo, ecosistema K8s.

Contras: curva K8s, Helm, CRD.

Ideal: decenas o cientos de runners, infra K8s existente.

Comparación y elección

Dimensión	Servidor	Docker	K8s ARC
Dificultad	Baja	Media	Alta
Aislamiento	Débil	Bueno	Muy bueno
Autoescalado	No	Limitado	Completo
Costo operativo	Alto	Medio	Bajo (automatizado)
Curva	Baja	Media	Alta
Escala	1-5	5-20	20+

Recomendación:

Pequeño (1-5 personas): servidor tradicional.

Medio (10-30, decenas de builds/día): Docker + Runner Fleet.

Grande (30+, miles de minutos CI): K8s ARC.

No hay «óptimo universal», solo el que encaja con equipo y stack.

Buenas prácticas de seguridad

Repos públicos: zona prohibida

GitHub advierte:

«Los self-hosted runners casi nunca deben usarse en repositorios públicos» — GitHub Docs

Cualquiera puede abrir PR y disparar workflows. En intranet, código malicioso con acceso a secretos y movimiento lateral.

Sysdig (enero 2026) documentó ataques reales usando runners como puerta trasera.

Público → GitHub-hosted o sin CI en self-hosted. Self-hosted → repo privado.

Runner Groups

En privados también hay niveles de confianza. Runners de producción no deben mezclarse con experimentos.

Runner Groups por proyecto/equipo/confianza:

• critical-prod: solo repos core, red aislada
• dev-team: repos de desarrollo
• sandbox: experimentos en sandbox

Un repo comprometido solo alcanza su grupo.

Endurecimiento

Mínimo privilegio: usuario dedicado, no root. Solo software necesario.

Red: sin exposición directa a internet; webhook de GitHub, sin inbound público.

Tokens: rotación; no hardcodear; usar Secrets.

Auditoría: conservar logs de ejecución.

Wiz (abril 2026): muchos entornos demasiado permisivos.

Herramientas

Harden-Runner en el workflow:

steps:
  - uses: step-security/harden-runner@v2
    with:
      egress-policy: audit

Monitoriza salida de red; modos Audit y Block. En self-hosted, Block corta conexiones no autorizadas.

No instales y olvides. He visto equipos con tokens en config en texto plano — tarde o temprano duele.

Runner Fleet

Gestionar muchos contenedores Docker runner dispersos cansa. Runner Fleet (proyecto open source de soulteary) centraliza en UI web: estado, tokens, auto-recuperación.

Funciones útiles:

Monitor agregado: online, tarea actual, historial.

Tokens unificados: configuración en web, sincronización masiva.

Auto-recuperación: reinicio si el contenedor cae.

Modos contenedor y host.

Operaciones en lote: start/stop/restart masivo.

Despliegue rápido:

# Descargar imagen
docker pull soulteary/runner-fleet

# Iniciar servicio (versión simplificada)
docker run -d \
  --name runner-fleet \
  -p 8080:8080 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  soulteary/runner-fleet

Abre http://IP:8080, configura token de GitHub, cantidad de runners y parámetros — creación en lote.

Si usas Docker sin querer K8s, Runner Fleet es buen equilibrio.

Pasos de despliegue

Cinco pasos en Linux (Ubuntu 20.04)

Paso 1: usuario dedicado

# Crear usuario runner, no ejecutar como root
sudo useradd -m runner
sudo passwd runner  # Establecer contraseña

Paso 2: descargar runner

sudo su - runner
cd ~
curl -o actions-runner-linux-x64-2.321.0.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.321.0/actions-runner-linux-x64-2.321.0.tar.gz
tar xzf actions-runner-linux-x64-2.321.0.tar.gz

Paso 3: token de registro

En Settings → Actions → Runners → New self-hosted runner. Token de un solo uso.

Paso 4: configurar

./config.sh --url https://github.com/YOUR_ORG \
  --token YOUR_REGISTRATION_TOKEN \
  --name my-runner-01 \
  --labels linux,ubuntu

Paso 5: servicio systemd

sudo ./svc.sh install runner
sudo ./svc.sh start

Arranque con el sistema; systemd reinicia si falla.

Especificar runner en workflow

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm run build

Con etiquetas:

jobs:
  test:
    runs-on: [self-hosted, linux, ubuntu]
    steps:
      - uses: actions/checkout@v4
      - name: Test
        run: npm test

Verifica estado en GitHub. «Offline» suele ser red o token.

Conclusión

Equipo pequeño, poco CI: GitHub-hosted tras la bajada.

Medio, decenas de builds/día: Docker + Runner Fleet.

Grande, muchos runners: K8s + ARC.

Alta sensibilidad: privado + Runner Groups + Harden-Runner. Público sin self-hosted — advertencia, no sugerencia.

El cambio de precios 2026 altera el cálculo, pero el valor de self-hosted no es solo dinero: intranet, hardware a medida, soberanía de datos.

¿Dolor concreto? Prueba Docker + Runner Fleet; si escalas, migra a K8s.