¿Mis flujos de trabajo funcionarán sin cambios?
Sí, la mayoría. Skipbox ejecuta los flujos de trabajo de repositorios públicos y privados de organizaciones y cuentas personales de GitHub. La VM es Ubuntu 24.04 en x64 con Docker, git, build-essential, Node 22 y Python 3.12, y el trabajo se ejecuta como un usuario con sudo sin contraseña, igual que en los ejecutores de GitHub. La imagen ubuntu-latest de GitHub trae más cosas preinstaladas, así que agrega actions/setup-java, actions/setup-go y similares para otras herramientas.
¿Por qué es tan barato?
Con la IA escribiendo cada vez más código, la CI se ejecuta más cada mes, y la facturación por minuto crece con cada ejecución. Por eso Skipbox eligió a propósito otro modelo: alquilas por meses una VM solo para tu cuenta. GitHub no cobra los minutos de los ejecutores autohospedados, así que, ejecutes los trabajos que ejecutes, el precio se mantiene fijo en $39 al mes por S. Fluxenic, la empresa detrás de Skipbox, usa servidores de proveedores de nube de bajo costo y servidores propios, y los ofrece como VM de un tamaño útil. Skipbox se encarga de la parte tediosa: registra los ejecutores, limpia después de cada trabajo y comprueba el estado de la máquina. También reconstruye una máquina averiada y mantiene la imagen actualizada. A pleno uso, el precio es 1/12 del de GitHub y 1/8 del de Blacksmith.
¿Por qué es tan rápido?
Porque la máquina es solo de tu cuenta y sigue encendida entre trabajos. Las capas de Docker y las cachés de paquetes de tu último trabajo siguen en su disco, así que una compilación que las usa no tiene que descargarlas ni reconstruirlas. Un trabajo hospedado en GitHub empieza cada vez en una VM nueva con el disco vacío. Incluso S guarda sus cachés en su propio disco de 80 GB. Eso es más de 7x la caché que GitHub da por defecto a un repositorio, y nada en ella caduca tras 7 días sin uso. S también tiene 4 vCPU, más que los 2 núcleos de ubuntu-latest en un repositorio privado.
¿No me saldría más barato alquilar mi propio VPS como ejecutor?
Aunque alquiles un VPS del mismo tamaño en un proveedor importante, no tendrás un ejecutor autohospedado más barato, más rápido y con menos trabajo que Skipbox. Skipbox registra un ejecutor nuevo para cada trabajo y lo quita al terminar. Después de cada trabajo borra las credenciales del ejecutor y conserva tu checkout y la salida de compilación para el siguiente. Comprueba el estado de la máquina, la reconstruye cuando la comprobación falla y mantiene la imagen actualizada. El código de personas sin acceso de escritura (como los pull requests desde forks) se ejecuta en una VM desechable. Obtienes todo eso por $39 al mes con S, cambiando una línea runs-on y sin nada que mantener.
¿Skipbox ejecuta repositorios públicos?
Sí, tanto públicos como privados. El código de personas sin acceso de escritura (como los pull requests desde forks) se ejecuta en una VM nueva que lee tus cachés pero no puede cambiarlas; tu propia máquina solo ejecuta el código de tu equipo.
¿De verdad los minutos son ilimitados?
Sí. Los planes cuestan $39, $79 o $149 al mes, con facturación en dólares estadounidenses, mensual o anual por adelantado al precio de 10 meses, y sin cargos por uso. Un plan limita cuántos trabajos se ejecutan a la vez y el tamaño de cada uno, no los minutos: un trabajo que no cabe espera hasta que termine uno en ejecución, y esperar no suma nada a tu factura. La página de tu organización en Skipbox muestra cuántos trabajos están esperando y cuánto lleva esperando el más antiguo. Un trabajo puede ejecutarse hasta 6 horas.
¿Cómo cuentan los trabajos más grandes en los trabajos simultáneos?
Los trabajos simultáneos se cuentan en trabajos de 4 vCPU. Un plan ejecuta a la vez trabajos hasta su total de vCPU (S 4, M 8, L 16 vCPU), así que un trabajo de 8 vCPU cuenta como 2 y uno de 16 vCPU como 4. El trabajo más grande que puede ejecutar un plan tiene tantos vCPU como el plan: 4 en S, 8 en M, 16 en L. Agrega planes para ejecutar más trabajos a la vez.
¿Cómo se compara Skipbox con los ejecutores de GitHub?
Cada trabajo de Skipbox S tiene 4 vCPU y 16 GB; ubuntu-latest de GitHub en un repositorio privado tiene 2 núcleos y 8 GB. Tu propia máquina además conserva las capas de Docker y las cachés de paquetes de tu último trabajo, así que una compilación que las usa no las vuelve a descargar; un trabajo hospedado en GitHub empieza cada vez en una VM nueva. docker build y docker compose build reutilizan las capas. El builder predeterminado de docker/setup-buildx-action empieza vacío en cada trabajo, así que configura driver: docker en él para usar la caché de la propia máquina. Cuando tu primer trabajo se ejecuta en Skipbox, el panel muestra su tiempo junto a su mediana en GitHub de los últimos 30 días, si GitHub lo ejecutó en ese periodo.
Mi compilación se queda sin memoria en el ejecutor de GitHub. ¿Cuánta memoria tiene Skipbox?
16 GB en el plan S, en tu propia máquina: 2× los 8 GB de ubuntu-latest en un repositorio privado, y lo mismo que el larger runner de GitHub, que tiene 4 núcleos. El plan S tenía antes 8 GB, y no bastaban para openai/codex (rust-v0.159.3): su cargo clippy --workspace --tests solo terminó al mover unos 14 GB a swap comprimido. Con los 16 GB de hoy, la misma compilación mueve a swap unos 20 MB. Para un trabajo que necesite más, el plan L tiene 32 GB.
¿A qué puede acceder Skipbox?
Solo a lo que necesita para registrar ejecutores y comprobar trabajos. En una organización, la app Skipbox CI pide tres permisos: Self-hosted runners (escritura), para registrar en GitHub un ejecutor para cada trabajo y quitarlo cuando el trabajo termina; Actions (lectura y escritura), para ver qué trabajos están esperando, comprobar su estado, leer cuánto duraron tus trabajos en los últimos 30 días para tu cotización y volver a ejecutar un trabajo cuya máquina de Skipbox se detuvo a mitad del trabajo; y Metadata (lectura). La app Skipbox CI nunca edita ni sube tus flujos de trabajo, y no puede leer tu código: cada trabajo hace checkout de tu código por su cuenta, en la VM donde se ejecuta. En una cuenta personal, GitHub solo registra un ejecutor para un repositorio con el permiso Administration, que también abarca la configuración, los colaboradores y las claves de implementación del repositorio. Skipbox (personal) lo pide y lo usa solo para registrar y quitar ejecutores. Una función es la excepción, y solo si la instalas: el botón “Abrir un pull request” del panel usa otra app, Skipbox Migrate, que instalas solo en los repositorios que elijas. Ahí pide acceso de escritura a Contents, Workflows y Pull requests, sube una rama (skipbox/run-ci-on-skipbox) que solo cambia líneas runs-on y abre un pull request desde ella. Nunca fusiona ni toca tu rama predeterminada. Cuando inicias sesión, Skipbox también lee tu dirección de correo electrónico para los avisos de la prueba y de facturación. Como en cualquier ejecutor, la VM de un trabajo contiene los secretos de tu flujo de trabajo y el token de GitHub de ese trabajo, así que el código que ejecuta el trabajo puede leerlos.
¿Dónde se ejecutan los trabajos?
En la propia máquina de tu organización: una VM del tamaño de tu plan (también durante la prueba), y una más con cada plan adicional. Ninguna otra organización la usa. Sigue encendida entre tus trabajos, así que las imágenes de Docker, las cachés, tu checkout y su salida de compilación (el target/ de Cargo y, con turbo 2, la caché de Turborepo) se quedan para tus próximos trabajos. Funciona en servidores que Fluxenic, la empresa detrás de Skipbox, alquila a proveedores de nube o gestiona por su cuenta. La política de privacidad indica cada proveedor y país. Después de cada trabajo se borran las credenciales del ejecutor, las credenciales de git de tu checkout y los archivos de credenciales habituales. Los trabajos que no caben en tus propias máquinas, el código de personas sin acceso de escritura (como los pull requests desde forks) y todos los trabajos con “VM nueva en cada trabajo” se ejecutan en una VM nueva, que se elimina con su disco cuando termina el trabajo. Un trabajo que sigue en ejecución después de 6 horas se detiene. Nada puede conectarse desde internet. El correo saliente (puerto TCP 25) está bloqueado. El resto de internet está abierto, como en los ejecutores hospedados en GitHub. El tráfico no se cobra.
¿Puedo empezar mi máquina de cero o ejecutar cada trabajo en una VM nueva?
Sí. Pulsa “Restablecer la máquina” en “Planes y facturación”, cuando quieras. Activa ahí “VM nueva en cada trabajo” y cada trabajo se ejecutará en una VM nueva.
¿Podemos cancelar o pedir un reembolso?
Cancela cuando quieras; tu plan sigue hasta el final del mes, o del año, que pagaste. Si tus trabajos no son más rápidos en Skipbox que en GitHub, recuperas todo lo que pagaste, tanto en planes mensuales como anuales: pídelo en la página “Planes y facturación” de tu cuenta dentro de los 30 días posteriores a tu primer pago. Skipbox toma la mediana del tiempo de cada trabajo en Skipbox y en GitHub (los 30 días antes de que instalaras Skipbox), pondera cada trabajo según cuántas veces se ejecutó en GitHub y compara los dos totales; un trabajo cuenta cuando se ha ejecutado al menos 3 veces en cada uno, y si no hay ningún trabajo que comparar, no hay nada que reembolsar. Si el primer trabajo que ejecutas después de suscribirte no empieza en 10 minutos, sin contar el tiempo que espera detrás de tus propios trabajos, te reembolsamos el pago completo automáticamente y terminamos el plan. Fuera de eso, un mes o un año pagado no se reembolsa, salvo en los casos que indican los Términos.
¿Qué pasa cuando termina la prueba? ¿Me cobran algo?
No se cobra nada: la prueba no pide tarjeta. Empieza con tu primer trabajo en Skipbox, no cuando inicias sesión ni cuando instalas la app, y ejecuta un trabajo de 4 vCPU · 16 GB a la vez durante 7 días o 3000 minutos, lo que ocurra primero. Hay 1 prueba por cuenta y 1 por persona. Cuando termina, los trabajos nuevos esperan en GitHub hasta que elijas un plan.
¿Cómo ejecuto un trabajo en Skipbox y cómo vuelvo atrás?
Cambia runs-on a skipbox para pasarte y otra vez a ubuntu-latest para volver. Inicia sesión con GitHub, instala la app Skipbox CI en tu organización o Skipbox (personal) en tu cuenta personal, cambia la línea runs-on del trabajo a skipbox y haz commit; para una VM más grande en los planes que la incluyen, usa skipbox-8x16 o skipbox-16x32. Para volver, cambia runs-on: skipbox de nuevo a runs-on: ubuntu-latest. No cambió nada más en tu repositorio.