Bitrise Build Hub - GitHub Actions runners that build 2x faster for your agents
by•
Coding agents push more code, so your CI runs more builds than ever. GitHub's runners are slow, so every extra build sits in the queue and your team waits with it. Bitrise Build Hub runs those builds on the newest Apple Silicon and high-core Linux instead: 54% faster on iOS, 31% on Android.
PRs come back in minutes, and your app ships sooner. You keep GitHub Actions. Changing one line in your workflow is all it takes to run on the best runners made for mobile.
Replies
This looks cool. Is it your own hardware, or built on top of a cloud provider?
@artyom_zhuravlev appreciate your support 🙏
@artyom_zhuravlev thank you!! The hardware is our own. We design our own racks, our "Mini Orchard" fits 32 Mac Minis in a 6U chassis, on 10 Gigabit Ethernet with 4TB NVMe SSDs, in our own US and EU data centres. That's why the whole stack is tuned for mobile rather than rented from a general-purpose cloud, and it's how we keep Xcode current and the cache co-located.
@artyom_zhuravlev Bitrise is vertically integrated, they built their own Mac mini housing for best efficiency for cooling and density, check out this: https://bitrise.io/blog/post/from-ci-pipelines-to-sheet-metal-sorcery-bitrise-introduces-mini-orchard
Congrats on the launch, awesome stuff! Tackling a real problem with runners that struggle to keep up and adapting it to the speed needed for today's development. Im assuming this can be trialed out prior to committing fully
@lex_zavala thank you so much for your support 💜
@lex_zavala thank you! sure, there is a free trial so you can try out all the Build Hub features without committing. If you like the product you can decide later whether to upgrade to a paid plan, if you need extra capacity than what our self-serve plans offer then we can chat and collaborate on a POC :)
Did you know that with Bitrise Build Hub, you get some extras from the Bitrise Platform? For instance, if performance is critical for you, we offer caching. It's a co-located architecture - storage and compute live in the very same datacenters as our runners, giving a near-zero latency, and no additional egress cost.
Key-Value Cache: it's included, and you get 10x more storage for free, compared to the native GitHub experience. During design and implementation, our main goal was to make the user experience as seamless as possible. The result: you can enable it with one click, and you won't have to change anything in your workflows. It works with native GHA actions. 😎
Build Cache for Bazel, Gradle, Xcode and React Native applications, cutting build times by up to 85–90%. Give it a try for free: https://bitrise.io/platform/build-cache. For development teams at high-scale, we also offer Bazel Remote Build Execution. 🚀
Two products in two weeks on ProductHunt? We're on a roll, baby! 🚀 Jokes aside, a 54% increment in speed looks like a very solid selling point against GitHub Actions. Can I ask how this was benchmarked?
@mefiblogger we are very active :)
@mefiblogger Ha, thanks! Happy to show the workings. It's XcodeBenchmark, on Xcode 26.3. Android is the same idea, the Thunderbird for Android app with a Gradle assemble (7m12s on GitHub's 16 vCPU versus 4m58s on our 14 vCPU, thats 31% faster from us on fewer cores with one of our smaller machines vs GitHub's largest!)
@mefiblogger Both are open source, so anyone can run them and see for themselves, and there's a full side-by-side too of how we stack up against GitHub hosted runners on all fronts.
Looks good, I had so many issues with the hosted runners in the past, I'll definitely try this.
@efpe thank you so much for checking Build Hub and considering giving it a try. Here is a good setup video:
Pls ping our team if you have any questions :)
Maybe I should already know this 😅 but I’m actually curious about the infrastructure behind Build Hub.
Do you guys actually own and operate the physical Mac minis yourselves? And how does the Linux side work? How are you able to keep machines pre-warmed and build startup times low across both macOS and Linux?
@daniel_bodnar91 never too late to learn : )
We sure do, we own and operate the physical machines ourselves. The Macs are Apple silicon Mac minis (M4 and M4 Pro, with M5 Pro coming really soon) that we rack in our own data centres, our own design 'the mini orchard', 32 minis to a 6U chassis on 10 Gigabit Ethernet with NVMe storage. The Linux side is AMD EPYC (Zen4/Zen5) in the same facilities, from small runners up to 192 vCPU.
On the pre-warming, it's the same idea on both platforms: we keep pools of VMs already booted from a clean snapshot, sitting ready. When a job comes in it grabs one of those instead of cold-booting a machine, which is what keeps startup times low. Each VM is ephemeral, it runs your build and gets torn down after, and a fresh one takes its place in the pool.
On the Mac side specifically, we run our own macOS virtualization layer on top of Apple's Virtualization framework. That's what lets us turn those minis into fast, consistent VMs at scale, it's handling millions of builds a month now. Owning the whole stack, hardware, network and virtualization, is exactly why we can keep it fast and be first onto each new Apple silicon generation.
@daniel_bodnar91 and if you're interested in the cable management all of that takes, here's a sneak peak 😍
Hey Product Hunt 👋
I'm Tamás, a Solutions Engineer at Bitrise, based in Amsterdam.
My part of Build Hub comes after the landing page. I sit with mobile teams during their trials and PoCs and help them move real workflows over, so I've seen a lot of "before" build logs.
What still makes me smile is how undramatic the switch is. We configure the machine pool, change the runs-on line and push. There's no migration plan and no rewriting workflows, and secrets and steps stay exactly as they were. Then the build finishes early enough that someone on the call scrolls back up to check the tests actually ran 😅
The other thing I hear constantly is less about raw speed and more about waiting. Builds queue in the afternoons. A release gets stuck because the new Xcode isn't on the runner yet. Build Hub gets new Xcode versions within 24 hours, and your build starts when you push instead of waiting for a free machine. That's usually what teams thank us for a few weeks later.
I'm obviously biased, so don't take my word for it. Our iOS benchmark came out 54% faster, but your project is the one that matters. Point your slowest workflow at it during the free trial and compare.
What's your slowest build right now, and how long does it take? Drop it below, I'm genuinely curious 👇🤓
Hi developers,
I’m Balazs, a Product Manager at Bitrise Build Hub, looking after the infrastructure that powers the Bitrise DevOps Platform.
And I'm very proud to bring Bitrise's decade-old macOS build experience to all GitHub Actions users.
What do we offer with Build Hub? How will it improve your GitHub Actions workflows?
✅ The right runner for every workload
macOS: M4 runners from 5 vCPU / 14 GB up to M4 Pro at 14 vCPU / 54 GB
Linux: from small utility runners up to 192 vCPU on Zen4 and Zen5
M5 Pro and M6 Mac mini support coming shortly
✅ Faster machines, better price. You get 2x faster macOS machine types than GitHub-hosted runners, at a lower per-minute cost.
✅ Self-serve pricing
Plans start from $13.50 per month
✅ Xcode 27 GM ready today. Every Xcode beta and stable release lands on Bitrise Build Hub stacks within 24 hours. All iOS devs on Product Hunt will really enjoy this capability.
✅ Rock-solid reliability
The same macOS virtualization stack that runs millions of customer builds every month
✅ Remote access when you need to look inside the Runner. You get SSH and VNC into your runner.
🤩 I work with mobile teams every day. We are aiming to give you the best experience and the fastest feedback loop, so you can keep shipping quality apps to your users.
Happy to answer any questions about the runners, the platform, or where Build Hub is heading next.
honest question since this is your 4th launch and the pitch leans hard on "agents push more code so your CI needs to be faster" - is Build Hub actually new infra, or is it existing Bitrise capacity repackaged for the AI-agent moment because that's the trending narrative right now? the 54%/31% numbers would land better with the baseline runner spec next to them, "GitHub's standard runners" covers a pretty wide range of actual hardware