Ruby on Rails
Ruby 3.2 End of Life: How to Upgrade a Rails App to Ruby 3.4
Ruby 3.2 reached end of life on March 31, 2026. Your Rails app keeps running, but any new vulnerability in the interpreter or its default libraries will not be fixed for that version. If the app also runs Rails 8.0, which loses security patches on November 7, 2026, it is a good moment to plan both upgrades, one after the other. This guide explains which Ruby to target, what tends to break and in what order to do the work.
Rails 8.0 security patches end November 7, 2026. Is your app affected? Check your Gemfile.lock in 10 seconds: free, and the file never leaves your browser.What end of life means for Ruby 3.2
Each Ruby release is maintained for a little over three years: bug fixes first, then security fixes only. After its end-of-life date, the Ruby core team stops releasing patches for it. For Ruby 3.2 that date was March 31, 2026, according to endoflife.date.
Nothing breaks on that day. The risk is gradual: hosting images, gems and tooling slowly drop support, and when a security issue is published, the fix lands in newer versions only. The longer an app stays on an unsupported Ruby, the larger the jump becomes.
- Ruby 3.2: end of life on March 31, 2026.
- Ruby 3.3: supported until March 31, 2027.
- Ruby 3.4: supported until March 31, 2028.
- Ruby 4.0: supported until March 31, 2029.
Ruby 3.4 or Ruby 4.0?
For most production Rails apps on 3.2 today, Ruby 3.4 is the sensible target. It has been out since December 2024, gems have had time to catch up, and it is supported until March 2028. Skipping 3.3 is fine: the Ruby team announces incompatibilities a version ahead, so going straight to 3.4 just means reading both sets of release notes.
Ruby 4.0, released in December 2025, buys one more year of support but removes more: the CGI library is gone from the default gems except cgi/escape, several old Ractor methods were removed, and Net::HTTP no longer adds a default Content-Type header to requests. Its new ZJIT compiler is not recommended for production yet. Choose 4.0 when your critical gems already declare support for it; otherwise move to 3.4 now and plan 4.0 as a separate, smaller step.
What breaks between Ruby 3.2 and 3.4
These are the items from the official Ruby 3.3 and 3.4 release notes that most often surface in Rails applications.
- Gems moved out of the default set: base64, bigdecimal, csv, drb, mutex_m, observer, getoptlong, nkf, syslog, abbrev, resolv-replace and rinda are now bundled gems. If your code or a gem requires them without declaring them, add them to the Gemfile. Ruby 3.3 already warns about this, but bootsnap hides the warning, so run once with DISABLE_BOOTSNAP=1.
- Mutating a string literal in a file without a frozen_string_literal comment now emits a deprecation warning when deprecation warnings are enabled. It is not an error yet, but it shows where code will break in a future version.
- Calling it with no arguments inside a block without parameters now refers to the block's first parameter. Test code that calls a method named it inside blocks deserves a look.
- Hash#inspect output changed to {user: 1} and {"user" => 1}, and error messages now open quotes with a single quote instead of a backtick. Tests that compare inspected hashes or exact error messages will fail.
- Smaller changes: Net::HTTP constants deprecated since 2012 were removed, Timeout.timeout rejects negative values, and the default URI parser now follows RFC 3986.
Upgrade Ruby first, then Rails
The official Rails upgrade guide recommends upgrading Ruby and Rails separately, Ruby first. Rails 8.0 and 8.1 require Ruby 3.2 or newer, so a Rails 8.0 app on Ruby 3.2 can move to Ruby 3.4 without touching Rails, deploy, and then upgrade Rails to 8.1 as a second project.
Keeping the two changes apart matters in production: if something breaks, you know which upgrade caused it, and each deploy can be rolled back on its own. If you are on Rails 7.2, which already lost security support on August 9, 2026, check that your exact Rails version supports the target Ruby before you start, and follow our Rails 7 to 8 guide afterwards.
A short upgrade checklist
For a typical Rails app moving from Ruby 3.2 to 3.4, the work fits in these steps.
- Check the current Ruby and Rails versions in Gemfile.lock and their support dates.
- Run the suite once on 3.2 with DISABLE_BOOTSNAP=1 and deprecation warnings enabled, and fix what they report.
- Add the bundled gems your app needs to the Gemfile and update gems that pin older Ruby versions.
- Switch .ruby-version, the Dockerfile and CI to Ruby 3.4, then run bundle install and the full test suite.
- Fix tests that depend on Hash#inspect output or exact error messages.
- Deploy Ruby alone, watch error tracking for a few days, then plan the Rails upgrade.
Key takeaways
- Ruby 3.2 has had no security fixes since March 31, 2026; Ruby 3.4 is supported until March 31, 2028.
- Target Ruby 3.4 now; move to 4.0 once your critical gems support it.
- Declare the gems that left the default set and run once without bootsnap to see the warnings.
- Upgrade Ruby first, deploy it alone, then upgrade Rails.
Related
Want to review your case with context?
Share the codebase, workflow, or systems involved and the result you need. We will use the call to decide a practical next step.