Show HN: Runners GitHub x64 e Arm open-source

Artigo original ↗ Discussão no Hacker News ↗

Runners open-source do GitHub Actions da Ubicloud prometem até 10x menos custo em CI e builds mais rápidos ao rodar em provedores bare-metal como Hetzner, atraindo forte interesse de equipes frustradas com os preços e o desempenho do GitHub, especialmente para cargas Linux. Os comentários examinam como a Ubicloud lida com cache, isolamento de armazenamento, licenciamento (incluindo a mudança para AGPL) e conformidade, além de apontar lacunas como suporte a macOS, SOC 2 e possíveis conflitos com os termos de serviço do GitHub. A conversa situa a Ubicloud em um mercado concorrido de runners de terceiros e setups auto-hospedados, refletindo uma tendência mais ampla em direção a uma infraestrutura de CI mais barata e mais controlável.

Produto e Posicionamento

  • Runners open-source do GitHub Actions em x64/ARM, construídos sobre provedores bare metal (notavelmente Hetzner), comercializados como ~10x mais baratos e mais rápidos do que os runners hospedados pelo GitHub.
  • Apresentados como parte de uma “cloud aberta e portátil” mais ampla que você pode auto-hospedar ou usar como serviço gerenciado.
  • Alguns comentários apontam que a mensagem está um pouco vaga/pesada em marketing; sugerem explicar concretamente o que é, por que é mais barato, e refinar o texto da landing page.

Desempenho, Cache e Armazenamento

  • Vários usuários relatam grandes ganhos de velocidade e grandes economias de custo em comparação com runners hospedados pelo GitHub, às vezes reduzindo o tempo de build pela metade ou mais.
  • O I/O nos próprios runners do GitHub é amplamente visto como ruim; migrar para Hetzner ou hardware auto-hospedado frequentemente traz melhorias de I/O de 5–10x.
  • O cache é atualmente um ponto doloroso: o cache hospedado pelo GitHub é lento pela rede; alguns usuários obtêm builds mais rápidos desativando o cache e recalculando.
  • A Ubicloud está projetando seu próprio cache (camadas Docker, caches de pacotes). As sugestões incluem discos locais persistentes por builder, semelhante a outras plataformas de CI.
  • Discussão sobre arquitetura de armazenamento: necessidade de copy-on-write/clone-on-attach para evitar copiar uma imagem base de ~86GB a cada execução; preocupações com o desempenho de CoW/CoA e escolhas de filesystem (ext4 vs btrfs, alternativas a ZFS).

Segurança, Apagamento de Dados e Conformidade

  • Os runners são efêmeros; as VMs são desligadas e os dispositivos de bloco são removidos entre jobs. Futuramente, está planejado “cryptoshredding” para runners do GH, semelhante às VMs normais.
  • Há perguntas sobre se a reutilização de blocos poderia vazar dados; uma mitigação discutida é criptografia em repouso com KEK/DEK (ainda não totalmente aplicada aqui).
  • Alguns se preocupam com a ausência de SOC2 e certificações semelhantes, especialmente dado o acesso dos pipelines de CI a segredos e chaves de deploy.
  • Há perguntas sobre conformidade com GDPR e jurisdição da empresa; isso não ficou claramente respondido no thread.

Runners para macOS e Questões de Licenciamento

  • O custo do CI em macOS é um grande problema. O licenciamento da Apple (Macs físicos, mínimo de locação de 24h) torna o hosted macOS complicado.
  • A Ubicloud não planeja suporte a macOS devido a licenciamento e restrições de hardware; outros provedores são mencionados para macOS ARM.
  • Discussão paralela sobre os novos runners M1 do GitHub e ofertas de macOS de terceiros.

Questões Legais / ToS do GitHub e Ecossistema

  • Há preocupação de que vender “runners GitHub hospedados” possa conflitar com os Termos de Serviço do Actions do GitHub. As interpretações divergem:
    • Um lado: os ToS proíbem transformar Actions em uma plataforma comercial de CI, mas não banem runners de terceiros.
    • Outros: ofertas que monetizam runners para Actions ainda podem estar em uma área cinzenta.
  • Muitas alternativas e ferramentas adjacentes foram mencionadas (BuildJet, WarpBuild, RunsOn, Cirun, módulos Terraform da AWS/Hetzner, setups auto-hospedados).

Licenciamento e Abertura

  • O projeto recentemente mudou da licença Elastic para AGPLv3; o thread observa e celebra essa mudança.
  • Parte da documentação ainda referenciava Elastic e precisava de atualização; os mantenedores indicam que isso está sendo corrigido.

Preocupações Diversas

  • Interesse em suporte futuro para Windows e FreeBSD.
  • Pedidos por intervalos de egress privados / execução dentro da VPC do cliente para acesso interno seguro.
  • Breve menção ao impacto ambiental de desativar caches versus cache intensivo de rede; reconhecido como complexo e difícil de quantificar.