CRACI frente a Jenkins

La respuesta corta

Jenkins se presenta como el principal servidor de automatización de código abierto, y con razón: funciona en cualquier lugar donde lo instale, reparte el trabajo entre tantas máquinas como le dé, y más de 2.300 plugins de la comunidad lo conectan a casi cualquier herramienta. Si los builds deben quedarse por completo dentro de su propia red, o sus pipelines dependen de plugins sin equivalente en otra parte, Jenkins es difícil de sustituir.

CRACI es un producto de otro tipo. Es un runner gestionado para GitHub Actions: no hay controlador que actualizar ni agente que parchear. Mientras se ejecuta cada job, CRACI registra cada dependencia externa que incorpora el build, aplica una política de egress en la red del build y genera SBOM, datos de procedencia y monitorización de vulnerabilidades a partir de ese registro. Jenkins puede hacer parte de eso mediante plugins que usted elige, configura y mantiene al día; CRACI convierte el propio runner en el registro de seguridad.

Antes de nada, un punto práctico. CRACI es compatible hoy con GitHub Actions, con Jenkins y GitLab CI en la hoja de ruta y sin fecha. Para ejecutarse hoy en CRACI, un pipeline de Jenkins tiene que pasar primero a un workflow de GitHub Actions.

De un vistazo

Lo que Jenkins hace bien

Funciona donde usted lo necesita. Jenkins se ejecuta en sus propios servidores, en su propia red, sin ningún plano de control SaaS de por medio. Los agentes pueden ser Linux, Windows, macOS o cualquier otra máquina que pueda conectar, así que un solo controlador puede compilar un backend, un cliente de escritorio y firmware.

Plugins para casi todo. El ecosistema de plugins es el mayor punto fuerte de Jenkins. Hay plugins para control de código fuente, herramientas de build, informes de pruebas, destinos de despliegue y escáneres de seguridad, y los equipos con toolchains poco habituales descubren a menudo que Jenkins es el único CI que ya los admite.

Sin coste de licencia. Jenkins es gratuito y de código abierto. Sus costes son las máquinas en las que se ejecuta y el tiempo que su equipo dedica a gestionarlo.

En qué se diferencia CRACI

Nada que gestionar

Una instalación de Jenkins es un sistema que pertenece a su equipo: el controlador, los agentes, los plugins y las actualizaciones. El proyecto Jenkins publica avisos de seguridad del núcleo y de los plugins con frecuencia, varios al mes en 2026 (por ejemplo, el 2 y el 16 de septiembre y el 5 de agosto), y aplicar cada uno es tarea suya. CRACI ejecuta los jobs en runners gestionados, en máquinas virtuales aisladas con una VM por job, así que no hay ningún servidor de build que usted tenga que parchear.

La SBOM sale del build

En Jenkins, una SBOM sale de un plugin o de un paso de escáner que usted añade, y que normalmente lee manifiestos y lockfiles a posteriori. Los builds suelen hacer más de lo que dicen esos archivos: los scripts de instalación descargan código, los scripts de build descargan durante el build y las cachés restauran paquetes que ningún lockfile menciona. CRACI ve ese tráfico porque es el runner. Un proxy que entiende de paquetes registra lo que cada job descarga de las fuentes de paquetes, en fuentes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk y Git, y la evidencia de dependencias viaja con las cachés de CI. Cada SBOM en CycloneDX o SPDX indica su grado de completitud, por job y por caché.

Una política en la red del build

En Jenkins, controlar a qué puede acceder un build significa reglas de firewall o proxies en torno a sus agentes, que usted diseña y mantiene. En CRACI, una política de egress en cada job decide a qué hosts puede acceder: denegación por defecto o permiso por defecto, con 24 presets de fuentes de software integrados y fuentes personalizadas tipadas, validada antes de que empiece el job. Las políticas bloquean si fallan, y las infracciones envían una alerta.

Monitorizar lo distribuido

La API devuelve SBOM, trazas de red y procedencia. CRACI agrega las vulnerabilidades de todos los builds y repositorios, sigue reevaluando las SBOM monitorizadas a medida que aparecen avisos y muestra qué builds anteriores contenían una dependencia vulnerable, para que sepa durante qué periodo estuvo afectado.

Precio por minuto de build

Jenkins no tiene coste de licencia, pero gestionarlo no sale gratis: paga el controlador y los agentes, estén inactivos u ocupados, y a las personas que los mantienen al día. CRACI solo cobra por los minutos de build: $0.002 por vCPU-minuto ($0.004 con un runner de 2 vCPU por defecto), facturados por segundo, sin cuota mensual ni cargo por SBOM.

Cuál le conviene

• Siga con Jenkins si los builds deben ejecutarse por completo en su propia infraestructura, si depende de plugins sin equivalente en GitHub Actions, si necesita builds en Windows o macOS, o si tiene personas para gestionarlo y le funciona.
• Elija CRACI si su código está en GitHub, está migrando o preparado para migrar pipelines a GitHub Actions, y quiere dejar de gestionar servidores de build y ganar a cambio un registro de lo que entró en cada versión.
• Use los dos durante una migración gradual: pase los proyectos nuevos y los pipelines de Linux a GitHub Actions en CRACI, y deje los jobs estables de Jenkins donde están.

Tenga claro a qué renuncia hoy al elegir CRACI. Solo ejecuta jobs de Linux, con Windows y macOS en la hoja de ruta; los runners alojados por el cliente están en la hoja de ruta para Enterprise; y los pipelines de Jenkins tienen que convertirse en workflows de GitHub Actions hasta que llegue la compatibilidad con Jenkins.

Para productos regulados

Marcos como el Cyber Resilience Act de la UE esperan que los fabricantes sepan qué contiene cada versión y gestionen sus vulnerabilidades, con obligaciones de notificación desde septiembre de 2026. En Jenkins, esa evidencia procede de los plugins y escáneres que usted conecte a cada pipeline. CRACI la genera a partir del registro del build y exporta las SBOM en CycloneDX o SPDX. Automatiza una parte importante de la visibilidad y la evidencia de la cadena de suministro de software que una empresa necesita para su proceso más amplio del CRA; ninguna de las dos herramientas hace que un producto cumpla por sí sola.

Migrar un pipeline a CRACI

GitHub Actions Importer, de la propia GitHub, convierte pipelines de Jenkins en workflows de GitHub Actions. GitHub aspira a que el 80 % de cada workflow se convierta automáticamente y afirma que cada workflow convertido debe revisarse antes de ejecutarse en producción, así que cuente con algo de trabajo manual. Cuando un pipeline ya funciona como workflow de GitHub Actions, se ejecuta en CRACI con una línea:

runs-on: craci

Las ejecuciones siguen apareciendo en la interfaz de GitHub. Más información sobre la generación de SBOM durante el build, consulte las alternativas a Jenkins, compare plataformas de CI/CD o vea los precios.