123% m谩s CVE notificadas al d铆a en 2026 que el a帽o pasado.

Coste

Runners autoalojados de GitHub Actions frente a runners gestionados de CRACI

Los runners autoalojados parecen gratuitos en la factura. El coste real son los hosts, las horas dedicadas a mantenerlos parcheados y el refuerzo que, seg煤n la propia GitHub, necesitan. Esto es lo que implica gestionar los suyos propios, con un modelo de costes que puede rellenar con sus cifras.

Actualizado el

驴Qu茅 es un runner autoalojado de GitHub Actions?

Un runner autoalojado es una m谩quina que usted despliega y gestiona y que ejecuta jobs de GitHub Actions en lugar de una VM alojada por GitHub. Puede ser un servidor f铆sico, una m谩quina virtual o un contenedor, on-premise o en su cuenta de nube, y GitHub indica que usted es responsable de la m谩quina y de todo su software.

  • Registro: un runner se registra en un solo repositorio, organizaci贸n o empresa a la vez. Reg铆strelo a nivel de organizaci贸n y use grupos de runners para compartirlos entre repositorios.
  • Plataformas: la aplicaci贸n de runner admite distribuciones Linux habituales, Windows 10, 11 y Windows Server, y macOS 11 y posteriores, en x64 y ARM64.
  • Red: el runner se conecta a GitHub mediante HTTPS saliente por el puerto 443.
  • Actualizaciones: la aplicaci贸n de runner debe actualizarse en un plazo de 30 d铆as desde cada nueva versi贸n. Se actualiza sola a menos que desactive esa opci贸n.
  • L铆mites: un job puede durar hasta 5 d铆as, frente a 6 horas en los runners alojados por GitHub, y un job en cola durante m谩s de 24 horas falla.
  • Escalado: Actions Runner Controller (ARC), un operador de Kubernetes, escala los runner scale sets con el n煤mero de workflows en ejecuci贸n. Los runners registrados con --ephemeral aceptan un solo job.

Por qu茅 los equipos autoalojan

Los equipos autoalojan para reducir los costes por minuto, para llegar a sistemas internos o a hardware espec铆fico, y para usar capacidad que ya pagan. Adem谩s, los runners m谩s grandes de GitHub no pueden usar los minutos incluidos, as铆 que las m谩quinas grandes salen caras en los runners alojados.

GitHub no cobra hoy por minuto por los runners autoalojados. Anunci贸 un cargo de plataforma en la nube de $0.002 por minuto para los runners autoalojados a partir del 1 de marzo de 2026 y despu茅s lo aplaz贸 para tomarse tiempo y reevaluar su enfoque. A septiembre de 2026, la documentaci贸n de facturaci贸n de GitHub describe el uso autoalojado como gratuito. Lo que GitHub no paga es todo lo que rodea al runner.

Las tres partes del coste del autoalojamiento

El coste del autoalojamiento es infraestructura, tiempo de ingenier铆a y refuerzo de la seguridad. Solo la primera aparece en una factura.

Infraestructura

Los hosts se pagan tanto si ejecutan jobs como si est谩n inactivos, as铆 que se dimensionan para la hora de m谩s actividad. A帽ada el almacenamiento para cach茅s e im谩genes, el tr谩fico de red y lo que use para monitorizar y autoescalar la flota.

Tiempo de ingenier铆a

La documentaci贸n de GitHub es directa sobre la responsabilidad: con los runners autoalojados, usted es responsable de actualizar el sistema operativo y todo el resto del software. En la pr谩ctica, eso tambi茅n significa actualizaciones de versi贸n del runner, deriva de im谩genes entre hosts, limpieza de disco, scripts de autoescalado y alguien de guardia cuando la cola deja de avanzar.

Refuerzo de la seguridad

La gu铆a de seguridad de GitHub para runners autoalojados incluye dos advertencias que merece la pena leer enteras:

