Reducing GitHub reliability risk for tool installs

Your toolchain still runs through GitHub

You’ve probably encountered the online conversations about GitHub’s AI scaling challenges.  A lot of the chatter is about how forgiving (or not) users should be to GitHub in light of inexorable traffic increases but also GitHub’s own decision-making.

There is certainly irony in the fact that it was a swashbuckling GitHub, against the objections of many open source developers, that pressed Copilot on the industry. Would GitHub be suffocating from the hug of death if it hadn’t brought about its proto-agentic coder?

Maybe yes, maybe no. But now we are here in 2026, and the profound shift in our industry has changed a lot, particularly GitHub’s own stability and reputation. The consequences of GitHub’s outages affect downstream engineering teams in subtle ways, and I’d like to present a short anecdote about how this has seeped into our product.

Let’s say your company decides that the cost of multi-hour downtime is unacceptable, and you are moving your team to a different git forge. GitHub will still continue to be deeply embedded in your developers' lives.

Case in point: mise recently added prebuilt Ruby binary support by default. Before this, running mise use [email protected] would end up compiling ruby from scratch, which takes several minutes. Installing a prebuilt binary takes seconds. This is a legit wonderful feature, and it even got a shoutout from DHH:

But where are these prebuilt binaries hosted? You guessed it: GitHub.

How Bitrise already made Ruby installs fast

At Bitrise, our team maintains VM images that power Bitrise’s CI, Build Hub, and Remote Developer Environment products. We include several Ruby versions in our images to cover most developers' needs. But when the odd workflow inevitably requires a specific version that’s not on the image, this is the time for mise use [email protected], asdf install ruby x.y.z, or our wrapper, bitrise tools install ruby x.y.z.

Why use our wrapper? One reason has been that since last year, bitrise tools install has provided super fast Ruby installs on macOS. So if you are a Bitrise customer, you got fast Ruby installs before DHH did!

How does the bitrise cli achieve this? Via our custom mise plugin, which grabs prebuilt Ruby binaries from nixpkgs. The bitrise cli, under the hood, then wraps mise with this plugin for tool installations.

Should we retire our plugin?

The introduction of native mise support for prebuilt Ruby binaries gives us an opportunity to achieve the same fast installs without our plugin. We can retire it and maintain one less project. Awesome! But should we?

Normally, the question would be decided by weighing the engineering overhead of maintaining an additional project against the risk to end-user experience without that system.

As mentioned, the mise implementation stores binaries on GitHub, so its usefulness is directly tied GitHub’s uptime (if GitHub is down, installs still work. Your builds just get slower, because Ruby falls back to compiling from source).

Alternatively, nixpkgs are hosted by S3 (there is also a self-hosting option), so this brings convenient redundancy.

Why we kept both

In light of recent history, such as the August 17 7+ hour outage, the decision was obvious. There is clear customer benefit to accepting the extra overhead of maintaining a redundant project.

So now, bitrise tools install ruby tries three sources in order:

• nixpkgs
• mise prebuilt binaries
• Build from source

You don't need to change anything, just keep using bitrise tools install and the fallbacks happen automatically.

On top of uptime, another benefit of this redundancy relates to version coverage. Suppose a user wants to install a brand new Ruby version. If nixpkgs is delayed in hosting that prebuilt binary, but mise publishes it sooner, then seamlessly falling back to vanilla mise can provide more complete coverage of fast installs across Ruby versions.

Bitrise's job is to be the boring layer that absorbs upstream chaos

Big kudos to the mise team for adding prebuilt Ruby support. That project’s use of GitHub for hosting these binaries proves that GitHub will remain central to developers' daily lives into the future.

Bitrise's job is to be the boring layer that absorbs upstream chaos. Platform engineers must have this mindset when deciding how to provide reliable and performant experiences for their users. GitHub’s downtime made taking a redundant approach a no-brainer for us, and we expect that to continue in future decisions.