La respuesta corta

Para la mayoría de desarrolladores solos y equipos pequeños, GitHub Actions en el plan gratuito o Team es el valor por defecto más fácil: tu repositorio, tu CI, una sola factura. Quédate ahí hasta que (a) empieces a publicar una app para macOS o iOS, (b) superes unas 15.000–20.000 minutos de build al mes, o (c) tengas trabajos que necesiten tu propio hardware (GPUs, suites de integración grandes, cargas reguladas). En ese momento, los runners autoalojados o un servicio de CI distinto empiezan a compensar.

Por qué esta decisión importa antes de crecer

La CI es una de esas herramientas que apenas notas cuando funciona y que notas muchísimo cuando falla. Como founder indie, tu factura de CI está haciendo un trabajo real por ti: detecta deploys rotos, ejecuta tu suite de tests en cada pull request y publica releases para que tú puedas centrarte en los clientes. Elegir mal no suele romper el build; solo va comiendo margen poco a poco según crecen el equipo, el tráfico y los minutos de build.

Dos preguntas mueven casi cualquier decisión de CI para un equipo pequeño:

  1. ¿Vas a necesitar macOS? Si la respuesta es sí, planifícalo desde ya. Los minutos de macOS cuestan aproximadamente diez veces lo que cuesta un minuto de Linux en los runners alojados de GitHub.
  2. ¿Se van a duplicar tus minutos de build en los próximos 12 meses? Si sí, conviene diseñar pensando en autoalojar desde el día uno, aunque empieces en alojado.

Lo que realmente ofrece el plan gratuito de GitHub Actions en 2026

Los precios de los runners alojados de GitHub bajaron el 1 de enero de 2026, hasta un 39%. La tarifa de plataforma propuesta de 0,002 $/min para runners autoalojados — anunciada en diciembre de 2025 y muy comentada — se pospuso a las 48 horas tras el rechazo de la comunidad y, a mediados de 2026, no se está facturando. Trata ese aplazamiento como una oportunidad para planificar, no como una garantía permanente.

Para repositorios privados:

  • Plan Free: 2.000 minutos de Linux al mes y 500 MB de almacenamiento de artefactos.
  • Plan Team (4 $/usuario/mes): 3.000 minutos de Linux al mes y 2 GB de almacenamiento.
  • Plan Enterprise (21 $/usuario/mes): 50.000 minutos de Linux al mes y 50 GB de almacenamiento.

Para repositorios públicos, los runners alojados siguen siendo gratuitos e ilimitados en todos los planes. Ese único dato explica por qué tantos devs indie eligen GitHub Actions por defecto: el trabajo open source y los side projects funcionan básicamente a coste cero.

Cuando excedes la cuota gratuita, las tarifas actuales por minuto de los runners alojados son aproximadamente:

  • Linux (Ubuntu): alrededor de 0,006 $/min en el tier de 2 cores.
  • Windows: alrededor de 0,010 $/min.
  • macOS: alrededor de 0,062 $/min.

Son precios de contador tras el recorte de enero de 2026. Pueden evolucionar, así que conviene verificarlos en la página oficial de precios de GitHub antes de cerrar un presupuesto.

Coste mensual real para equipos pequeños (estimaciones)

Estas son cifras realistas en orden de magnitud, no promesas. Asumen runners Linux de 2 cores al precio post-recorte, plan Team y unos 21 días laborables al mes.

  • Desarrollador solo, ~1.000 minutos Linux al mes: aproximadamente 0 $ — entra en los 2.000 minutos gratuitos.
  • Equipo de 5, ~15.000 minutos, sobre todo Linux con algo de Windows: aproximadamente 70–80 $/mes tras agotar los minutos gratuitos.
  • Equipo de 10, ~30.000 minutos, mezcla de Linux/Windows/macOS: aproximadamente 300–350 $/mes.
  • Organización de 50, ~150.000 minutos con macOS en la mezcla: aproximadamente 1.300–1.400 $/mes, que suele ser el punto de inflexión donde autoalojar compensa.

La variable más importante en estas cifras es macOS. Un build de iOS de 15 minutos que corre 50 veces al día en macOS alojado puede costar más al mes que todo el Linux alojado de varios ingenieros juntos.

GitHub Actions alojado vs. runners autoalojados: el trade-off honesto

Los runners alojados son el botón fácil. GitHub aprovisiona una VM limpia para cada job, tú no gestionas la máquina y solo pagas por los minutos que usas. Para un dev solo o un equipo de tres, casi siempre es la decisión correcta: tu tiempo vale más que los pocos dólares de compute que ahorras autoalojando.

Los runners autoalojados empiezan a ganar cuando se cumple una o varias de estas condiciones:

  • Tu factura se acerca a varios cientos de dólares al mes y la carga es lo bastante estable como para mantener una máquina ocupada.
  • Necesitas hardware especializado: una CPU más potente, una GPU, más RAM, una máquina Apple Silicon para builds rápidos de macOS.
  • Los arranques en frío te están matando. Un runner autoalojado en caliente puede empezar un job en segundos, mientras que los runners alojados suelen hacer cola entre 10 y 30 segundos mientras arranca una VM nueva.
  • Tienes jobs que tocan datos sensibles — secretos, cargas reguladas, integraciones on-prem — que no deberían salir de tu red.

Los trade-offs son reales y conviene nombrarlos:

  • La caja es tuya. Parches, actualizaciones de seguridad, limpieza de disco, churn de versiones de Docker: todo recae en ti.
  • Escalar es más difícil. Un pool de runners alojados crece contigo en un día punta. Un runner autoalojado es un recurso fijo a menos que montes un autoscaler tipo Actions Runner Controller (ARC).
  • La higiene de versiones importa. Los runners autoalojados deben estar en la versión v2.329.0 o superior para poder registrarse (hubo un corte duro en marzo de 2026). Fija tus versiones y ten un runbook de actualización.

