CRACI frente a RunsOn

La respuesta corta

RunsOn son runners autoalojados de GitHub Actions sin el mantenimiento de una flota de runners. Un stack de CloudFormation o un módulo de Terraform lo despliega en su cuenta de AWS; después, cada job obtiene una instancia EC2 nueva del tipo que usted elija, y AWS factura el cómputo a precio de coste. Si quiere runners dentro de su propia cuenta de nube y la factura de cómputo más baja posible, sobre todo en instancias spot, RunsOn es difícil de superar.

CRACI es un CI que gestiona de forma nativa la seguridad de la cadena de suministro. Es un runner gestionado y compatible con GitHub Actions, y la seguridad forma parte del runner en lugar de ser una herramienta añadida: CRACI registra cada dependencia externa que descargó el build, aplica una política de egress en la red del build y convierte ese registro en SBOM, monitorización de vulnerabilidades y evidencia. Ambos productos sustituyen el runner en el que se ejecutan sus jobs, así que debe elegir uno.

De un vistazo

Lo que RunsOn hace bien

Su cuenta, sus datos. El plano de control, las máquinas virtuales de los runners, la caché S3 y los logs están todos en su cuenta de AWS, y los flujos de datos propios de RunsOn se limitan a la validación de licencias, la telemetría y el soporte. Para los equipos cuya revisión de seguridad se detiene en «un tercero ejecuta nuestro código y nuestros secretos», esa es la respuesta que RunsOn está hecho para dar. Los runners de CRACI son gestionados hoy; los runners alojados por el cliente están en su hoja de ruta para Enterprise.

Cualquier instancia, una por job. La etiqueta runs-on elige la máquina, de modo que un job puede pedir una gran instancia optimizada para cómputo, una GPU, almacenamiento NVMe local o Windows. Cada job obtiene una instancia EC2 nueva que se destruye al terminar, y RunsOn dice que los jobs suelen arrancar en unos 30 segundos, o en menos de 6 con warm pools.

Coste. RunsOn no añade margen al cómputo de AWS y cobra una licencia fija, desde unos $348 (€300) al año. Dice que el resultado es entre 7 y 12 veces más barato que los runners alojados por GitHub. Las instancias spot con retorno automático a on-demand reducen aún más la factura. Estas son las cifras de RunsOn; su combinación de instancias y su región deciden el número real.

Caché y observabilidad. Una caché respaldada por S3 en su VPC sustituye la caché de GitHub sin su límite de tamaño, la caché de capas de Docker viene integrada, y los discos persistentes EBS y los volúmenes compartidos EFS conservan el estado entre jobs. Las métricas por job y los informes de costes van a CloudWatch y OpenTelemetry.

Complementos de seguridad. Una integración con StepSecurity Harden-Runner añade monitorización y filtrado del egress y detección de manipulaciones del código fuente durante el build, con una licencia enterprise de StepSecurity.

Precio y tamaños

Solo en cómputo, RunsOn en instancias spot cuesta una fracción de los $0.004 por minuto de 2 vCPU de CRACI. Pero la comparación no es solo por minuto. Con RunsOn también paga la licencia y los servicios de AWS que rodean a los runners, como las NAT gateways para IP estáticas, y su equipo se hace cargo de la pila: actualizaciones, cuotas de AWS e incidentes. CRACI tiene un único precio por minuto, medido por segundo, sin cuota mensual, y CRACI opera la infraestructura. Consulte los precios de CRACI para ver las condiciones vigentes y runners gestionados frente a autoalojados para el análisis más amplio.

En velocidad, CRACI ejecuta los builds aproximadamente el doble de rápido que los runners alojados por GitHub, gracias a un hardware más rápido, menos tiempo en cola y la caché. La velocidad de RunsOn depende del tipo de instancia que elija. No hemos comparado ambos en un benchmark.

En qué se diferencia CRACI

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 los presets de descarga. La evidencia de dependencias viaja con las cachés de CI, de modo que los paquetes restaurados desde una caché se siguen contando. Eso incluye las dependencias ocultas que ningún lockfile enumera, como el código descargado por hooks de instalación o scripts de build, y las capas de imágenes base. Cada job produce una SBOM en CycloneDX o SPDX con un estado de completitud por job y por caché.

Control sobre lo que el build puede alcanzar

Los security groups deciden a qué redes puede llegar un runner de RunsOn; no saben qué registro de paquetes debe usar un job. La política de egress de CRACI, sí: de denegación o permiso por defecto, con 24 presets integrados de fuentes de software, fuentes personalizadas tipadas para npm, PyPI, apt, apk, el proxy de Go, Nix, Cargo, registros OCI y Git por 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 y envían una alerta ante una infracción. Como la política solo permite lo que el build necesita, bloquea la exfiltración a hosts que el build no necesita, incluso en un ataque que nadie haya visto antes.

Harden-Runner en RunsOn llega más lejos en un punto: también vigila si se modifican archivos fuente durante el build, algo que CRACI no hace.

Procedencia y monitorización

La API devuelve SBOM, trazas de red y procedencia. CRACI no firma la procedencia ni declara ningún nivel de SLSA. Agrega las vulnerabilidades de todos los builds y repositorios y sigue reevaluando las SBOM monitorizadas.

Dos preguntas de seguridad distintas

