Show HN: Runners GitHub de código abierto para x64 y Arm

Artículo original ↗ Discusión en Hacker News ↗

Los runners de código abierto de GitHub Actions de Ubicloud prometen hasta 10x menos coste en CI y compilaciones más rápidas al ejecutarse sobre proveedores de bare metal como Hetzner, lo que despierta un gran interés entre equipos frustrados por los precios y el rendimiento de GitHub, especialmente en cargas Linux. Los comentaristas preguntan cómo gestiona Ubicloud la caché, el aislamiento del almacenamiento, la licencia (incluido el paso a AGPL) y el cumplimiento, al tiempo que señalan carencias como soporte para macOS, SOC 2 y posibles conflictos con los términos de servicio de GitHub. La conversación sitúa a Ubicloud dentro de un campo abarrotado de runners de terceros y configuraciones autoalojadas, reflejando una tendencia más amplia hacia infraestructuras de CI más baratas y controlables.

Producto y posicionamiento

  • Runners de GitHub Actions de código abierto en x64/ARM, construidos sobre proveedores de bare metal (especialmente Hetzner), comercializados como ~10x más baratos y rápidos que los runners alojados por GitHub.
  • Se presenta como parte de una “nube abierta y portátil” más amplia que puedes autoalojar o usar como un servicio gestionado.
  • Algunos comentarios señalan que el mensaje es algo vago y demasiado orientado al marketing; se sugiere explicar de forma concreta qué es, por qué es más barato y afinar el texto de la página de inicio.

Rendimiento, caché y almacenamiento

  • Varios usuarios informan de grandes mejoras de velocidad y ahorros importantes frente a los runners alojados por GitHub, a veces reduciendo los tiempos de compilación a la mitad o más.
  • La E/S en los runners propios de GitHub es ampliamente considerada deficiente; pasar a Hetzner o a hardware autoalojado suele dar mejoras de E/S de 5–10x.
  • La caché es actualmente un punto débil: la caché alojada por GitHub es lenta por red; algunos usuarios obtienen compilaciones más rápidas desactivando la caché y recomputando.
  • Ubicloud está diseñando su propia caché (capas de Docker, cachés de paquetes). Se sugieren discos persistentes locales por builder, similares a otras plataformas de CI.
  • Discusión sobre la arquitectura de almacenamiento: se necesita copy-on-write/clone-on-attach para evitar copiar una imagen base de ~86GB en cada ejecución; preocupaciones sobre el rendimiento de CoW/CoA y la elección del sistema de archivos (ext4 frente a btrfs, alternativas como ZFS).

Seguridad, borrado de datos y cumplimiento

  • Los runners son efímeros; las VMs se apagan y los dispositivos de bloque se eliminan entre trabajos. En el futuro se planea “cryptoshredding” para los runners de GH, similar a las VMs normales.
  • Hay preguntas sobre si la reutilización de bloques podría filtrar datos; una mitigación discutida es el cifrado en reposo con KEK/DEK (todavía no aplicado por completo aquí).
  • A algunos les preocupa la falta de SOC2 y certificaciones similares, especialmente dado que las canalizaciones de CI tienen acceso a secretos y claves de despliegue.
  • Se plantean preguntas sobre el cumplimiento de GDPR y la jurisdicción de la empresa; no se responde claramente en el hilo.

Runners de macOS y problemas de licencias

  • El coste del CI en macOS es un gran problema. La licencia de Apple (Macs físicos, mínimo de 24h de alquiler) hace que el macOS alojado sea complicado.
  • Ubicloud no planea soporte para macOS debido a restricciones de licencia y hardware; se mencionan otros proveedores para macOS ARM.
  • Discusión paralela sobre los nuevos runners M1 de GitHub y ofertas de macOS de terceros.

Legal / ToS de GitHub y ecosistema

  • Preocupa que vender “runners de GitHub alojados” pueda entrar en conflicto con los Términos de Servicio de Actions de GitHub. Las interpretaciones difieren:
    • Un lado: los ToS prohíben convertir Actions en una plataforma de CI comercial, pero no prohíben runners de terceros.
    • Otros: las ofertas que monetizan runners para Actions podrían seguir estando en una zona gris.
  • Se mencionan muchas alternativas y herramientas adyacentes (BuildJet, WarpBuild, RunsOn, Cirun, módulos Terraform para AWS/Hetzner, configuraciones autoalojadas).

Licencia y apertura

  • El proyecto cambió recientemente de la licencia Elastic a AGPLv3; el hilo señala y celebra este cambio.
  • Parte de la documentación seguía haciendo referencia a Elastic y necesitaba actualización; los mantenedores indican que eso se está corrigiendo.

Preocupaciones misceláneas

  • Interés en soporte para Windows y FreeBSD en el futuro.
  • Solicitudes de rangos de salida privados / ejecución dentro de una VPC del cliente para acceso interno seguro.
  • Breve mención del impacto ambiental de desactivar cachés frente a la caché intensiva en red; se reconoce como algo complejo y difícil de cuantificar.