The Rails maintenance policy is lean by design: only the most recent minor version of the most recent two major versions receives security patches. Everything else is on its own.

That policy creates a faster EOL cadence than most teams expect. Rails 7.0 felt modern — it shipped with Hotwire, import maps, and CSS bundling. It reached end of life on April 1, 2025.

Here's the current state of the Rails lifecycle.

Rails EOL Schedule

The Compounding Ruby Problem

Rails 6.x applications typically run on Ruby 2.6, 2.7, or 3.0. All three are EOL:

• Ruby 2.6 — EOL March 2022
• Ruby 2.7 — EOL March 2023
• Ruby 3.0 — EOL March 2024

A Rails 6.1 application on Ruby 2.7 has two compounding EOL layers. New CVEs in either the framework or the runtime will never be patched.

EOL Risk Score for Rails 6.1: 82 Critical
View → endoflife.ai/score/rails/6.1

Understanding the Rails Maintenance Policy

The Rails project publishes three maintenance states:

1. Full maintenance — bug fixes + security fixes (latest two minor versions)
2. Security maintenance only — security fixes only, no bug fixes
3. Unsupported — no fixes of any kind

Today:

• Rails 8.0 — full maintenance
• Rails 7.2 — full maintenance
• Rails 7.1 — security maintenance only until October 2026
• Rails 7.0 and earlier — unsupported

What's New in Rails 8

Rails 8.0 (November 2024) is a significant release focused on reducing external infrastructure dependencies:

• Solid Cache — database-backed caching (replaces Redis for most use cases)
• Solid Queue — database-backed background jobs (replaces Sidekiq for most use cases)
• Solid Cable — database-backed WebSockets
• Kamal 2 — container-based deployment built in
• Thruster — HTTP asset caching and compression proxy

Rails 8 requires Ruby 3.2 or later. If you're on Ruby 3.1 or earlier, upgrade Ruby first.

Upgrade Strategy: One Minor Version at a Time

The Rails team's official guidance is to upgrade incrementally:

6.0 → 6.1 → 7.0 → 7.1 → 7.2 → 8.0

Each minor version includes deprecation warnings for APIs removed in the next version. Skipping versions means missing those warnings and hitting breaking changes blind.

Key steps for any Rails upgrade

1. Check your Ruby version first
Rails 7.2 requires Ruby 3.1+. Rails 8 requires Ruby 3.2+. Upgrade Ruby before upgrading Rails.

ruby --version

2. Use the load_defaults incremental approach
After bumping the gem version, update config/application.rb:

config.load_defaults 7.2  # or whatever your target version is

This activates new defaults gradually. Address each failure before moving to the next.

3. Follow the official upgrade guide
Every Rails version has a dedicated upgrade guide documenting every breaking change.

4. Run your test suite on the new version before deploying
Rails CI should be your gate. If it passes on the target version in CI, production follows cleanly.

Rails CVE History: Not Theoretical

Rails has had real, high-severity CVEs over its lifetime:

• SQL injection through unsafe query parameter handling
• CSRF vulnerabilities in earlier action controller versions
• Mass assignment bypass (the Egor Homakov GitHub hack)
• Regex injection in route handling

The framework's security has improved significantly since the Rails 3/4 era, but CVEs are still disclosed. On an EOL version, those CVEs are never patched.

Check Your Dependencies Too

Your Rails version isn't the only thing with an EOL date. Check:

• Ruby EOL dates
• PostgreSQL EOL dates
• MySQL EOL dates
• Ubuntu EOL dates (your server OS)

Full article with EOL Risk Scores for every Rails version: endoflife.ai/article-rails-eol