actions-runner-pool
gharp es un pool autoescalable de runners efímeros para GitHub Actions basado en Docker, diseñado para cuentas personales y multi-repositorio sin depender de Kubernetes.
Ficha actualizada 25 sept 2026, 3:48 · upstream 25 sept 2026, 3:14 · release v1.3.1
Qué es actions-runner-pool
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
gharp (GitHub Actions Runner Pool) es una solución open source que permite gestionar un conjunto dinámico de runners auto-alojados para GitHub Actions. A diferencia de la infraestructura nativa de GitHub, que limita los runners a repositorios u organizaciones específicas, gharp utiliza una aplicación de GitHub y webhooks para crear instancias efímeras bajo demanda. Cada trabajo ejecuta su propia instancia de contenedor Docker, garantizando un entorno limpio tras cada ejecución.
- Ejecutar CI/CD en cuentas personales compartiendo recursos entre múltiples repositorios
- Auto-escalado dinámico de runners basándose en eventos de webhook sin intervención manual
- Gestión centralizada de credenciales y rotación segura mediante un panel de control integrado
- Aislamiento completo de entornos de ejecución para cada trabajo mediante contenedores efímeros
- Arquitectura basada en Docker que elimina la necesidad de Kubernetes o orquestadores complejos
- Panel de control integrado con métricas Prometheus y controles de reintentos/cancelación
- Soporte nativo para credenciales rotadas automáticamente (webhook secret, PEM, client secret)
- Implementación en Go con servidor ligero y gestión de estado persistente vía SQLite
- No soporta repositorios públicos por defecto debido a riesgos de ejecución remota de código
- Requiere acceso al socket Docker del host para la creación dinámica de contenedores efímeros
- La URL BASE_URL es persistente y debe configurarse correctamente desde el inicio
- Dependencia obligatoria de Docker en el sistema anfitrión para la ejecución de runners
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Despliegue recomendado mediante Docker Compose con volumen persistente para datos. Asegurar HTTPS en BASE_URL accesible públicamente. Configurar ALLOW_PUBLIC_REPOS=false por defecto y usar REPO_ALLOWLIST si es necesario. Asignar al menos 4 núcleos CPU y 8 GB RAM al contenedor principal.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.