CRACI frente a WarpBuild

La respuesta corta

WarpBuild es un proveedor de runners de GitHub Actions. Ofrece runners alojados en Linux, Windows y macOS, una caché rápida, runners con snapshots, builders remotos de Docker y una opción de nube propia (BYOC) que ejecuta los mismos runners en su cuenta de AWS, GCP o Azure. Si quiere la cobertura de plataformas más amplia de un solo proveedor de runners, o runners dentro de su propia nube, WarpBuild es una opción sólida.

CRACI es un runner compatible con GitHub Actions construido en torno a la seguridad de la cadena de suministro: cada job genera una SBOM de lo que descargó y se ejecuta bajo una política de egress. WarpBuild compite en velocidad, precio y lugar donde reside el runner; CRACI, en lo que el runner registra y controla. Ambos sustituyen el runner alojado en GitHub, así que tendrá que elegir uno.

De un vistazo

Lo que WarpBuild hace bien

• Plataformas y tamaños. Runners Linux en x86-64 (Ubuntu 22.04, 24.04 y 26.04) y arm64 (24.04 y 26.04) desde 2 vCPU y 8 GB de RAM hasta 32 vCPU y 128 GB, runners Windows Server 2022 y 2025 desde 4 vCPU, macOS 14, 15 y 26 en Apple M4 Pro, y runners Linux arm64 en Apple Silicon. La virtualización anidada está disponible en Linux x86-64.
• Aislamiento. Cada runner es una máquina virtual efímera, creada para el job y destruida después, con su propio volumen de almacenamiento cifrado. WarpBuild dice que no accede a su código ni almacena secretos de build.
• Caché y Docker. Una caché sin límite de tamaño, facturada a $0.20 por GB al mes en los runners alojados, caché de capas de contenedor, runners con snapshots que restauran un estado de máquina preparado y builders remotos de Docker con builds nativos para amd64 y arm64 que también funcionan desde otros sistemas de CI.
• Nube propia. BYOC ejecuta runners gestionados por WarpBuild en su propia cuenta de AWS, GCP o Azure, en cualquier región, con IP estáticas, instancias spot, discos en espera e imágenes de VM personalizadas. WarpBuild anuncia los runners BYOC Linux y Windows a $0.002 por minuto, con complementos gratuitos, además de lo que paga a su proveedor de nube.
• Enterprise. SOC 2 Type II en seguridad, disponibilidad y confidencialidad, infraestructura específica por región, SAML SSO, SCIM, un SLA de disponibilidad del 99,9 % respaldado con créditos, warm pools que inician los jobs en menos de 10 segundos, depuración por SSH y compatibilidad con GitHub Enterprise Server.

En velocidad, WarpBuild anuncia builds el doble de rápidos que los runners alojados en GitHub, y de dos a diez veces más rápidos en su página de precios. Son afirmaciones de WarpBuild, y no hemos comparado CRACI con WarpBuild en un benchmark; la prueba justa es su propio pipeline.

Precio y tamaños

En x86-64, ambos tienen el mismo precio de catálogo por minuto, $0.004 con 2 vCPU y $0.064 con 32 vCPU. El precio de WarpBuild en arm64 es más bajo, ya que CRACI cobra ARM64 a la misma tarifa que x86-64. BYOC traslada el coste de cómputo a su propia factura de la nube. CRACI mide por segundo en lugar de por minuto, así que los jobs cortos se facturan por los segundos que se ejecutan. La memoria por vCPU también difiere (3 GB en CRACI, 4 GB en WarpBuild Linux), así que determine lo que necesitan sus builds antes de comparar. Consulte los precios de CRACI para conocer las condiciones vigentes.

En qué se diferencia CRACI

CRACI trata el build como la fuente de verdad de lo que usted distribuye.

Un registro de lo que descargó el build

Mientras se ejecuta cada job, un proxy que entiende de paquetes registra el tráfico hacia las fuentes de paquetes: fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, además de presets de descarga. La evidencia de dependencias viaja con las cachés de CI, de modo que un paquete restaurado desde una caché también se cuenta. La SBOM de cada job, en CycloneDX o SPDX, lleva un estado de completitud por job y por caché, de modo que usted sabe cuándo el registro está completo y cuándo no.

