Cómo cambiar de proveedor de runners de GitHub Actions: etiquetas, cachés, secretos, facturación y fallback

Esta guía es neutral respecto a los proveedores. Explica qué se traslada cuando cambia de proveedor de runners de GitHub Actions, qué falla con más frecuencia y cómo dar marcha atrás. Nosotros desarrollamos CRACI, uno de esos proveedores; aparece donde se aplica un hecho documentado, y en su propia sección al final. Para elegir primero un proveedor, consulte la comparativa de proveedores de runners de GitHub Actions y las alternativas a los runners alojados por GitHub.

Qué cambia y qué se queda al cambiar de proveedor

GitHub Actions tiene dos mitades. GitHub es el plano de control: almacena el repositorio y los archivos de workflow, lanza los disparadores, guarda los secretos, asigna los jobs, muestra los logs y los checks, conserva los artefactos y emite los tokens OIDC. El runner de CI es donde se ejecuta un job: una máquina con una imagen, CPU, disco, una ruta de red hacia internet y normalmente una caché local. GitHub asigna un job a un runner, le entrega los secretos del job cuando empieza y el runner devuelve los logs en streaming.

Un proveedor de runners sustituye solo la segunda mitad.

Elemento	Se queda en GitHub	Pasa al proveedor
Repositorio, archivos de workflow, disparadores	Sí	No
Almacén de secretos	Sí	Los secretos se entregan a la máquina del proveedor al inicio del job
Asignación de jobs, logs, interfaz de checks	Sí	El runner devuelve los logs en streaming
Artefactos de actions/upload-artifact	Sí	No
Emisor del token OIDC	Sí	No, pero el token indica que el runner es autoalojado
Máquina, imagen, CPU, memoria, disco	No	Sí
Ruta de red de salida y direcciones IP	No	Sí
Almacenamiento de caché	Depende del proveedor	Depende del proveedor
Facturación por minuto de los jobs trasladados	No	Sí

Un runner de terceros se registra en GitHub como runner autoalojado. Por eso se le aplican las reglas de GitHub para runners autoalojados: cómo enrutan los jobs las etiquetas, cómo limitan el acceso los grupos de runners, cómo lo describe el token OIDC y cómo lo factura GitHub.

El cambio de runs-on y las etiquetas

GitHub busca un runner que coincida con las etiquetas y los grupos de runs-on del job. Si no hay ningún runner coincidente en línea, el job se queda en cola hasta que aparezca uno; si un runner asignado no recoge el job en 60 segundos, el job vuelve a la cola; y un job que permanece en cola más de 24 horas falla (la referencia de GitHub sobre runners autoalojados). Una errata en una etiqueta, o una app del proveedor que no está instalada en el repositorio, se manifiesta como un job que nunca empieza.

Los proveedores codifican la máquina de una de dos formas:

• En la etiqueta. Ubicloud usa etiquetas como ubicloud-standard-2, Blacksmith blacksmith-2vcpu-ubuntu-2404 y Avrea avrea-ubuntu-latest-2-vcpu, con arm en la etiqueta para las máquinas ARM. Cambiar de tamaño significa cambiar de etiqueta.
• En un paso de configuración. CRACI usa una sola etiqueta, runs-on: craci, y el paso cracicorp/setup@v1 selecciona el tamaño (de 1 a 32 unidades de cómputo de 1 vCPU y 3 GB, 2 por defecto), la imagen, la política de red o una plantilla de runner de la organización por su slug. Si CRACI no puede interpretar una entrada, ejecuta el entorno por defecto y escribe un aviso en el log del job; una imagen o plantilla desconocida se rechaza.

Haga que el cambio sea una variable

Ponga la etiqueta en una variable de repositorio u organización en lugar de escribirla a mano. Así, avanzar o volver atrás es un cambio de configuración, no una pull request en cada repositorio.

jobs:
  build:
    # Falls back to GitHub-hosted when the variable is not set
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: make build

  deploy:
    needs: build
    # Stays on GitHub-hosted until you decide to move it
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