Self-hosted runners should almost never be used for public repositories on GitHub, because any user can open pull requests against the repository and compromise the environment. GitHub Docs, Secure use reference
Self-hosted runners for GitHub do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. GitHub Docs, Secure use reference

GitHub recomienda runners just-in-time que ejecuten como m谩ximo un job antes de eliminarse. Hacerlo bien implica m谩quinas ef铆meras, aislamiento entre jobs, controles sobre el tr谩fico de red saliente y un manejo cuidadoso de los secretos. Cada una de estas cosas es trabajo que usted dise帽a, construye y mantiene en marcha.

Buenas pr谩cticas para runners autoalojados a escala

La gu铆a de seguridad de GitHub y las pr谩cticas publicadas por AWS para runners a escala coinciden en la misma lista. Cada elemento es un proyecto en s铆 mismo:

  • Runners ef铆meros: un job por m谩quina, para que nada pase de un job a otro.
  • Grupos de runners: separe los runners por repositorio y entorno, idealmente en cuentas distintas.
  • Credenciales de corta duraci贸n: OpenID Connect hacia su nube en lugar de claves de acceso de larga duraci贸n.
  • Control de egress: limite a qu茅 puede llegar un job, no solo lo que ejecuta.
  • Tiempo de arranque: pools precalentados e im谩genes personalizadas, porque las m谩quinas ef铆meras tardan m谩s en arrancar.
  • Coste: instancias spot con una alternativa para los jobs de larga duraci贸n.
  • Monitorizaci贸n: m茅tricas de jobs en cola, en ejecuci贸n y completados, con alertas.

En CRACI, la primera y la cuarta vienen con el runner: cada job se ejecuta en una m谩quina virtual aislada bajo una pol铆tica de egress que se valida antes de que empiece el job y que, si falla, bloquea.

Un modelo de costes para rellenar

Coste mensual autoalojado = coste de hosts + (horas de mantenimiento y refuerzo 脳 su coste por hora)

Coste mensual de CRACI (runners de 2 vCPU) = minutos de build 脳 $0.004

La f贸rmula de CRACI usa la tarifa de la p谩gina de precios. CRACI solo cobra por los minutos de build, sin cuota mensual ni cargos por SBOM. Consulte la p谩gina de precios para ver las cifras actuales.

Ejemplo A

Datos ilustrativos, no benchmarks. 60.000 minutos de build al mes en runners de 2 vCPU, $350 al mes en hosts para runners y 8 horas al mes de mantenimiento a $85 la hora.

  • Autoalojado: $350 + (8 脳 $85) = $350 + $680 = $1,030 al mes
  • CRACI: 60.000 脳 $0.004 = $240 al mes

Ejemplo B

Datos ilustrativos, no benchmarks. Los mismos 60.000 minutos, pero los hosts cuestan $115 al mes y el mantenimiento lleva 2 horas a $85 la hora.

  • Autoalojado: $115 + (2 脳 $85) = $115 + $170 = $285 al mes
  • CRACI: $240 al mes

En el ejemplo B, ambos est谩n cerca solo en c贸mputo. Es un resultado real para equipos con hosts baratos y una configuraci贸n estable. Para hallar su propio punto de equilibrio, reste el coste de sus hosts a la cifra de CRACI y divida el resultado entre su coste por hora. Con los hosts del ejemplo B, son ($240 menos $115) 梅 $85, o alrededor de 1,5 horas de mantenimiento al mes.

Hay dos cosas que la f贸rmula no muestra. Primero, la cifra de CRACI incluye m谩s que c贸mputo (consulte la secci贸n siguiente). Segundo, las horas son el dato que m谩s equipos subestiman. Cuente las actualizaciones de im谩genes, los parches de seguridad, el escalado, la limpieza de disco y el tiempo dedicado a jobs fallidos, no solo la configuraci贸n inicial.

Lo que los runners autoalojados no le dan