Una política de egress que viene con el runner

Las políticas de CRACI son de denegación o permiso por defecto, con 24 presets de fuentes de software integrados, fuentes personalizadas tipadas para npm, PyPI, apt, apk, el proxy de Go, Nix, Cargo, registros OCI y Git sobre HTTPS y SSH, y reglas explícitas de TLS, TCP, UDP e ICMP. Las políticas se validan antes de que empiece el job, bloquean si fallan (fail closed) y envían una alerta ante una infracción. Los runners de CRACI también usan un rango estable de IP de egress.

La documentación de WarpBuild no describe una política de egress por job para sus runners alojados. Con BYOC, los runners residen en su propia red, y la guía de refuerzo para AWS de WarpBuild muestra cómo restringir las reglas de salida con sus propios grupos de seguridad, e indica los endpoints que necesita un runner. Eso funciona, y es una configuración de red que usted mantiene en su cuenta de nube en lugar de una política vinculada al job.

Procedencia y monitorización

• Datos de procedencia. La API devuelve SBOM, trazas de red y datos de procedencia. CRACI no firma la procedencia ni declara ningún nivel de SLSA.
• Monitorización de lo distribuido. Las SBOM monitorizadas se reevalúan continuamente frente a nuevas vulnerabilidades, y los hallazgos se agregan de todos los builds y repositorios.

Reserve una demo para ver la SBOM, la traza de red y la procedencia de uno de sus propios workflows.

Cuál encaja mejor

WarpBuild encaja mejor si

• Necesita runners macOS o Windows. CRACI hoy solo funciona en Linux; Windows y macOS están en la hoja de ruta.
• Quiere runners en su propia cuenta de AWS, GCP o Azure. CRACI todavía no ofrece runners alojados por el cliente; están en la hoja de ruta para Enterprise.
• Utiliza GitHub Enterprise Server, con el que CRACI no es compatible hoy.
• Depende hoy de runners con snapshots o de builders remotos de Docker.
• Su objetivo principal es el menor coste por minuto en arm64 o con BYOC.

CRACI encaja mejor si

• Necesita demostrar qué entró en una versión, con un estado de completitud, a partir del propio build.
• Quiere una política de egress vinculada a cada job sin tener que construirla en la red de su nube.
• Quiere monitorizar las SBOM distribuidas.
• Necesita residencia de datos en la UE, disponible en el plan Enterprise de CRACI.

A qué renuncia con CRACI. A los jobs de Windows y macOS, a los runners en su propia nube y a GitHub Enterprise Server, todo lo cual WarpBuild ofrece hoy, además de a los precios más bajos en arm64 y BYOC. Lo que gana es un registro del build que los equipos de seguridad y de cumplimiento pueden usar sin otro escáner en el pipeline.

Para el Cyber Resilience Act

El Cyber Resilience Act pide a los fabricantes que conozcan los componentes de sus productos, gestionen sus vulnerabilidades y conserven evidencia. El producto de WarpBuild es infraestructura de CI. CRACI automatiza una parte importante de la visibilidad y la evidencia de la cadena de suministro de software que las empresas necesitan para su proceso más amplio de cumplimiento del CRA: SBOM del build exportadas en CycloneDX o SPDX, seguimiento de vulnerabilidades y procedencia a través de la API. Consulte la evidencia para el CRA.

Migrar desde WarpBuild

CRACI sustituye el runner, no GitHub Actions. Los workflows y la interfaz de GitHub siguen igual, y la etiqueta del job pasa a ser runs-on: craci. Los jobs disponen de Docker Engine, Buildx y Compose v2, una imagen de Ubuntu 24.04 compatible con GitHub y virtualización anidada en x86-64. Lea más sobre la integración con CI/CD y la generación de SBOM durante el build.

WarpBuild frente a CRACI: preguntas frecuentes

Precios, BYOC, plataformas y seguridad, respondidos a partir de la información publicada por cada proveedor

¿Qué es WarpBuild?

WarpBuild es un proveedor de runners de GitHub Actions. Ejecuta sus jobs en runners Linux, Windows y macOS propios, o en runners gestionados por WarpBuild dentro de su cuenta de AWS, GCP o Azure (BYOC). También vende builders remotos de Docker, runners con snapshots y una caché para artefactos y capas de contenedor.