La elección es por job, así que los jobs de build y de test pueden trasladarse mientras un job de despliegue se queda. Las variables pueden definirse a nivel de organización y sobrescribirse por repositorio, de modo que un solo ajuste puede trasladar un grupo de repositorios y un repositorio puede quedarse fuera.

Workflows reutilizables

Si el mismo pipeline está copiado en muchos repositorios, páselo a un workflow reutilizable que lea el runner de una entrada o de una variable. Cambiar runs-on ahí cambia todos los repositorios que lo llaman. Los rulesets pueden exigir que un workflow se ejecute en los repositorios de una organización, lo que mantiene en uso la versión compartida.

Imágenes de runner: compatibilidad y fijación

La imagen alojada de GitHub incluye un amplio conjunto de herramientas preinstaladas y una caché de herramientas alojada. Los proveedores ofrecen una imagen compatible con la de GitHub o una más ligera. Los jobs suelen depender de cosas que nunca declaran:

• versiones de lenguajes y herramientas de línea de comandos preinstaladas;
• sudo sin contraseña, y systemd para servicios iniciados con systemctl;
• un daemon de Docker en ejecución, con Buildx y Compose;
• la caché de herramientas alojada que las acciones setup-* leen antes de descargar;
• espacio libre en disco para builds grandes.

Regla de decisión: empiece con la imagen compatible con GitHub del proveedor. Pase un job a una imagen ligera solo cuando esté en verde, y añada pasos setup-* explícitos para todo lo que usaba de forma implícita.

Fijación: ubuntu-latest pasa a una nueva versión según el calendario de GitHub, y ubuntu-24.04 fija la versión del sistema operativo, no las versiones de los paquetes. Fije lo que importa dentro del job: acciones de configuración con versiones explícitas e imágenes de contenedor por digest. Pregunte a cada proveedor qué le permite fijar. La propia aplicación de runner tiene que seguir actualizándose para comunicarse con GitHub.

En CRACI, las imágenes son CRACI Slim en x86-64 y ARM64 (Ubuntu 24.04, sin systemd) y una imagen Ubuntu 24.04 completa compatible con GitHub Actions, que se selecciona como ubuntu-24.04 o ubuntu-latest, sigue la imagen de runner Ubuntu 24.04 de GitHub e incluye la caché de herramientas alojada. Todas las imágenes incluyen Docker Engine, Buildx y Compose v2.

Cachés: qué se conserva y qué empieza en frío

Las primeras ejecuciones en un proveedor nuevo suelen ser más lentas, y el motivo habitual es una caché fría, no una máquina lenta. Lo que verá depende de cómo funciona actions/cache (README de actions/cache):

• Una entrada se encuentra por su clave y una versión, que es un hash de las rutas cacheadas y la herramienta de compresión.
• Las entradas tienen ámbito por rama; las de la rama por defecto están disponibles para las demás ramas.
• Por defecto, un repositorio puede tener hasta 10 GB de cachés antes de que se expulsen las entradas más antiguas. Los administradores del repositorio y los propietarios de la organización o de la empresa pueden subir el límite; el uso por encima de 10 GB se factura a la cuenta (GitHub sobre dependency caching).
• Una caché guardada en Windows no se restaura en otro sistema operativo, ni al revés, salvo que se defina enableCrossOsArchive; otra herramienta de compresión también da una versión distinta.

Los proveedores sirven la caché de una de dos formas:

Modelo	Primeras ejecuciones	Contrapartida
El runner usa el servicio de caché de GitHub, como los runners alojados por GitHub	Las entradas existentes se restauran	El tráfico de caché cruza internet entre el proveedor y GitHub
El proveedor sirve la API de caché desde un almacenamiento junto a sus runners	Normalmente vacía hasta que las primeras ejecuciones la llenan, salvo que el proveedor importe las entradas de GitHub o recurra a ellas	Restauraciones más rápidas; las entradas escritas ahí no suelen ser visibles para los runners alojados por GitHub

Lo segundo importa en flotas mixtas y para volver atrás: si devuelve un job a GitHub, también allí puede empezar en frío. Pregunte qué modelo usa el proveedor y dónde se guardan las entradas.

