CRACI frente a Buildkite

La respuesta corta

Buildkite es una plataforma de CI/CD híbrida. Su plano de control SaaS se encarga de la orquestación, y los agentes que ejecutan sus jobs residen en su propia infraestructura, on-premises o en la nube. Buildkite afirma que el código fuente y los secretos permanecen en su entorno. También ofrece agentes alojados totalmente gestionados si prefiere no operar los suyos.

CRACI es un runner gestionado compatible con GitHub Actions diseñado para la seguridad de la cadena de suministro. Registra cada dependencia externa que descarga un build, aplica una política de egress a la red del build y genera SBOM, datos de procedencia y evidencia para el CRA a partir de ese registro. En pocas palabras: Buildkite es un CI tradicional con el máximo control de la infraestructura; CRACI es un CI consciente de la seguridad en el que el runner es la evidencia.

CRACI solo es compatible hoy con GitHub Actions, así que no ejecuta pipelines de Buildkite. Un equipo en Buildkite tendría que trasladar un pipeline a GitHub Actions para usar los runners de CRACI, o esperar a otros sistemas de CI, que están en la hoja de ruta.

Lo que Buildkite hace bien

Control sobre la capacidad de cómputo. Como usted aloja los agentes, elige el hardware, el sistema operativo, la red y la región. Los agentes consultan la API de agentes de Buildkite por HTTPS, así que no necesita abrir puertos de entrada en el firewall. Ese modelo se adapta a monorepos grandes, a hardware especializado y a organizaciones cuyas políticas mantienen el código fuente dentro de su propio perímetro.

Integridad de los pipelines. Con los pipelines firmados, los jobs se firman al subirlos y los agentes verifican la firma antes de ejecutarlos, de modo que un agente no ejecutará un job cuyas instrucciones se hayan modificado después de la subida.

Herramientas en torno al build. Test Engine detecta y pone en cuarentena los tests inestables y reparte los tests entre jobs paralelos. Package Registries puede publicar artefactos con procedencia SLSA, que según Buildkite cumple SLSA Build Level 1; esa función está disponible en los planes Enterprise.

Precios flexibles. A septiembre de 2026, Buildkite tiene un plan Free y un plan Pro a $30 por usuario activo al mes, con 10 agentes autoalojados incluidos en Pro y más a $3.50 por agente al mes. Los agentes Linux alojados cuestan $0.004 por minuto de vCPU, medido al segundo.

En qué se diferencia CRACI

La evidencia de seguridad forma parte del runner

Con agentes autoalojados, la seguridad del entorno de build corre por su cuenta. La propia guía de seguridad de Buildkite le indica que instale sistemas operativos mínimos, desactive el SSH de entrada y aplique controles estrictos del egress de red. Es un reparto razonable de responsabilidades, y significa que la evidencia de la cadena de suministro depende de lo que su equipo construya en torno a los agentes.

En CRACI, esa capa viene con el runner. Un proxy que entiende de paquetes registra el tráfico hacia las fuentes de paquetes mientras se ejecuta cada job, en 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. Cada job genera una SBOM en CycloneDX o SPDX con un estado de completitud por job y por caché: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.

Política de egress sin tener que construirla usted

Las políticas de egress de CRACI son de denegación por defecto o de 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, 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 cada infracción.

Procedencia y monitorización

La API devuelve SBOM, trazas de red y datos de procedencia. CRACI no firma la procedencia. Agrega las vulnerabilidades de todos los builds y repositorios y sigue reevaluando las SBOM monitorizadas.

La contrapartida

CRACI solo se ofrece como servicio gestionado. Los jobs se ejecutan en máquinas virtuales aisladas en la infraestructura de CRACI, y el código fuente se procesa en la VM del job mientras dura el build y no se almacena. En el plan Enterprise, CRACI ofrece residencia de datos en la UE con ejecución de los builds en infraestructura bare-metal europea. Si su política exige compilar en su propio hardware, el modelo de Buildkite cumple ese requisito y el de CRACI no.

Cuál encaja mejor

• Buildkite si necesita compilar en su propio hardware o en su propia red, ejecuta builds de Windows o macOS, usa GitLab o Bitbucket, u opera a una escala en la que ser propietario de la capacidad de cómputo compensa.
• CRACI si usa GitHub Actions y quiere evidencia del build sin tener que construirla ni operarla: dependencias registradas, política de egress y evidencia para el CRA desde un único runner.
• Ambos si su organización está dividida: Buildkite para los pipelines que deben permanecer en su hardware y CRACI para los workflows de GitHub Actions en Linux. Los builds de Linux pesados, como las imágenes de Yocto, pueden ejecutarse en runners de CRACI de hasta 32 vCPU y 96 GB de RAM, como se describe en la guía de Yocto de CRACI.

Para el Cyber Resilience Act

El Cyber Resilience Act de la UE exige a los fabricantes saber qué contiene cada versión y gestionar sus vulnerabilidades, con obligaciones de notificación desde septiembre de 2026 y aplicación plena desde diciembre de 2027. En Buildkite, esa evidencia procede de las herramientas que usted ejecuta en sus agentes. CRACI la genera a partir del registro del build, sigue monitorizando lo que se publicó y exporta las SBOM en CycloneDX o SPDX, vulnerabilidades incluidas. 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.

Incorporar CRACI

Para un repositorio en GitHub con workflows de GitHub Actions, instale la GitHub App de CRACI en su organización y configure la etiqueta del runner:

runs-on: craci

Las ejecuciones siguen apareciendo en la interfaz de GitHub. Lea más sobre la generación de SBOM durante el build y cómo gestiona CRACI la seguridad, o consulte los precios.