Un runner autoalojado ejecuta su job, pero no registra lo que hizo el job. En los runners de CRACI, cada build genera evidencias mientras se ejecuta:

  • Una SBOM del build en CycloneDX o SPDX, a partir de un proxy que entiende de paquetes y observa lo que descarga el job, incluidos los paquetes restaurados desde cach茅s de CI. La completitud se indica por job y por cach茅.
  • Pol铆tica de egress de red, de denegaci贸n o permiso por defecto, con 24 presets de fuentes de software integrados y fuentes personalizadas tipadas. Las pol铆ticas se validan antes de que empiece el job y, si fallan, bloquean. Las infracciones activan alertas.
  • Una traza de red por job, disponible a trav茅s de la API.
  • Datos de procedencia, disponibles a trav茅s de la API.
  • Seguimiento de vulnerabilidades entre builds y repositorios, con las SBOM monitorizadas reevaluadas continuamente.

Puede construir partes de esto en runners autoalojados con su propio proxy, sus herramientas de SBOM y su registro de red. Si lo hace, el tiempo de construirlo y mantenerlo debe figurar en el modelo de costes anterior.

CRACI Runners autoalojados
Qui茅n parchea el SO y el runner CRACI Usted
Aislamiento de jobs Cada job se ejecuta en una m谩quina virtual aislada Depende de su configuraci贸n; GitHub no garantiza m谩quinas limpias y ef铆meras
Egress de red Pol铆ticas de organizaci贸n con denegaci贸n por defecto disponible, validadas antes de que empiece el job; si fallan, bloquean El firewall o proxy que usted construya y mantenga
SBOM Registrada durante el build, con la completitud indicada por job y por cach茅 Una herramienta aparte que se a帽ade a cada pipeline
Procedencia Datos de procedencia a trav茅s de la API; sin firmar Herramientas de firma y atestaci贸n que usted a帽ade
Facturaci贸n Por segundo de tiempo de job Los hosts cuestan lo mismo ocupados o inactivos
D贸nde se ejecutan los jobs Runners gestionados de CRACI en infraestructura bare-metal europea Su propia red, cuenta de nube o hardware
Sistemas operativos Linux en x86-64 y ARM64 hoy; Windows y macOS en la hoja de ruta Cualquier m谩quina en la que se pueda instalar el runner

Lo que CRACI no ofrece

Hoy CRACI no ofrece runners alojados por el cliente ni on-premise; est谩n en la hoja de ruta para Enterprise. Los builds se ejecutan en los runners gestionados de CRACI en infraestructura europea. Si un job debe ejecutarse dentro de su propia red, en hardware de su propiedad o en un entorno aislado (air-gapped), mantenga un runner autoalojado para ese job.

  • Hoy los runners de CRACI son solo Linux; Windows y macOS est谩n en la hoja de ruta. Los builds de macOS y Windows se quedan donde est谩n.
  • x86-64 y ARM64 tienen la misma tarifa.
  • Im谩genes: CRACI Slim, CRACI Slim ARM64 y una imagen Ubuntu 24.04 compatible con GitHub. La virtualizaci贸n anidada est谩 disponible en x86-64 y en versi贸n preliminar en ARM64.
  • GitHub Actions es la integraci贸n de CI compatible.

Una configuraci贸n mixta es habitual. Mover un job es un cambio en su l铆nea runs-on, as铆 que puede mover la mayor铆a de los jobs y mantener unos pocos en runners autoalojados. Solo los jobs en runners de CRACI obtienen SBOM del build y pol铆tica de red.

C贸mo decidir