Cómo distinguir una caché fría de un runner lento. Tome un build de Node que cachea un directorio node_modules grande. En la primera ejecución en un proveedor nuevo, actions/cache informa de un fallo, el paso de instalación lo descarga todo y el paso posterior guarda la caché. Desde la siguiente ejecución en la misma rama, el paso informa de un acierto y el paso de instalación se reduce. Compare ejecuciones solo cuando la caché esté caliente: lea la salida cache-hit y mida el paso de restauración y el de instalación por separado del build en sí. Consulte cómo funciona la caché de GitHub Actions para claves, ámbitos y envenenamiento de caché.

En CRACI, actions/cache funciona como hoy, y el registro del build marca por paquete si se restauró de una caché de CI en lugar de descargarse.

Caché de capas de Docker

Mecanismo	Dónde se guardan las capas	Qué debe saber
BuildKit type=gha	La caché de GitHub Actions	Las mismas reglas de ámbito y tamaño que arriba; necesita un builder que lo admita
BuildKit type=registry	Una imagen aparte en su registro	Funciona en cualquier runner y sobrevive a un cambio de proveedor; usted paga el almacenamiento y la transferencia del registro
Caché de capas local del proveedor o disco persistente	Junto a los runners del proveedor	Normalmente la más rápida; se queda atrás si deja al proveedor

Una caché en registro es la opción portable (backends de caché de Docker):

- uses: docker/build-push-action@v7
  with:
    push: true
    tags: ghcr.io/acme/app:latest
    cache-from: type=registry,ref=ghcr.io/acme/app:buildcache
    cache-to: type=registry,ref=ghcr.io/acme/app:buildcache,mode=max

Dos jobs que empiezan a la vez restauran la misma caché y ambos construyen las capas que le faltan. Esto ocurre en cualquier CI, así que no lo interprete como un problema del proveedor.

CRACI ofrece caché de capas de contenedor con una caché de capas local, una caché de capas remota y una caché de bind mount.

Secretos, OIDC y credenciales de nube

GitHub almacena sus secretos y los entrega al runner que ejecute el job. Trasladar un job a un proveedor significa confiarle los secretos de ese job. Pregunte:

• ¿Cada job obtiene su propia máquina virtual, o un contenedor en un host compartido?
• ¿Se destruye la máquina después del job? ¿Se conserva algo?
• ¿Qué logs conserva el proveedor? GitHub enmascara los secretos registrados en los logs de los jobs, y advierte de que el ocultamiento automático no está garantizado para valores transformados; pregunte también por los logs de sistema del propio proveedor.

OIDC sigue funcionando, con un matiz. Es GitHub quien emite el token OIDC, no el runner, así que permissions: id-token: write funciona en cualquier runner. Pero el claim runner_environment del token es github-hosted o self-hosted (la referencia de OIDC de GitHub), y en un runner de terceros es self-hosted. Una política de confianza de la nube que exija github-hosted rechaza el job. Por ejemplo, un workload identity pool de Google Cloud con esta condición de atributo:

# Before: only GitHub-hosted runners in the acme organization
assertion.repository_owner == 'acme' && assertion.runner_environment == 'github-hosted'

# After: drop the runner check, and narrow by repository and branch instead
assertion.repository == 'acme/app' && assertion.ref == 'refs/heads/main'

Quitar la comprobación del runner amplía quién puede obtener credenciales, así que endurezca otra condición al mismo tiempo. Antes del cambio, busque runner_environment en todas las políticas de confianza de la nube y configuraciones de workload identity.

Publicar imágenes: GITHUB_TOKEN con packages: write publica en GitHub Container Registry desde cualquier runner, y los inicios de sesión en registros que usan secretos almacenados funcionan sin cambios.

En CRACI, la GitHub App lee su código y sus ejecuciones de Actions y gestiona los runners que registra para su organización. Cada job se ejecuta en su propia máquina virtual aislada, y CRACI no almacena su código fuente.

Identidad de red: listas de IP permitidas y egress

El nuevo runner sale desde direcciones IP nuevas. Haga una lista de todo lo que filtra por dirección de origen:

• listas de permitidos de bases de datos y repositorios de artefactos;
• API SaaS con restricciones de IP;
• servidores SFTP de socios y servicios internos tras un firewall.