RunsOn responde a «¿quién custodia mi código, mis secretos y el estado de mis runners?» manteniéndolo todo en su cuenta de AWS. CRACI responde a otra pregunta: «¿qué incorporó este build y a dónde se conectó?». CRACI ejecuta cada job en su propia máquina virtual aislada, no almacena su código fuente y cuenta con la certificación ISO 27001. La segunda respuesta es la que le piden un auditor, un cliente o el Cyber Resilience Act.

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

Cuál encaja mejor

RunsOn encaja mejor cuando

• Los runners deben ejecutarse dentro de su propia cuenta de AWS, junto a los recursos de su VPC.
• Lo que más importa es el menor coste de cómputo, y le resulta cómodo operar una pila en AWS.
• Necesita hoy runners de Windows, instancias con GPU o tipos concretos de instancia EC2.
• Sus proyectos no son comerciales, un uso que RunsOn cubre gratis.

CRACI encaja mejor cuando

• Distribuye software para el que debe demostrar qué entró en cada versión, desde el propio build.
• Quiere restringir lo que pueden alcanzar los builds, con una política que bloquea si falla y no necesita licencias adicionales.
• Necesita monitorizar lo distribuido sin añadir herramientas a cada workflow.
• Prefiere no operar infraestructura de CI y quiere los builds en infraestructura europea.

A qué renuncia con CRACI. A los runners en su propia cuenta de AWS, que están en la hoja de ruta para Enterprise, a los runners de Windows, también en la hoja de ruta, y a la factura de cómputo más baja. Lo que gana es un registro del build que seguridad y cumplimiento pueden usar sin otro escáner en el pipeline, en una infraestructura que usted no tiene que operar.

Para el Cyber Resilience Act

El Cyber Resilience Act de la UE espera que los fabricantes sepan qué hay en cada versión y gestionen sus vulnerabilidades, con obligaciones de notificación desde septiembre de 2026 y aplicación completa desde diciembre de 2027. Un runner autoalojado no produce esa evidencia por sí solo; tendría que añadir herramientas de SBOM y de escaneo a sus workflows. CRACI la produce a partir del registro del build y exporta SBOM en CycloneDX o SPDX. 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.

Migrar desde RunsOn

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. Las startups pueden solicitar el programa para startups.

RunsOn frente a CRACI: preguntas frecuentes

Precios, alojamiento, plataformas y seguridad, con respuestas basadas en la información publicada por cada proveedor

¿Qué es RunsOn?

RunsOn son runners autoalojados de GitHub Actions convertidos en producto. Usted despliega un stack de CloudFormation o un módulo de Terraform en su propia cuenta de AWS, y RunsOn lanza una instancia EC2 nueva para cada job y la termina cuando el job finaliza. Los runners, las cachés, los logs y las credenciales permanecen en su cuenta de AWS. Lo fundó en 2023 Cyril Rohr, que reside en Rennes (Francia).

¿Cuánto cuesta RunsOn?

A septiembre de 2026, RunsOn cobra una licencia anual fija por entidad jurídica: desde unos $348 (€300) al año en Starter, unos $1,044 (€900) en Growth, unos $2,088 (€1,800) en Scale y unos $4,176 (€3,600) en Enterprise, según cuántos runners lance al mes. AWS factura el cómputo directamente, por segundo, sin margen de RunsOn. RunsOn indica unos $0.0009 por minuto para una instancia spot x64 de 2 vCPU en us-east-1. Es gratuito para uso no comercial y tiene una prueba de 15 días.

¿RunsOn es más barato que CRACI?

En cómputo, sí, y por un amplio margen en instancias spot. CRACI cobra $0.004 por minuto de 2 vCPU, mientras que una instancia spot de 2 vCPU a través de RunsOn cuesta unos $0.0009 por minuto en us-east-1, más la licencia. El total incluye además su red y su almacenamiento de AWS, y el tiempo de operar la pila. 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.

¿RunsOn genera SBOM o procedencia del build?

No figura entre sus funcionalidades documentadas. RunsOn se centra en el cómputo, la caché, el coste y la observabilidad en su cuenta de AWS. CRACI registra los paquetes que descarga cada job, incluidos los restaurados desde cachés, y produce una SBOM en CycloneDX o SPDX con un estado de completitud. La API devuelve SBOM, trazas de red y procedencia.

¿Puede RunsOn restringir lo que un build alcanza en la red?

Los runners de RunsOn están en su VPC, así que se aplican los security groups y el enrutamiento de AWS, y las IP de egress estáticas proceden de NAT gateways. Para filtrar el egress dentro del job, RunsOn integra StepSecurity Harden-Runner, que crea una línea base del tráfico saliente de cada job y puede imponerla como lista de permitidos; en RunsOn necesita una licencia enterprise de StepSecurity. CRACI aplica una política de egress en el propio runner: de denegación o permiso por defecto, con 24 presets integrados de fuentes de software, validada antes de que empiece el job y que bloquea si falla.

¿Puedo ejecutar CRACI en mi propia cuenta de AWS?

Hoy no. Los runners de CRACI son gestionados, en infraestructura europea, y los runners alojados por el cliente están en la hoja de ruta del plan Enterprise. Si los runners dentro de su propia cuenta de AWS son un requisito imprescindible, RunsOn está hecho exactamente para eso.

¿CRACI admite runners de Windows o macOS?

CRACI ejecuta hoy Linux en x86-64 y ARM64, con Windows y macOS en la hoja de ruta. RunsOn ofrece Windows Server 2022 y 2025 e instancias con GPU; con RunsOn, los jobs de macOS también se quedan en runners alojados por GitHub.

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

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