Decida con sus propias cifras: el coste y las horas de runners del mes pasado, las evidencias que le piden y un workflow real ejecutado en cada opci贸n.

  1. Sume la factura de hosts del mes pasado y las horas que su equipo dedic贸 a los runners, incluidos los incidentes.
  2. Cuente sus minutos de build.
  3. Introduzca ambos datos en las f贸rmulas anteriores.
  4. Enumere las evidencias que le piden (SBOM, procedencia, controles de red) y lo que costar铆a generarlas en sus runners actuales.
  5. Reserve una demo y ejecute un workflow real en CRACI para comparar.

M谩s informaci贸n sobre c贸mo funcionan los runners: integraci贸n con CI/CD, seguridad en CRACI y la documentaci贸n.

Runners autoalojados de GitHub Actions: preguntas frecuentes

Respuestas breves sobre coste, configuraci贸n, seguridad y l铆mites.

驴Qu茅 es un runner autoalojado de GitHub Actions?

Un runner autoalojado es una m谩quina que usted despliega y gestiona y que ejecuta jobs de GitHub Actions. Puede ser f铆sica, virtual, un contenedor, on-premise o en una cuenta de nube. Se instala en ella la aplicaci贸n de runner de GitHub, se registra en un repositorio, una organizaci贸n o una empresa, y se apunta a ella con runs-on: self-hosted o con sus propias etiquetas.

驴Son gratuitos los runners autoalojados de GitHub Actions?

GitHub no cobra por minuto por los runners autoalojados a septiembre de 2026. Anunci贸 un cargo de plataforma de $0.002 por minuto a partir del 1 de marzo de 2026 y despu茅s lo aplaz贸 para reevaluar su enfoque. Usted sigue pagando las m谩quinas, su almacenamiento y su red, y el tiempo necesario para mantenerlas parcheadas y seguras.

驴Puede un runner autoalojado dar servicio a varios repositorios?

Un runner se registra en un solo repositorio, organizaci贸n o empresa a la vez. Para compartirlo entre repositorios, reg铆strelo a nivel de organizaci贸n y controle el acceso con grupos de runners, o ejecute varias instancias de runner en la misma m谩quina, cada una registrada por separado.

驴Qu茅 sistemas operativos pueden ejecutar un runner autoalojado?

GitHub admite la aplicaci贸n de runner en distribuciones Linux habituales como Ubuntu 20.04 y posteriores, Debian 10 y posteriores y RHEL 8 y posteriores, en Windows 10, 11 y Windows Server 2016 a 2022, y en macOS 11 y posteriores. Funciona en x64 y ARM64, y en ARM32 para Linux.

驴Cu谩nto tiempo puede durar un job en un runner autoalojado?

Hasta 5 d铆as, frente a 6 horas en los runners alojados por GitHub. Un job que permanece en cola m谩s de 24 horas falla.

驴Son seguros los runners autoalojados para repositorios p煤blicos?

GitHub dice que los runners autoalojados casi nunca deber铆an usarse en repositorios p煤blicos, porque cualquiera puede abrir una pull request y ejecutar c贸digo en la m谩quina. Su recomendaci贸n son runners ef铆meros just-in-time que ejecuten como m谩ximo un job, adem谩s de aislamiento, control de egress y un manejo cuidadoso de los secretos.

驴Qu茅 hace Actions Runner Controller?

Actions Runner Controller (ARC) es un operador de Kubernetes que orquesta y escala runners autoalojados para GitHub Actions. Los runner scale sets crecen y se reducen con el n煤mero de workflows en ejecuci贸n. Usted sigue operando el cl煤ster, las im谩genes y la red que los rodea.

驴Pueden los runners de CRACI ejecutarse en mi propia red?

Hoy no. CRACI ofrece runners gestionados en infraestructura europea, con runners alojados por el cliente en la hoja de ruta para Enterprise. Los jobs que deban ejecutarse dentro de su red pueden quedarse en runners autoalojados mientras otros jobs pasan a CRACI.

Compare runners con su propia carga de trabajo

Reserve una demo y mueva un workflow real a CRACI. Compare el coste, la velocidad y las evidencias que genera cada build.

Reservar una demo