Las opciones son las direcciones IP de egress estáticas o estables del proveedor, o un proxy que usted controle. También es el momento de decidir a qué pueden llegar los jobs: una política de egress en el runner impide que una dependencia comprometida envíe secretos a un host que el build nunca necesitó. Consulte la política de egress de GitHub Actions.

CRACI ofrece un rango estable de IP de egress y una política de egress, de denegación o de permiso por defecto, que se valida antes de que empiece el job y, si falla, bloquea. Sin una entrada network, la plantilla por defecto permite las demás conexiones salientes, así que el control de egress es algo que usted configura.

Flotas mixtas: traslade Linux y deje macOS e iOS donde están

El runner se elige por job, así que un workflow puede ejecutar sus jobs de Linux en un proveedor y sus jobs de macOS en runners alojados por GitHub. Los artefactos subidos con actions/upload-artifact los almacena GitHub, así que un job en un runner puede pasar archivos a un job en otro.

jobs:
  backend:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew test

  android:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v7
        with:
          name: android
          path: app/build/outputs/apk/release/

  ios:
    # Signing and the iOS build stay on GitHub-hosted macOS
    runs-on: macos-latest
    needs: backend
    steps:
      - uses: actions/checkout@v7
      - run: xcodebuild -scheme App -configuration Release archive

Los jobs que se quedan en GitHub siguen consumiendo el uso incluido en su plan, y GitHub los factura por encima de él. CRACI ejecuta Linux en x86-64 y ARM64 hoy, con Windows y macOS en la hoja de ruta, así que una flota mixta con CRACI significa CRACI para Linux y runners alojados por GitHub para el resto.

Fallback cuando un proveedor está caído

GitHub no tiene un fallback integrado entre etiquetas de runner. Si no hay ningún runner en línea para la etiqueta, el job espera y, a las 24 horas, falla. Prepárese:

• El cambio por variable descrito arriba: vuelva a ponerla en ubuntu-latest y las nuevas ejecuciones irán a runners alojados por GitHub.
• Una anulación manual para ejecuciones urgentes: una entrada de workflow_dispatch, leída como runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}.
• timeout-minutes en los jobs, para que un job colgado no retenga un despliegue durante horas.
• Supervisión del tiempo en cola, para detectar cuándo los jobs esperan más de lo normal.

Pregunte a cada proveedor si ofrece un fallback automático y qué lo activa. Prepárese también para la otra dirección: GitHub pone en cola y asigna cada job, así que una caída de GitHub Actions también detiene los jobs en todos los proveedores de runners.

Facturación: ¿sigue cobrando GitHub?

GitHub no cobra por minuto los runners autoalojados, y los runners de terceros se registran como autoalojados, así que los minutos que traslade dejan de aparecer en la factura de GitHub (facturación de GitHub Actions). GitHub sigue cobrando:

• los puestos de su plan;
• el almacenamiento de artefactos y cachés que guarda por encima de lo incluido;
• los jobs que se quedan en runners alojados por GitHub, por encima del uso incluido en su plan, que no se reembolsa.

Durante la prueba pagará dos facturas. Los proveedores cuentan los minutos de build de forma distinta: GitHub redondea cada job al minuto entero, y algunos proveedores miden por segundos. Para dimensionar su uso antes y después, utilice la calculadora de costes de GitHub Actions. CRACI solo cobra por los minutos de build: $0.002 por minuto de vCPU ($0.004 para un runner de 2 vCPU por defecto), medidos por segundos, sin cuota mensual.

Aislamiento de seguridad: qué preguntar a cualquier proveedor

Pregunta	Por qué importa
¿Una máquina virtual por job, o contenedores en un host compartido?	Un host compartido permite que un job comprometido llegue a sus vecinos
¿Se destruye la máquina después del job?	Una máquina persistente arrastra archivos, credenciales y procesos al siguiente job
¿Dónde está el hardware y quién lo opera?	Ubicación de los datos, jurisdicción y los contratos de sus clientes
¿Qué almacena el proveedor y durante cuánto tiempo?	Los logs, las cachés y los datos de red pueden contener material sensible
¿Qué certificaciones tiene?	Su evaluación de proveedores lo preguntará
¿Puede controlar el egress?	Impide que los secretos salgan a través de un paquete malicioso
¿Qué puede leer y cambiar su GitHub App?	Los permisos de la app se aplican a cada repositorio en el que la instale

