Minutos de CI gratuitos: qué cubren y qué no

Qué cubren los minutos gratuitos

GitHub incluye con cada cuenta una cuota mensual de minutos de Actions para usar en repositorios privados. A septiembre de 2026, la documentación de facturación de GitHub indica:

• GitHub Free: 2.000 minutos al mes
• GitHub Pro y GitHub Team: 3.000 minutos al mes
• GitHub Enterprise Cloud: 50.000 minutos al mes

Los runners estándar alojados por GitHub son de uso gratuito en repositorios públicos. Los minutos incluidos se reinician al principio de cada ciclo de facturación. Algunos detalles influyen en hasta dónde llegan:

• GitHub redondea los minutos que usa cada job al minuto entero superior.
• Los minutos incluidos no se pueden usar en los runners más grandes de GitHub.
• Por encima de la cuota, un runner Linux estándar de 2 núcleos cuesta $0.006 por minuto (Windows y macOS cuestan más por minuto).

Es una oferta generosa en cómputo. Para muchos equipos también es la adecuada, y así lo decimos más abajo.

Hasta dónde llegan 2.000 minutos

1. GitHub redondea cada job de 2 minutos y 20 segundos a 3 minutos, así que una ejecución se factura como 4 × 3 = 12 minutos.
2. 2.000 ÷ 12 = 166,7, así que la cuota de Free cubre 166 ejecuciones completas al mes.
3. 166 ÷ 21 son alrededor de 7,9 ejecuciones por día laborable, para todo el equipo.
4. Cada ejecución por encima de la cuota cuesta 12 × $0.006 = $0.072.

A modo de comparación, la misma ejecución en CRACI se mide por segundos: 4 × 140 segundos = 560 segundos, o alrededor de 9,33 minutos. En un runner de 2 vCPU a $0.004 por minuto, una ejecución cuesta alrededor de $0.037, y las 166 ejecuciones que cubre la cuota de GitHub Free cuestan alrededor de $6.20. CRACI no tiene nivel gratuito ni cuota mensual: se paga por minuto de build. Consulte la página de precios para ver las cifras actuales.

Los minutos gratuitos pueden salir a coste cero; CRACI, no. La mejor pregunta es qué le da cada opción además de cómputo.

Qué no cubren los minutos gratuitos

Los minutos compran tiempo en una máquina. Nunca pretendieron responder a las preguntas que surgen cuando se distribuye software a los clientes:

• ¿Qué paquetes descargó realmente este build, y de dónde?
• ¿Pudo una dependencia comprometida llegar a un host inesperado durante el build?
• ¿El artefacto que distribuimos es el que generó este build?
• Cuando se publica una nueva vulnerabilidad, ¿cuáles de nuestros builds lanzados la incluyen?
• ¿Qué evidencias podemos entregar a un cliente o a un auditor?

Seguridad

GitHub ofrece funciones gratuitas de cadena de suministro que funcionan junto con Actions, y merece la pena activarlas. Las alertas de Dependabot analizan la rama por defecto de su repositorio y le avisan cuando se añade una nueva vulnerabilidad a la GitHub Advisory Database. También puede exportar el estado actual del grafo de dependencias de un repositorio como una SBOM en formato SPDX.

Esas funciones describen el repositorio. CRACI registra el build. Sus runners observan el tráfico hacia las fuentes de paquetes mientras se ejecuta el job, de modo que la SBOM enumera lo que el job descargó realmente, incluidos los paquetes restaurados desde cachés de CI, e indica si el registro de cada job y caché está completo. Las políticas de egress de red pueden denegar todo excepto las fuentes de software que usted permita. Los detalles están en la página de generación de SBOM.

Resiliencia

Cuando aparece una nueva CVE, la respuesta útil no es si su repositorio declara hoy el paquete, sino qué builds distribuidos lo contienen. CRACI agrega las vulnerabilidades entre builds y repositorios y reevalúa continuamente las SBOM monitorizadas, para que pueda encontrar los builds que comparten una dependencia vulnerable. Consulte seguimiento de vulnerabilidades.

Evidencias de cumplimiento

Los clientes y los reguladores piden cada vez más SBOM y pruebas de cómo se construyó el software. La API de CRACI devuelve SBOM, trazas de red y procedencia, y las SBOM se exportan en CycloneDX o SPDX. Automatiza una parte significativa de la visibilidad de la cadena de suministro de software y de las evidencias que las empresas necesitan para su proceso más amplio de cumplimiento del CRA. Por sí sola no hace que una empresa cumpla.

Cuándo los minutos gratuitos son realmente suficientes

Quédese con los minutos gratuitos y active las funciones de seguridad gratuitas de GitHub si se cumple la mayor parte de lo siguiente:

• Su proyecto es de código abierto y está en repositorios públicos, donde los runners alojados estándar son gratuitos.
• Está haciendo prototipos y nada de lo que construye ha llegado aún a los clientes.
• Sus builds caben holgadamente en la cuota mensual.
• Ningún cliente, auditor o regulador le pide SBOM o evidencias de build.
• No vende productos con elementos digitales en el mercado de la UE.

En esa situación, pagar por CRACI compra evidencias que todavía nadie necesita. Vuelva cuando eso cambie.

Señales de que es hora de ir más allá de los minutos gratuitos

• Un cuestionario de seguridad de un cliente pide una SBOM de la versión que distribuyó.
• Vende en la UE. Las obligaciones de notificación de vulnerabilidades del Cyber Resilience Act se aplican desde septiembre de 2026, con aplicación plena en diciembre de 2027. Nuestra introducción al CRA cubre lo básico.
• Un incidente le hace preguntarse qué builds descargaron un paquete, y nadie puede responder rápidamente.
• Supera la cuota gratuita todos los meses y ya está pagando por minutos.

Un camino intermedio para startups

Las startups que cumplan los requisitos reciben un mínimo de 100k minutos de build gratuitos y un onboarding personalizado de nuestro equipo a través del programa para startups. Es una forma de ver cómo son las evidencias del build en su propio pipeline antes de pagar por ellas.