Casos de uso
El CI inestable suele ser un entorno que no controlas
Ejecuta tus jobs de GitHub Actions en tus propias máquinas: el mismo equipo, las mismas cachés calientes y los mismos recursos siempre, con un log que puedes ir a leer.
version: 1
budget:
max_cost_usd: 5
policy:
require_checks: true
deny_paths:
- infra/prod/**Un test que falla una de cada diez veces es un problema de entorno mientras no se demuestre lo contrario
Los runners compartidos te dan una máquina nueva y con distinta carga en cada ejecución, que es justo la condición en la que los tests sensibles al tiempo se comportan mal. developerz.ai convierte tus VMs en runners just-in-time de GitHub Actions: un cambio de etiqueta runs-on: y los jobs se ejecutan en hardware que tú dimensionaste, con los límites de recursos que tú fijaste. Cada job sigue corriendo en un contenedor nuevo que se destruye al terminar, así que el aislamiento no depende de que la máquina esté limpia.
Hardware predecible
Elige el tamaño de runner por job —etiquetas de 2 a 32 vCPU— y deja de depurar fallos que en realidad son contención en la flota de otro.
Contenedor nuevo en cada job
Los jobs corren en un contenedor que se destruye al terminar. Nada persiste entre ejecuciones, así que una caché envenenada no te sigue.
El agente vigila el PR
Una comprobación en rojo no es un callejón sin salida: el agente sigue el PR y escala cuando deja de avanzar.
Profundiza
Una etiqueta para mover un workflow
La página de CI muestra el diff exacto, los tamaños de runner y el modelo de seguridad: vida del token, ciclo del contenedor y la regla de los forks.
CI en tu hardwarePon a trabajar una flota de desarrolladores de IA
Trae tus propias claves y tus propias máquinas, coloca un .maintainer.yml y deja correr los bucles — auditado de principio a fin. El acceso es solo por invitación.