GitHub dice que los runners autoalojados casi nunca deberían usarse en repositorios públicos, porque cualquiera puede abrir una pull request y comprometer el entorno, y que los runners just-in-time ejecutan como máximo un job antes de eliminarse (la referencia de uso seguro de GitHub). Una máquina virtual nueva por job responde a la mayor parte de esa preocupación.

Las respuestas de CRACI: cada job se ejecuta en su propia máquina virtual aislada sobre infraestructura bare-metal europea. El sistema de gestión de la seguridad de la información de CRACI Corporation Oy, para el desarrollo y la operación de la plataforma CRACI, está certificado en ISO/IEC 27001 por Into Certification, con los detalles en el Trust Center. CRACI almacena metadatos de build, datos de paquetes, trazas de red, SBOM, procedencia, cachés y registros de auditoría, y nunca su código fuente. Consulte a qué puede acceder CRACI y seguridad.

Pruebe primero en un repositorio

1. Elija un repositorio con un workflow de Linux representativo y frecuente, no el pipeline de release.
2. Registre una referencia en runners alojados por GitHub: mediana de duración y de tiempo en cola en las últimas 30 ejecuciones, y minutos facturados.
3. Instale la GitHub App del proveedor solo en ese repositorio.
4. Cambie un job mediante la variable de repositorio, en una rama.
5. Ejecútelo al menos diez veces y descarte las tres primeras como calentamiento de la caché.
6. Compare duración, tiempo en cola, tasa de aciertos de caché, fallos y coste; revise los logs, OIDC y las llamadas salientes.
7. Vuelva atrás cambiando la variable y confirme que el job regresa a los runners alojados por GitHub.

Métrica	Referencia alojada por GitHub	Proveedor	Umbral de aprobación
Mediana de duración del job			Su objetivo, por ejemplo un 30% menos
Mediana de tiempo en cola			No peor que la referencia
Tasa de aciertos de caché tras el calentamiento			Igual que la referencia
Ejecuciones fallidas no causadas por el código			Ninguna
Coste por ejecución			Por debajo de la referencia
OIDC, listas de permitidos y llamadas salientes			Todo funciona

Mida la velocidad en su propio workflow. Cada proveedor publica sus propias cifras, y el único número que decide su caso es el de su pipeline.

Dónde encaja CRACI

CRACI es un runner de GitHub Actions. Sustituye el runner, no GitHub Actions: un job se traslada con runs-on: craci, los tamaños y las imágenes se definen con cracicorp/setup@v1 o con una plantilla de runner de la organización, y las ejecuciones siguen apareciendo en GitHub. CRACI ejecuta los builds aproximadamente el doble de rápido que los runners alojados por GitHub, gracias a un hardware más rápido, tiempos en cola más cortos y la caché.

El motivo para elegirlo frente a otros proveedores es lo que deja cada job: una SBOM de lo que el build descargó, con un estado de completitud, registrada bajo una política de egress que, si falla, bloquea. docs.craci.com ofrece además un prompt para agentes de código que propone un plan de migración por job para sus workflows. Consulte la integración con CI/CD.

Cuándo CRACI no es la respuesta

• Necesita runners de macOS o Windows: están en la hoja de ruta de CRACI.
• Usa GitHub Enterprise Server, que CRACI no admite.
• Su CI es GitLab CI o Jenkins: ambos están en la hoja de ruta.
• Los runners deben estar en su propia cuenta de nube: los runners alojados por el cliente están en la hoja de ruta. RunsOn y la opción de nube propia de WarpBuild lo hacen hoy; consulte CRACI frente a RunsOn y CRACI frente a WarpBuild.
• Su objetivo principal es la observabilidad y la depuración de CI; consulte CRACI frente a Avrea. Para ejecutar sus propios runners, consulte runners gestionados frente a autoalojados.

Cambiar de proveedor de runners: preguntas frecuentes

