Show HN: Open-source x64 और Arm GitHub runners
Ubicloud के open-source GitHub Actions runners bare-metal providers जैसे Hetzner पर चलकर CI लागत को 10x तक कम करने और builds को तेज़ करने का वादा करते हैं, जिससे GitHub की pricing और performance से परेशान टीमों में खासा उत्साह है, विशेषकर Linux workloads के लिए। टिप्पणीकर्ता यह समझने की कोशिश करते हैं कि Ubicloud caching, storage isolation, licensing (AGPL में बदलाव सहित), और compliance को कैसे संभालता है, साथ ही macOS support, SOC 2, और GitHub की terms of service से संभावित टकराव जैसे gaps भी नोट करते हैं। यह बातचीत Ubicloud को third-party runners और self-hosted setups के एक crowded क्षेत्र में रखती है, और सस्ती, अधिक controllable CI infrastructure की व्यापक प्रवृत्ति को दर्शाती है।
उत्पाद और पोज़िशनिंग
- x64/ARM पर Open-source GitHub Actions runners, जो bare metal providers (विशेष रूप से Hetzner) पर बने हैं, और GitHub के hosted runners की तुलना में लगभग 10x सस्ते और तेज़ होने का दावा किया गया है।
- इन्हें एक व्यापक “open, portable cloud” के हिस्से के रूप में पेश किया गया है, जिसे आप self-host कर सकते हैं या managed service के रूप में उपयोग कर सकते हैं।
- कुछ प्रतिक्रिया यह है कि संदेश थोड़ा अस्पष्ट/marketing-heavy है; सुझाव दिए गए कि यह स्पष्ट रूप से बताया जाए कि यह क्या है, यह सस्ता क्यों है, और landing page की wording को और सटीक किया जाए।
प्रदर्शन, कैशिंग और स्टोरेज
- कई उपयोगकर्ता GitHub-hosted runners की तुलना में बड़े speedups और काफी cost savings की रिपोर्ट करते हैं, कभी-कभी build times आधे या उससे भी कम हो जाते हैं।
- GitHub के अपने runners पर I/O को व्यापक रूप से खराब माना जाता है; Hetzner या self-hosted hardware पर जाने से अक्सर 5–10x I/O improvements मिलती हैं।
- कैशिंग अभी एक दर्द बिंदु है: GitHub-hosted cache नेटवर्क पर धीमा है; कुछ उपयोगकर्ताओं को cache बंद करके और recompute करके तेज़ builds मिलती हैं।
- Ubicloud अपनी caching खुद डिज़ाइन कर रहा है (Docker layers, package caches)। सुझावों में हर builder के लिए local persistent disks शामिल हैं, जैसा कि अन्य CI platforms में होता है।
- storage architecture पर चर्चा: हर run में लगभग 86GB की base image को copy करने से बचने के लिए copy-on-write/clone-on-attach की ज़रूरत; CoW/CoA performance और filesystem choices (ext4 vs btrfs, ZFS alternatives) को लेकर चिंताएँ।
सुरक्षा, डेटा वाइपिंग और अनुपालन
- runners ephemeral हैं; VMs को shut down किया जाता है और jobs के बीच block devices हटा दिए जाते हैं। भविष्य में GH runners के लिए सामान्य VMs की तरह planned “cryptoshredding”।
- यह सवाल उठा कि block reuse से data leak हो सकता है या नहीं; एक mitigation पर चर्चा हुई है encryption-at-rest with KEK/DEK (अभी यहाँ पूरी तरह लागू नहीं)।
- कुछ लोगों को SOC2 और समान attestations की कमी को लेकर चिंता है, खासकर क्योंकि CI pipelines के पास secrets और deployment keys तक पहुँच होती है।
- GDPR compliance और company jurisdiction पर सवाल उठे; thread में इसका स्पष्ट उत्तर नहीं दिया गया।
macOS Runners और Licensing Issues
- macOS CI लागत एक बड़ा pain point है। Apple की licensing (physical Macs, 24h minimum lease) hosted macOS को tricky बनाती है।
- Ubicloud licensing और hardware constraints के कारण macOS support की योजना नहीं बनाता; macOS ARM के लिए अन्य providers का उल्लेख किया गया है।
- GitHub के नए M1 runners और third-party macOS offerings पर भी समानांतर चर्चा हुई।
कानूनी / GitHub ToS और Ecosystem
- “hosted GitHub runners” बेचने पर GitHub के Actions ToS से conflict होने की चिंता जताई गई। व्याख्याएँ अलग-अलग हैं:
- एक पक्ष: ToS Actions को commercial CI platform में बदलने से रोकता है, लेकिन third-party runners को नहीं।
- दूसरे: Actions के लिए runners को monetize करने वाली offerings grey area में रह सकती हैं।
- कई alternatives और adjacent tools का उल्लेख हुआ (BuildJet, WarpBuild, RunsOn, Cirun, AWS/Hetzner Terraform modules, self-hosted setups)।
लाइसेंसिंग और ओपननेस
- Project ने हाल ही में Elastic license से AGPLv3 में बदलाव किया; thread में इस बदलाव को नोट किया गया और स्वागत किया गया।
- कुछ documentation में अभी भी Elastic का संदर्भ था और उसे update करने की ज़रूरत थी; maintainers ने बताया कि यह ठीक किया जा रहा है।
विविध चिंताएँ
- भविष्य में Windows और FreeBSD support में रुचि।
- private egress ranges / customer VPC के अंदर चलाने की मांग, ताकि secure internal access मिल सके।
- cache बंद करने बनाम network-heavy caching के पर्यावरणीय प्रभाव का संक्षिप्त उल्लेख; इसे जटिल और कठिन-से-मापने योग्य माना गया।