CRACI es el runner en el que se ejecutan sus builds

Una línea traslada el build

CRACI sustituye el runner, no GitHub Actions. Sus archivos de workflow, actions y secretos se quedan donde están; lo único que cambia es dónde se ejecuta el job:

jobs:
  build:
    runs-on: craci

Las ejecuciones siguen apareciendo en GitHub, de modo que las pull requests, los checks y los logs permanecen donde su equipo ya los consulta. De eso se encarga la GitHub App, que usted instala en todos sus repositorios o solo en los que elija.

Cómo son los runners

• Tamaños de 1 a 32 unidades de cómputo, cada una con 1 vCPU y 3 GB de RAM; el tamaño por defecto es 2. El tamaño se define por job con cracicorp/setup@v1 y su parámetro size:.
• x86-64 y ARM64 nativos a la misma tarifa.
• Imágenes: CRACI Slim, CRACI Slim ARM64 y una imagen de Ubuntu 24.04 compatible con GitHub, con Docker Engine, Buildx y Compose v2.
• Máquinas virtuales aisladas para cada job. La virtualización anidada está disponible en x86-64 y en versión preliminar en ARM64.
• Caché: la caché de GitHub Actions, además de caché de capas de contenedor: cachés de capas locales, remotas y de bind mount.
• Infraestructura del pipeline: un rango estable de IP de salida y plantillas de runner a nivel de organización.
• Linux por ahora. Los runners de Windows y macOS están en la hoja de ruta.

CRACI gestiona los runners, que se ejecutan en infraestructura bare-metal europea, con residencia de datos en la UE. Los runners alojados por el cliente están en la hoja de ruta para Enterprise; consulte runners gestionados frente a autoalojados para valorar las ventajas e inconvenientes.

Por qué la seguridad de la cadena de suministro corresponde al runner

El build de producción no es el build de un portátil. Los rangos de versiones se resuelven de otra manera, las etiquetas se mueven, las cachés están calientes o frías y el entorno no es el mismo. El único registro fiable de lo que se publicó es el que se toma mientras se ejecuta el build de la versión, y por eso CRACI puso el registro dentro del runner y no a su lado. El argumento completo está en por qué la seguridad de la cadena de suministro corresponde a la CI.

Como CRACI controla el runner, puede hacer cosas que un escáner no puede:

• Registrar, no escanear. Un proxy que entiende de paquetes observa lo que el job descarga realmente, incluidas las dependencias transitivas y los paquetes restaurados desde cachés de CI. La SBOM de cada job lleva un estado de completitud.
• Aplicar una política de salida. La política se aplica en el runner, se valida antes de que empiece el job y bloquea ante cualquier fallo.
• Devolver la evidencia. La API devuelve SBOM, trazas de red y datos de procedencia de cada job.

Aproximadamente el doble de rápido que los runners alojados en GitHub

CRACI ejecuta los builds aproximadamente el doble de rápido que los runners alojados estándar de GitHub, con los mismos workflows y sin modificarlos. El job que tardaba diez minutos tarda unos cinco.

Una CI más rápida vale más que los minutos que ahorra. Una pull request que se pone en verde en cinco minutos es una que el revisor todavía tiene delante; una que tarda veinte es una que el autor ya ha dejado de lado para pasar a otra cosa. El tiempo de build es el intervalo entre escribir un cambio y saber si funciona, y lo paga cada ingeniero del equipo en cada push.

Hay tres motivos: el hardware, menos tiempo de espera y la caché.

Lo que cuesta la aceleración

Como CRACI mide por segundo y cobra menos por minuto, ir el doble de rápido suma en lugar de anularse. En un build que tarda diez minutos en un runner x64 de 2 núcleos alojado en GitHub (precios de lista de GitHub a septiembre de 2026, de CRACI a octubre de 2026):

Build de diez minutos, 1000 veces al mes	GitHub-hosted	CRACI
Tiempo real por build	10 minutos	Unos 5 minutos
Coste por build	$0.060	$0.020
Coste al mes	Unos $60	Unos $20

Es aproximadamente un 67% menos, o 3 veces más barato. Sin la aceleración, el ahorro se reduce a la diferencia de precio de lista: alrededor de un 33% en x64 de 2 núcleos. Cuánto más rápidos sean sus propios builds depende de la carga de trabajo, así que traslade un workflow y mídalo.

Facturación por segundo

Los minutos de build se miden por segundo, redondeados al segundo más próximo. GitHub redondea cada job al minuto completo superior, de modo que una matriz de jobs cortos se factura por tiempo que nunca utilizó: un job de 30 segundos cuesta aproximadamente un 67% menos en CRACI, y uno de 70 segundos, alrededor de un 61% menos. En los jobs largos, el ahorro tiende a la diferencia de precio de lista.

Los minutos de build cuestan $0.002 por vCPU-minuto, o $0.004 por minuto para un runner de tamaño 2, a la misma tarifa en ARM64. CRACI no es el runner más barato del mercado, y el precio no es el argumento: el argumento es lo que el runner registra mientras se ejecuta. Consulte los precios.

Cómo se compara CRACI con otros runners de GitHub Actions

Blacksmith, Depot, Namespace y WarpBuild funcionan igual que CRACI: sus workflows siguen en GitHub Actions y cambia el lugar donde se ejecuta el job. En velocidad y precio están cerca unos de otros, y varios publican un precio de ARM inferior al de CRACI. La diferencia está en lo que el runner registra y controla mientras se ejecuta el job.

CRACI es uno de los runners más asequibles, y es el que genera una SBOM de lo que el job descargó realmente, aplica una política de salida que bloquea ante cualquier fallo y devuelve datos de procedencia a través de su API, como subproducto de ejecutar el build y sin añadir nada al workflow. Si quiere la versión completa, fila a fila: Comparativa de runners de GitHub Actions.

Lo que funciona bien en CRACI

Todo lo que hace un job de GitHub Actions: builds de aplicaciones, imágenes de contenedor, baterías de tests. Dos casos que conviene destacar son los builds de Yocto y BitBake de imágenes de Linux embebido, documentados hasta runners de tamaño 32, y los builds de Raspberry Pi OS con pi-gen.

En la hoja de ruta

• Runners de Windows y macOS: en la hoja de ruta.
• Runners alojados por el cliente: en la hoja de ruta, para Enterprise.
• Otros sistemas de CI: GitHub Actions hoy, otros en la hoja de ruta, todavía sin fecha.