¿Qué tengo que cambiar para usar otro proveedor de runners de GitHub Actions?

Instale la GitHub App del proveedor y cambie la etiqueta runs-on del job por la del proveedor. Los workflows, los disparadores, los secretos y la interfaz de GitHub siguen igual. Antes de trasladar jobs importantes, revise la imagen del runner, las cachés, las direcciones IP de salida, las políticas de confianza de la nube que usan OIDC, el fallback y la facturación.

¿Se conservan mis cachés de GitHub Actions con un nuevo proveedor de runners?

Depende de desde dónde sirva la caché el proveedor. Si sus runners usan el servicio de caché de GitHub, las entradas existentes se restauran. Si sirve la API de caché desde un almacenamiento junto a sus runners, la caché suele empezar vacía y se llena en las primeras ejecuciones. Pregunte al proveedor qué modelo usa y si las entradas escritas en sus runners son visibles para los runners alojados por GitHub.

¿Funciona la caché de capas de Docker en runners de terceros?

Sí, con cualquiera de tres mecanismos: el backend type=gha de BuildKit, que usa la caché de Actions; una caché en registro con type=registry, que funciona en cualquier runner; o una caché de capas o un disco persistente que el proveedor mantiene junto a sus runners.

¿Puedo mantener los builds de macOS e iOS en GitHub mientras traslado los jobs de Linux?

Sí. El runner se elige por job, así que los jobs de Linux pueden ejecutarse en un proveedor mientras los de macOS se quedan en runners alojados por GitHub dentro del mismo workflow. Conéctelos con needs: y pase archivos con actions/upload-artifact y actions/download-artifact, que almacena GitHub.

¿Qué le pasa a un job si el runner de terceros está caído? ¿Hay fallback?

GitHub no tiene un fallback integrado entre etiquetas de runner. Un job cuya etiqueta no coincide con ningún runner en línea se queda en cola y falla a las 24 horas. Guarde la etiqueta en una variable de repositorio u organización para que volver atrás sea un solo cambio, defina timeout-minutes y pregunte a cada proveedor si ofrece su propio fallback.

¿Siguen funcionando los secretos y OIDC en runners de terceros?

Sí. GitHub almacena los secretos y los entrega al runner al inicio del job, y GitHub emite el token OIDC, así que id-token: write funciona en cualquier runner. El problema: el claim runner_environment del token es self-hosted en un runner de terceros, así que una política de confianza de la nube que exija github-hosted rechaza el job.

¿Me sigue cobrando GitHub los minutos si uso otro proveedor de runners?

No por los jobs que traslade. Los runners de terceros se registran en GitHub como runners autoalojados, y GitHub indica que los runners autoalojados no tienen cargos por minuto. GitHub sigue cobrando los puestos, el almacenamiento que guarda por encima de lo incluido y los jobs que se quedan en runners alojados por GitHub. El proveedor cobra sus propios minutos.

¿Cómo fijo la imagen del runner para que no cambie sin avisar?

ubuntu-latest cambia según el calendario de GitHub, y ubuntu-24.04 fija la versión del sistema operativo, pero no las versiones de los paquetes. Fije lo que importa dentro del job: acciones de configuración con versiones explícitas e imágenes de contenedor por digest. Pregunte a cada proveedor qué le permite fijar; la propia aplicación de runner tiene que actualizarse para seguir funcionando con GitHub.

¿Cómo se aíslan los jobs entre sí en un runner de terceros?

Depende del proveedor. Pregunte si cada job obtiene su propia máquina virtual o un contenedor en un host compartido, si la máquina se destruye después del job y qué conserva el proveedor después. Una máquina virtual nueva por job es el más sólido de los modelos habituales, porque no queda nada de un job para el siguiente.

¿Cómo pruebo primero un proveedor de runners en un solo repositorio?

Instale la GitHub App del proveedor en un repositorio, cambie un job de Linux que se ejecute con frecuencia mediante una variable de repositorio en una rama, ejecútelo al menos diez veces y compare duración, tiempo en cola, aciertos de caché, fallos y coste con una referencia en runners alojados por GitHub. Vuelva atrás cambiando la variable.