Para un founder solo, el patrón más simple de autoalojamiento es un VPS pequeño (de los que usarías para staging) con el runner instalado y una cola de 1–2 jobs simultáneos. Eso cubre la mayoría de side projects y deja tu factura de CI cerca de cero, mientras mantienes elasticidad en los runners alojados para picos.

Velocidad de arranque en frío: el coste oculto de los runners alojados

Este es el factor infravalorado. Los runners alojados levantan una VM nueva por job. Para un lint de 30 segundos, ese overhead es la mayor parte de tu factura y la mayor parte de tu espera. Los runners autoalojados que se mantienen calientes responden en segundos, algo que importa más de lo que parece en el feedback loop de un PR.

Trucos prácticos sin salir de los runners alojados:

  • Cachea a fondo — gestores de paquetes (npm, pip, Gradle), capas de Docker y fixtures de tests. Una instalación de seis minutos que pasa a 30 segundos al restaurar caché es más rápida y más barata.
  • Separa los jobs pequeños de los grandes para que el lint y los tests unitarios no hagan cola detrás de un build de release de 20 minutos.
  • Usa filtros por path para que un PR solo de backend no ejecute toda la matriz de tests de frontend.

Cómo estimar tu coste mensual real antes de crecer

Una hoja de cálculo le gana a cualquier calculadora. Este es el modelo simple que funciona para equipos indie:

  1. Cuenta los últimos 30 días de minutos de build reales desde la página de facturación de tu proveedor de CI, desglosados por sistema operativo del runner.
  2. Aplica tu tarifa por minuto actual (y el multiplicador de macOS si aplica).
  3. Suma un 50% de colchón para el crecimiento del próximo trimestre — la mayoría de equipos subestima lo rápido que escala el uso de CI cuando empiezas a desplegar más a menudo.
  4. Resta tu cuota gratuita según tu plan.
  5. Compara esa cifra con el coste de un VPS pequeño siempre encendido (suele ser 10–25 $/mes) más el tiempo de ingeniería para mantener sano un runner autoalojado.

Si el número autoalojado gana por un margen claro y se mantiene ganando tras aplicar un crecimiento de 2–3×, merece la pena autoalojar. Si es un empate o casi empate, quédate en alojado: tu tiempo es la línea más cara.

Cuándo tiene sentido un servicio de CI alternativo

GitHub Actions no es la única respuesta, y para algunos equipos ni siquiera es la mejor. Razones habituales para mirar elsewhere:

  • Necesitas builds más rápidos en monorepos pesados. Algunos servicios ofrecen cachés más agresivas y una topología de build farm mejor afinada de fábrica.
  • Ya estás pagando por otra plataforma. Si tu equipo vive en GitLab o usa Bitbucket, la CI incluida puede salir más barata que añadir GitHub Actions encima.
  • Publicas apps iOS y los minutos de macOS te revientan el presupuesto. Algunos servicios ofrecen runners Apple Silicon alojados a tarifas por minuto más bajas que GitHub, o agrupan macOS en una suscripción plana.
  • Necesitas funciones de compliance que GitHub no expone limpiamente: logs de auditoría, cifrado con BYOK, pinning regional.

La decisión rara vez es marca contra marca — suele ser una cuestión de encaje: si el servicio se adapta a la forma de tu carga, a tus necesidades de seguridad y a las herramientas que ya usa tu equipo.

Un marco de decisión simple

  • Solo o 1–3 devs, sobre todo web, sobre todo Linux, < 5.000 min/mes: quédate en GitHub Actions Free o Team. No lo pienses demasiado.
  • Equipo pequeño, cargas mixtas, acercándote a 15.000 min/mes: empieza a cachear fuerte, separa jobs y revisa tu factura cada mes. Estás en la zona de “vigilar de cerca”.
  • Equipo mediano o cualquier trabajo de iOS/macOS a escala: modelo híbrido — runners alojados para checks de PR con picos y runners autoalojados para los jobs pesados y predecibles (builds de release, suites de integración, macOS). Presupuesta ambos.
  • Cargas reguladas o hardware que no puedes obtener alojado: solo autoalojado, con autoscaling y pinning de versiones desde el día uno.

FAQ

¿GitHub Actions es realmente gratis para repos privados?

Incluye una cuota mensual gratuita (2.000 minutos en Free, 3.000 en Team), y los repositorios públicos son ilimitados. Cuando excedes la cuota, pagas por minuto, así que “gratis” significa de verdad “gratis hasta cierto punto”.

¿Va a empezar GitHub a cobrar por los runners autoalojados?

Se anunció en diciembre de 2025 una tarifa de plataforma de 0,002 $/min para runners autoalojados y se pospuso a las 48 horas tras el feedback de la comunidad. A mediados de 2026 no se factura. Planifica como si pudiera volver, pero no la pagues todavía.

¿Cuántos minutos de build usa un proyecto solo típico?

La mayoría de proyectos solos caben sin problema en los 2.000 minutos gratuitos. El salto suele llegar cuando sumas tests de integración completos o un pipeline de release que corre con cada tag.

¿Cuándo merece realmente la pena autoalojar?

Cuando tu factura en alojado supera de forma estable varios cientos de dólares al mes, cuando necesitas hardware especializado (Apple Silicon, GPUs, mucha memoria) o cuando los arranques en frío afectan de verdad a la experiencia de tu equipo.

Fuentes