¿Cuánto cuesta WarpBuild?

A septiembre de 2026, los runners Linux alojados de WarpBuild cuestan $0.004 por minuto con 2 vCPU en x86-64 y $0.003 en arm64, y llegan a $0.064 y $0.048 con 32 vCPU. Windows empieza en $0.016 por minuto con 4 vCPU, y macOS en M4 Pro, en $0.08 con 6 vCPU. Los runners BYOC cuestan $0.002 por minuto además de su factura de la nube. El almacenamiento en caché cuesta $0.20 por GB al mes, y la facturación es por minuto.

¿Es WarpBuild más barato que CRACI?

En arm64, sí; en x86-64, el precio de catálogo es el mismo. CRACI cobra $0.004 por minuto de 2 vCPU tanto en x86-64 como en ARM64, frente a los $0.004 de WarpBuild en x86-64 y $0.003 en arm64. Con 32 vCPU, ambos anuncian $0.064 por minuto en x86-64. WarpBuild presenta BYOC como su opción más barata a escala, ya que usted paga $0.002 por minuto más su propia factura de la nube. CRACI mide por segundo en lugar de por minuto, así que los jobs cortos se facturan por los segundos que se ejecutan. Lo que CRACI añade en el runner es el registro del build: una SBOM para cada job, una política de egress, datos de procedencia y monitorización de vulnerabilidades.

¿Qué es WarpBuild BYOC y puede CRACI ejecutarse en mi propia nube?

BYOC ejecuta runners gestionados por WarpBuild en su propia cuenta de AWS, GCP o Azure, en cualquier región, con IP estáticas, instancias spot, discos en espera e imágenes de VM personalizadas. CRACI ejecuta hoy runners gestionados en infraestructura europea, con runners alojados por el cliente en la hoja de ruta para Enterprise.

¿Genera WarpBuild SBOM o procedencia del build?

No figura entre sus funciones documentadas. WarpBuild se centra en la capacidad de cómputo, la caché y el lugar donde reside el runner. CRACI registra los paquetes que descarga cada job, incluidos los restaurados desde cachés, y genera una SBOM en CycloneDX o SPDX con un estado de completitud. La API devuelve SBOM, trazas de red y datos de procedencia.

¿Puede WarpBuild restringir a qué accede un build en la red?

La documentación de WarpBuild no describe una política de egress por job para sus runners alojados. Con BYOC, los runners están en su propia red, y la guía de refuerzo para AWS de WarpBuild muestra cómo restringir las reglas de salida con sus propios grupos de seguridad. CRACI aplica una política de egress en el runner para cada job: denegación o permiso por defecto, 24 presets de fuentes de software integrados, validada antes de que empiece el job y que bloquea si falla (fail closed).

¿Es compatible CRACI con Windows, macOS o GitHub Enterprise Server?

Hoy no. CRACI ejecuta Linux en x86-64 y ARM64, con Windows y macOS en la hoja de ruta, y no es compatible con GitHub Enterprise Server. WarpBuild ofrece runners Windows y macOS, y compatibilidad con GitHub Enterprise Server en su plan enterprise.

¿Cumple WarpBuild con SOC 2 y dónde se guardan los datos?

WarpBuild afirma contar con la certificación SOC 2 Type 2 en seguridad, disponibilidad y confidencialidad, y dice que no accede a su código ni a sus secretos de build. Los planes Enterprise pueden conservar los datos en una región elegida. CRACI ejecuta los builds en infraestructura bare-metal europea, ofrece residencia de datos en la UE en Enterprise, no almacena su código fuente y documenta sus controles de seguridad en su Trust Center.

¿Es WarpBuild más rápido que CRACI?

WarpBuild anuncia en su página de inicio builds el doble de rápidos que los runners alojados en GitHub, y de dos a diez veces más rápidos en su página de precios. No hemos comparado CRACI con WarpBuild en un benchmark, así que ejecute el mismo workflow en los dos y compare.

¿Tengo que reescribir mis workflows de GitHub Actions para cambiar?

No. Ambos productos sustituyen el runner, no GitHub Actions. Los workflows, los triggers y la interfaz de GitHub siguen igual; en CRACI, la etiqueta del job pasa a ser runs-on: craci.