Synthetic Industry

Platform · updated 2026-10-11

Rails upgrades: keep the Ruby, framework and JavaScript decisions apart

A Rails upgrade is three separate moving parts. Name which one is blocking you, and what each vendor still supports, before choosing a job.

Three separate decisions

A Rails app is held back by up to three different things: the Ruby version, the Rails version and the way its JavaScript is built. Each has its own support dates, its own failure modes and its own tests. Treating them as one upgrade makes a failed test run uninterpretable, because a change in Ruby, in Rails and in the bundler arrived together.

  • Ruby: the interpreter, whose branches have their own end-of-life dates.
  • Rails: the framework, upgraded one minor version at a time.
  • JavaScript build: Webpacker, jsbundling, import maps or the asset pipeline, which has its own retirement history.

What the vendors say, as checked on 11 October 2026

The Rails maintenance page lists two series: 8.1, whose bug-fix window ended on 10 October 2026 and which has security fixes through 10 October 2027, and 8.0, with security fixes through 7 November 2026. Its policy is one year of bug fixes and two years of security fixes after the first release of a series. A series that is not listed is no longer maintained upstream. On the Ruby side, 3.2 is end of life as of 1 April 2026, and Rails 8.0 and 8.1 require at least Ruby 3.2, so a realistic Rails 8 target also needs a newer Ruby: 3.3 is in security maintenance and 3.4 in normal maintenance. Re-check these pages before you act, because the dates are the vendors' to change.

  • Record the date you checked each page; support tables move.
  • Ask your host which Ruby versions it can run: the host's cut-off may come before the upstream one.
  • A support date is a reason to plan, not a measure of how risky your current version is.

Order of work that keeps failures readable

The Rails upgrade guide asks for passing tests first, then the latest Ruby you can, then Rails one minor version at a time, reading deprecation warnings at each step. The guide gives only minimum Rubies, and a published compatibility table recommends Ruby 3.3 for Rails 7.0 and 3.4 from 7.1, so in practice Ruby is raised again as each Rails minor allows. Each step runs the update task, whose file changes are reviewed one by one, and new framework defaults are enabled gradually through a generated defaults file rather than all at once. This order means a failure points at one change.

  • Get the suite to run and record its baseline, including tests that already fail.
  • Raise Ruby to the newest version your current Rails minor supports, then re-run the suite before any Rails change.
  • Step through each Rails minor version and keep the result of each run.

Which job fits

An app on Rails 7.0, 7.1 or 7.2 with a runnable test suite and gems that support Rails 8.1 matches the fixed Rails 7 to 8.1 job. An app on Rails 6 or older needs an inventory first: the autoloader and the JavaScript build are decisions that come before any version number. Keeping the app current afterwards is a different, recurring job. None of these jobs includes a hosting move, a database change or a rewrite of unmaintained gems, and none needs your production secret key or a password in the first enquiry.

  • Send the Rails and Ruby versions, how the JavaScript is built and the flows that matter.
  • Prices are untested proposals; payment follows the agreed checks and your sign-off.

Sources and limits

  • Rails maintenance policy Checked 2026-10-11.
    • The page lists the 8.1 series for bug fixes through 10 October 2026 and security fixes through 10 October 2027, and the 8.0 series for security fixes through 7 November 2026.
    • Minor releases receive bug fixes for one year and security fixes for two years after the first release in the series.
  • Rails guides: upgrading Ruby on Rails Checked 2026-10-11.
    • Rails 8.0 and 8.1 require Ruby 3.2.0 or newer; Rails 7.2 requires Ruby 3.1.0 or newer; Rails 7.0 and 7.1 require Ruby 2.7.0 or newer.
    • The guide recommends moving one minor version at a time with passing tests first and upgrading to the latest Ruby you can before Rails; it gives only minimum Ruby versions per series.
    • Zeitwerk autoloading is mandatory from Rails 7.0.
  • FastRuby: Rails and Ruby compatibility table Checked 2026-10-11.
    • The table, updated 30 September 2026, recommends Ruby 3.3 for Rails 7.0.Z and Ruby 3.4 for 7.1.Z, 7.2.Z, 8.0.Z and 8.1.Z.
  • Ruby: maintenance branches Checked 2026-10-11.
    • Ruby 3.2 is end of life (2026-04-01); Ruby 3.3 is in security maintenance with an expected end of life of 2027-03-31; Ruby 3.4 is in normal maintenance.