GitHub Actions: cómo escapar del límite de 2.000 minutos
En pocas palabras: El truco es montar un self-hosted runner en una VPS de USD 5 al mes: GitHub no cobra minutos cuando corrés los workflows en tu propia máquina. Así saltás el tope de 2.000 minutos gratis y el costo de USD 0,008 por minuto en Linux.
GitHub Actions te da 2.000 minutos gratis por mes en repositorios privados. Cuando los agotás, te empieza a cobrar por minuto (USD 0,008 en Linux) o podés montar un self-hosted runner en una VPS de USD 5 y correr tus pipelines sin tope. Ese es el atajo que casi nadie configura hasta que llega la factura.
Si alguna vez configuraste un pipeline de CI/CD, sabés la sensación: todo verde, el deploy solo, magia. Después el equipo crece, entran veinte commits por día y aparece el mail que arruina la fiesta: “You have used 100% of your included Action minutes”. La luna de miel con la automatización se terminó. Vamos a ver por qué pasa y cómo salir sin poner un peso.
GitHub Actions es la plataforma de integración y despliegue continuo (CI/CD) integrada en GitHub, propiedad de Microsoft. Ejecuta tus workflows (compilar, testear, deployar) en máquinas virtuales que proporciona GitHub. En repositorios privados de plan gratuito tenés una cuota de 2.000 minutos mensuales; superado ese número, cada minuto extra se factura en dólares.
En 30 segundos
- 2.000 minutos/mes gratis en repos privados (plan Free); en repos públicos es gratis e ilimitado.
- Un pipeline full-stack quema ~5 min por ejecución (2 de Angular + 3 de .NET); con 20 commits diarios, la cuota se agota en 20 días hábiles.
- Minuto extra en Linux: USD 0,008; Windows cuesta el doble (USD 0,016) y macOS diez veces más (USD 0,08).
- Cacheando dependencias y paralelizando jobs recortás minutos sin tocar la billetera.
- Con uso intensivo, un self-hosted runner en una VPS de USD 5-20 sale más barato que pagarle a GitHub.
¿Cuál es el límite de minutos de GitHub Actions y qué pasa si lo superás?
En el plan Free tenés 2.000 minutos por mes para repos privados. Al llegar al 100%, GitHub frena los workflows o empieza a cobrar por minuto excedente, según cómo tengas configurado el spending limit. En repositorios públicos no hay tope: corren gratis e ilimitado. Ese es el primer dato clave sobre el límite de minutos de GitHub Actions. Para más detalles técnicos, mirá ventajas principales de GitHub.
Los números finos, según la documentación oficial de GitHub: cada job tiene un timeout de 6 horas, el almacenamiento gratis de artefactos es de 500 MB, y el consumo se cuenta en minutos redondeados hacia arriba. Ojo con esto: los minutos de Windows valen el doble y los de macOS diez veces más, así que un pipeline en macOS te vacía la cuota mucho antes de lo que pensás.
¿Por qué GitHub pone un límite? Porque cada minuto que corrés es una máquina virtual real de Microsoft trabajando para vos. La cuota gratis subsidia el open source y a los equipos chicos. El resto paga.
¿Cuántos minutos gasta de verdad un proyecto mediano?
Un pipeline full-stack típico consume unos 5 minutos por ejecución. El ejemplo de la serie de Erick G. en dev.to lo desglosa así: el build de Angular tarda 2 minutos, el build y los tests de .NET otros 3. Total: 5 minutos cada vez que alguien pushea.
Hacé la cuenta. Veinte commits por día en un equipo mediano son 100 minutos diarios. En 20 días hábiles ya te comiste los 2.000. Y eso contando solo build y test: si además deployás, corrés linters o generás reportes, el número trepa.
Acá viene lo interesante: el gasto no se reparte parejo. El build suele ser lo más caro (bajar dependencias, compilar), los tests van segundos, y el deploy depende de a dónde subas. Por eso el primer lugar donde atacar siempre es el build.
| Tipo de proyecto | Min. por ejecución | Commits/día | Min./mes (20 días) |
|---|---|---|---|
| Frontend Angular | ~2 | 20 | 800 |
| Backend .NET | ~3 | 20 | 1.200 |
| Full-stack (ambos) | ~5 | 20 | 2.000 |
¿Cómo optimizar workflows sin pagar un minuto extra?
Antes de sacar la tarjeta, hay cuatro palancas gratis que combinadas te bajan hasta la mitad del consumo. Ninguna requiere infraestructura nueva. Tema relacionado: la seguridad de GitHub.
- Cacheá dependencias con
actions/cache. Bajar node_modules o restaurar paquetes NuGet en cada run te roba 5 a 10 minutos. Cacheado, se resuelve en segundos. - Paralelizá jobs con
needs. Correr build y test en secuencia suma tiempos; en paralelo, el pipeline dura lo que tarda el job más lento, no la suma de todos. - Filtrá por rutas con
pathsypaths-ignore. ¿Para qué correr todo el pipeline cuando alguien solo tocó el README? Con path-filters, un cambio de docs no te gasta un solo minuto. - Usá
concurrencypara cancelar runs viejos. Si pusheás tres veces seguidas, no tiene sentido que corran las tres builds. Cancelás las anteriores y corrés solo la última.
Con estos cuatro cambios, un proyecto que gastaba 2.000 minutos puede bajar a 1.000 sin resignar cobertura. La verdad es que la mayoría de los equipos ni siquiera cachea, y ahí se les va la mitad de la cuota.
¿Qué son los self-hosted runners y cuándo conviene usarlos?
Un self-hosted runner es tu propia máquina ejecutando los workflows en lugar de las VMs de GitHub. En vez de runs-on: ubuntu-latest (que alquila un servidor de Microsoft), ponés runs-on: [self-hosted] y el pipeline corre en tu hardware. Resultado: cero minutos facturados, sin importar cuánto lo uses.
Ventajas
- Sin límite de minutos. Corré 10.000 builds al mes si querés; no pagás por ejecución.
- Más rápido en red local. Cachés, artefactos y dependencias viajan por tu red, no por internet.
- Control total. Elegís CPU, RAM y disco. Un .NET pesado vuela en una máquina decente.
Desventajas
- Mantenimiento tuyo. Actualizaciones, seguridad y uptime dependen de vos, no de GitHub.
- Riesgo de seguridad en repos públicos. GitHub recomienda usar self-hosted runners solo en repos privados: un PR malicioso podría ejecutar código en tu servidor.
Lo podés montar en una VPS barata. Una máquina de USD 5 alcanza para arrancar, y si tenés hosting o servidores en donweb.com ya tenés dónde correrlo sin sumar otro proveedor. El break-even es claro: si pasás las 100 horas mensuales de acciones, un servidor dedicado de USD 12-20 sale más barato que el excedente.
¿Conviene pagarle a GitHub o montar un runner propio?
Depende del volumen. Para un equipo de 3 devs que aún no revienta la cuota, optimizar y quedarse en el Free es lo lógico. Para 20 devs con pipelines intensivos, el self-hosted (o GitLab CI auto-gestionado) gana por goleada. Acá la comparativa cruda.
| Opción | Costo mensual | Minutos | Mantenimiento | Ideal para |
|---|---|---|---|---|
| Free + optimización | USD 0 | 2.000 | Ninguno | Startup de 1-3 devs |
| GitHub Team | ~USD 4/usuario | 3.000 incluidos | Ninguno | Equipos que quieren soporte |
| Self-hosted (VPS) | USD 5-20 | Ilimitado | Tuyo | Pipelines intensivos |
| GitLab CI (auto-gestionado) | USD 0 + servidor | Según runner | Tuyo | Equipos grandes |
La cuenta rápida: 5.000 minutos extra de Linux por mes son USD 40. Una VPS que te da minutos ilimitados sale la mitad. Si tu equipo crece, el self-hosted deja de ser opcional y pasa a ser la decisión obvia. Esto se conecta con lo que analizamos en servidores confiables y robustos.
¿GitHub Actions es la mejor opción o hay alternativas?
GitHub Actions es el estándar de facto para open source y proyectos que ya viven en GitHub, por integración y facilidad. Pero no es la única opción, y para equipos grandes hay alternativas que salen más baratas a gran escala.
GitLab CI brilla cuando querés self-hosting: montar tus propios runners es su terreno natural y no dependés de una cuota de minutos. Jenkins te da control absoluto, aunque a costa de mantener un servidor entero y su overhead de configuración. La regla práctica: quedate en GitHub Actions si tu proyecto es open source o el equipo es chico; mirá GitLab o self-hosted si tenés pipelines pesados y muchos desarrolladores empujando código todo el día.
Errores comunes que agotan tus minutos
- No cachear dependencias. Es el error número uno. Bajar todo de cero en cada run suma 5-10 minutos que no aportan nada. Solución:
actions/cachecon la clave del lockfile. - Correr todo en secuencia. Jobs que podrían ir en paralelo esperando uno al otro inflan el tiempo hasta 30%. Usá
needssolo donde haya dependencia real. - No filtrar por path. Disparar el pipeline completo porque cambiaste un
.mdes tirar minutos a la basura. Configurápaths-ignore. - Filtrar secrets en los logs. Un secret impreso por error no solo es un agujero de seguridad: te obliga a rotar credenciales y re-correr todo. Usá siempre
secrets.*, nuncaechode variables sensibles. - Acumular artefactos viejos. Los 500 MB gratis se llenan rápido si nunca borrás. Poné
retention-daysbajo y limpiá lo que no uses.
Preguntas Frecuentes
¿Cuál es el límite de minutos de GitHub Actions en repos privados?
2.000 minutos por mes en el plan Free. El plan Team incluye 3.000. En repositorios públicos no hay límite: GitHub Actions es gratis e ilimitado, sin importar cuántos workflows corras.
¿Cuánto cuesta cada minuto extra en GitHub Actions?
USD 0,008 por minuto en runners Linux, según la facturación oficial de GitHub. Windows cuesta el doble (USD 0,016) y macOS diez veces más (USD 0,08). Por eso conviene mantener los pipelines en Linux siempre que se pueda. Ya lo cubrimos antes en otras herramientas CI/CD disponibles.
¿Cómo reduzco los minutos que usa mi workflow?
Cacheando dependencias con actions/cache, paralelizando jobs con needs, filtrando por rutas con paths-ignore y cancelando runs duplicados con concurrency. Combinadas, estas cuatro técnicas bajan el consumo sin costo.
¿Vale la pena un self-hosted runner en lugar de pagarle a GitHub?
Sí, cuando el volumen es alto. Una VPS de USD 5-20 te da minutos ilimitados, mientras que ese mismo volumen pagado a GitHub cuesta más. Para equipos chicos que no revientan la cuota, no vale la pena el mantenimiento.
¿Es seguro usar un self-hosted runner?
En repos privados, sí. GitHub desaconseja usarlos en repos públicos porque un pull request malicioso podría ejecutar código en tu servidor. Si lo montás, mantené el sistema actualizado y nunca lo expongas a repositorios abiertos.
Conclusión
El límite de 2.000 minutos no es un muro: es una señal de que tu pipeline creció. La secuencia sensata tiene dos pasos. Primero optimizá (cacheo, paralelismo, path-filters) porque es gratis y suele resolver el problema del equipo chico. Segundo, si aún así te quedás corto, montá un self-hosted runner en una VPS y olvidate del contador.
La factura llega solo cuando dejás todo en piloto automático. Con media hora de tuning o cinco dólares de VPS, esa cuota deja de ser un problema. Hacé la cuenta de cuántos minutos gasta tu equipo hoy y decidí con datos, no cuando aparezca el mail del 100%.
Fuentes
- Documentación oficial de GitHub – límites de uso, facturación y administración de Actions
- Erick G. en dev.to – cómo escapar del límite de 2.000 minutos con self-hosted runners (Parte 2)
- Tenki Cloud – guía de optimización de costos en GitHub Actions
- ReturnGIS – desplegar y escalar self-hosted runners
- Vermiip – errores comunes al usar GitHub Actions y cómo evitarlos
