¿Por qué GitHub Actions es tan lento? Cómo acelerarlo

La mayor parte de un trabajo lento de GitHub Actions ocurre antes de que se ejecute la primera prueba. Configurar Node, descargar las dependencias, compilar la imagen de Docker: los mismos minutos, en cada push, mientras alguien de tu equipo espera una marca verde. Con facturación por minuto, además, pagas esos minutos.

Skipbox es un ejecutor de GitHub Actions que conserva su máquina entre trabajos, así que lo que instaló un trabajo sigue en el disco para el siguiente. Cambia una línea, runs-on: skipbox, y el trabajo se ejecuta en tu propia máquina por $39 fijos al mes con minutos ilimitados.

Cada trabajo empieza en una VM vacía

Un ejecutor hospedado en GitHub es una máquina virtual nueva para cada trabajo. No tiene nada de lo que descargó o compiló el trabajo anterior, así que cada trabajo reconstruye el mismo estado:

Las tres primeras filas no producen nada nuevo. Devuelven la máquina a como estaba ayer.

La caché de GitHub suaviza esto sin cambiarlo. Guarda 10 GB por repositorio, elimina las entradas que ningún trabajo leyó en 7 días, y una rama de funcionalidad nueva no puede leer la caché de otra rama de funcionalidad. Incluso un acierto descarga y descomprime un archivo en cada ejecución.

Lo que te cuesta la espera

Supón que la configuración ocupa 3 minutos de cada trabajo y que tu equipo ejecuta 100 trabajos al día. Son 300 minutos al día de tiempo de ejecutor dedicados a devolver la máquina a su estado, y cada pull request espera su parte. Las revisiones empiezan más tarde, las fusiones llegan más tarde, y los ingenieros se ponen con otra cosa mientras esperan.

Con facturación por minuto, esos minutos están en la factura. Un ejecutor de 4 vCPU, según los minutos al mes:

Las cifras de GitHub son la factura después del uso incluido en GitHub Team. Pon tus propios minutos en la calculadora de la página de inicio; no hace falta iniciar sesión.

Y la cantidad de ejecuciones solo sube:

• Agentes de código con IA. Cada push de un agente inicia la CI. La espera y la factura crecen con los push, no con la plantilla.
• Más pruebas. Una suite E2E o una matriz repite la configuración en cada trabajo que agrega.
• Presupuestos. Limita la factura con un presupuesto de GitHub y los trabajos dejan de iniciarse a mitad de mes, lo que detiene las fusiones.

Acelerarlo por tu cuenta es un proyecto

Quedarte en los ejecutores hospedados en GitHub y hacerlos rápidos significa asumir trabajo como este:

• Basar las claves de caché en hashes de los lockfiles y ajustar restore-keys hasta que acierten
• Agregar buildx y exportar la caché de Docker con cache-to, dentro de los mismos 10 GB
• Dividir las pruebas en fragmentos, donde cada fragmento repite la configuración y suben los minutos cobrados
• O mantener tu propio ejecutor autohospedado: aprovisionarlo, actualizar el sistema operativo, limpiar entre trabajos y arreglarlo cuando se cae

Cada una de estas soluciones rodea una máquina que lo olvida todo. Skipbox conserva la máquina, así que ninguna hace falta.

Lo que cambia con Skipbox

La configuración se queda en el disco. Tus trabajos se ejecutan en la máquina propia de tu cuenta, y la máquina se mantiene entre trabajos. Las imágenes de Docker, las capas y la caché de compilación; las cachés de paquetes de npm, pip, Gradle y más; las herramientas que instalan setup-node y similares. Al menos 7× el espacio de caché de GitHub, sin caducidad a los 7 días y sin reglas de ramas.

Máquinas más grandes a precio fijo. Los compiladores y los ejecutores de pruebas inician un proceso por núcleo, así que más núcleos acortan los pasos que dependen de la CPU.

Los minutos son ilimitados en todos los planes. Los trabajos de Skipbox no usan minutos de GitHub, así que un presupuesto de GitHub nunca los detiene.

Ninguna máquina que cuidar. Skipbox aprovisiona la máquina, actualiza el sistema operativo y las herramientas, limpia después de cada trabajo, comprueba el estado de la máquina y reconstruye la que falla la comprobación.

Pasarte es una línea

jobs:
  build:
    runs-on: skipbox # was ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

1. Inicia sesión en Skipbox con GitHub.
2. Instala la app de GitHub de Skipbox y elige los repositorios.
3. Cambia runs-on y haz push.

Lo que instala el primer trabajo está en el disco para el segundo.

Seguridad

• La máquina es solo de tu cuenta. Ningún trabajo de otra empresa se ejecuta en ella.
• Después de cada trabajo se borran las credenciales, los procesos y los contenedores del ejecutor. Desde el 13 de noviembre de 2026, tu checkout y su salida de compilación (el target/ de Cargo) se quedan en tu propia máquina para tus próximos trabajos; “VM nueva en cada trabajo” le da a cada trabajo una máquina nueva.
• El código de personas sin acceso de escritura (como los pull requests desde forks) se ejecuta en una máquina nueva y desechable.

Los detalles están en cómo se aíslan los trabajos.

Pruébalo con tu trabajo más lento

La prueba es gratuita durante 7 días o 3000 minutos de trabajos, lo que ocurra primero, y no pide tarjeta. Pasa tu trabajo más lento a runs-on: skipbox, ejecútalo dos veces seguidas y pon los tiempos de cada paso junto a los de GitHub.

Actualizado el 11 de noviembre de 2026