Ruby and Rails at GitHub: The Case for Always Being Current

GitHub.com started as—and remains—a Ruby on Rails monolith. That application has grown to nearly two million lines of code, touched daily by more than 1,000 engineers, and is deployed up to 20 times per day. Rails upgrades, however, no longer represent the major migration events they once did.

A Weekly Rails Upgrade Cadence

Every Monday, a scheduled GitHub Action workflow opens an automated pull request bumping the Rails version to the latest commit on the Rails main branch. The full build suite runs against that version, and once everything passes, the change is reviewed and shipped the following day. From kickoff to production, the entire cycle fits inside a single week.

That rhythm contrasts sharply with earlier practice. Previously, GitHub spent months moving from a custom Rails fork to a stable upstream release, maintaining two Gemfiles along the way to guarantee compatibility with the upcoming version. The current process removes that overhead, and it has operational benefits beyond convenience:

  • Latest features, immediately. Engineers always develop against the most recent Rails, including improvements to database connection handling, view rendering speed, and the steady stream of work landing upstream.
  • A near-empty patch stack. Because GitHub runs current Rails, fixes can be proposed directly to Rails rather than maintained as local patches awaiting a future release.
  • Simpler upstream contribution. Instead of flagging behavior that will be corrected in an unspecified future version, any engineer can submit a fix and see it in production one week later.
  • Improved security posture. With a weekly upgrade pipeline already in place, patching in response to a security advisory is routine rather than an exceptional, unplanned effort.
  • Smaller migration surfaces. Incremental upgrades isolate changes, making incompatibilities easier to trace. The most painful problems in a major upgrade typically come from unexpected changes of unknown origin—a problem this approach mostly eliminates.
  • Better engineering feedback loops. Catching defects on the Rails main branch and contributing fixes back deepens the team's understanding of both the framework and the host application.

Continuous Ruby Testing, Too

The same philosophy extends to the Ruby runtime itself. Shortly after moving to Ruby 3.1 in February 2022, GitHub configured its CI to run a parallel build against Ruby 3.2-alpha. A second build track always exercises the monolith against the most recent Ruby commit, refreshed weekly alongside the Rails version. Production, however, receives only numbered Ruby releases—the preview builds serve entirely to catch compatibility problems early.

That preparation paid off. By early December 2022, CI showed the application was compatible enough to route a percentage of production traffic at the Ruby 3.2 release candidates, giving the Ruby team feedback before the usual Christmas release. The process surfaced, among other things, a regression in allocations tied to keyword argument handling—fixed prior to final release—and a subtle behavioral difference when to_str and #to_i are applied.

Frequent upgrades made those problems ordinary to resolve, and the monolith was running Ruby 3.2 within a month of release—the fastest Ruby upgrade GitHub had ever performed. That record didn't last: Ruby 3.2.1 was adopted on release day itself.

Side benefits include an easy path for testing and profiling Ruby changes internally before proposing them upstream. That makes regressions in the application easier to isolate and clarifies how proposed changes would perform in full production scale.

Prerequisites and Payoff

None of this is turnkey. Frequent Ruby and Rails releases assume a level of engineering maturity that includes a deep test suite and tooling for progressive rollout. Confidence at GitHub rests on tests likely catching most issues and deploy processes catching any that slip through before they reach customers.

Given those foundations, the argument for the same cadence elsewhere is straightforward: consider weekly Rails upgrades and ongoing testing against bleeding-edge Ruby. In the words of Rails Conf 2022 keynote speaker Eileen Uchitelle:

Ultimately, if more companies treated the framework as an extension of the application, it would result in higher resilience and stability. Investment in Rails ensures your foundation will not crumble under the weight of your application.

Treating a core framework as an afterthought is, in her analysis, a widespread leadership miscalculation. Regular upgrades and deliberate framework investment ensure the foundation keeps pace with the application. For GitHub, the arrangement gives the Ruby and Rails ecosystems real feedback from a large production system—and keeps the platform itself running on the best available versions of both.