Ruby 4.0 is Here - What It Actually Means for Your Rails App
Ruby 4.0 landed in December 2025. Rails 8.1.3 followed in March 2026.
If you're running a production Rails application and haven't looked closely at either release yet, this post is for you. Not a feature dump — a practical take on what matters, what you can skip for now, and what you should be doing this quarter.
The headline: Ruby 4.0 is a performance story
Ruby 4.0's big performance headline is ZJIT, a new method based JIT compiler positioned as the next generation of YJIT. But in Ruby 4.0, ZJIT is still experimental. The Ruby team says it's faster than the interpreter, but not yet as fast as YJIT, and advises against deploying it to production for now. For production workloads today, YJIT remains the more practical choice.
If you're already using YJIT on Ruby 3.3 or 3.4, you're already using the more production-proven JIT path available today.
The actionable upgrade path right now:
- Consider moving to Ruby 3.4, and test
--yjiton your workload if you haven't already - Plan a Ruby 4.0 upgrade once your gem dependencies confirm support
- Keep an eye on ZJIT maturity, the Ruby team says the goal is to make it production-ready in Ruby 4.1
What changed in Rails 8.1.3
Rails 8.1.3 is the current stable release, published on March 24, 2026. The 8.1 series, introduced in October 2025, brought a few things worth knowing about:
Active Job Continuations. Rails 8.1 lets long-running jobs resume from the last completed step after interruption or restart, especially useful around deploys and process restarts.
Native Markdown rendering. Rails 8.1 adds direct markdown response rendering (format.md { render markdown: ... }). Minor for most apps, but increasingly relevant if you're building content-heavy or AI assisted features.
Deprecated associations. You can now mark associations as deprecated in the model layer (has_many :posts, deprecated: true), surfacing legacy code usage, including indirect usage - systematically as you refactor. Small feature, high value in large codebases.
The version landscape in April 2026
| Version / status | Current | Notes |
|---|---|---|
| Ruby 4.0 | 4.0.2 | ZJIT experimental |
| Ruby 3.4 | 3.4.9 | Supported 3.x branch in normal maintenance |
| Ruby 3.2 | EOL | Reached end-of-life on April 1, 2026 |
| Rails | 8.1.3 | Current stable |
| Rails 8.0 | 8.0.5 | Moves to security-only support in May 2026 |
| Rails 7.2 | 7.2.3.1 | Still receiving security patches |
| Rails 7.0 / 7.1 | EOL | No longer receiving patches |
Rails 7.0 and 7.1 are end of life. If you're on either, you're not receiving security patches. That's not a future risk, it's a present one.
Rails 8.0.x moves to security-only support in May 2026. If you're on 8.0, moving to 8.1 should generally be a smaller step than a larger deferred upgrade, but it still needs normal testing and an upgrade review.
Ruby 3.2 reached end-of-life on April 1, 2026. If you're still on 3.2, moving to 3.4 is the immediate priority.
The Ruby 4.0 compatibility question
Ruby 4.0 is out, but adopting it today requires care. For production applications, the pragmatic move is:
- Run your CI against Ruby 4.0 now to surface incompatibilities early
- Treat Ruby 4.0 production adoption as a separate track from your Rails 8.1 upgrade
- Don't block a Rails 8.1 upgrade waiting for Ruby 4.0, treat them as separate planning tracks, subject to your app's compatibility matrix
What this means in practice
Most of the teams I work with aren't chasing the cutting edge, they're trying to stay on supported, secure, maintainable versions of their stack. The goal isn't Ruby 4.0 today. It's making sure you're not running on an unsupported framework when an incident forces the issue.
The incremental upgrade path still holds:
Rails 6.1 → 7.0 → 7.1 → 7.2 → 8.0 → 8.1
Ruby 2.7/3.0 → 3.2 → 3.3 → 3.4 → 4.0
Each step can move you closer to currently supported, patched infrastructure. Each step is also smaller than the one that follows if you wait.
Where to focus this quarter
- Get off Rails 7.0/7.1 - they're EOL and no longer receive security patches
- Get off Ruby 3.2 - it reached end-of-life on April 1, 2026
- Target Rails 8.1.3 - current stable, with features like Active Job Continuations, Markdown rendering, and deprecated associations
- Move to Ruby 3.4 - supported 3.x branch in normal maintenance; test
--yjiton your workload - Plan for Ruby 4.0 in H2 - start testing, don't rush production; ZJIT is experimental, and the Ruby team aims to make it production-ready in 4.1
Ruby 4.0 introduces ZJIT, which the Ruby team aims to make faster than YJIT and production-ready in Ruby 4.1. The teams best positioned to benefit are the ones already on supported versions, not the ones catching up from 3.2 or Rails 7.
Need help planning or executing a Rails upgrade? I work with teams across the UK, US, and Europe on fractional and retainer engagements. Get in touch.