Ruby on Rails End-of-Life Schedule (and What It Means for Your App)
Somewhere in your Gemfile.lock there is a Rails version number, and attached to that number is a date after which the framework stops receiving security patches. Rails publishes these dates well in advance, so nobody has to be surprised by one, but they live scattered across a policy page that explains the rules, a maintenance page that lists living versions and stays silent about dead ones, and community trackers that show tables without any guidance. This page puts the whole schedule in one place, current as of July 2026, and then walks through what to do depending on which row your app sits in. We re-verify the dates and re-date this page whenever the schedule moves, so it’s safe to bookmark.
One warning before the table: your app is on two support clocks at once, because Ruby versions expire on a schedule of their own, independent of Rails. The second clock catches teams who are perfectly current on the first one, and we cover it below.
How the Rails support clock works
The official maintenance policy is short and mechanical. Each minor series (think 7.2, 8.0, 8.1) receives bug fixes for one year after its first release and security fixes for two years, and after that it reaches end of life. New feature releases aim for a roughly six-month cadence, and if a year passes without one, the previous release’s support window extends until the next release actually ships, so the schedule never strands you between releases.
Two details in that policy are easy to read past. First, Rails uses what the policy calls shifted semver: a minor release like 7.1 to 7.2 can contain breaking changes, which is why each minor series gets its own support window and why each hop is a real upgrade project. Second, the policy says exactly what end of life means: “it’s your own responsibility to deal with bugs and security issues.” A fix might still get backported to a stable branch in git, but no gem release is ever cut from it, so nothing will ever reach your app through a routine bundle update again.
Every Rails version’s support dates
Dates for the supported series come from the official maintenance page; the historical rows come from endoflife.date, which keeps tracking the versions the official page no longer lists. Where the two sources overlap, they agree exactly. Verified July 30, 2026.
| Series | First released | Bug fixes | Security fixes | Status in July 2026 |
|---|---|---|---|---|
| 8.1 | Oct 22, 2025 | until Oct 10, 2026 | until Oct 10, 2027 | Fully supported |
| 8.0 | Nov 7, 2024 | ended May 7, 2026 | until Nov 7, 2026 | Security fixes only |
| 7.2 | Aug 9, 2024 | ended Aug 9, 2025 | until Aug 9, 2026 | Security fixes only, ending within days |
| 7.1 | Oct 5, 2023 | ended Oct 1, 2024 | ended Oct 1, 2025 | End of life |
| 7.0 | Dec 15, 2021 | ended Oct 15, 2023 | ended Apr 1, 2025 | End of life |
| 6.1 | Dec 9, 2020 | ended Dec 15, 2021 | ended Oct 1, 2024 | End of life |
| 6.0 | Aug 16, 2019 | ended Dec 15, 2021 | ended Jun 1, 2023 | End of life |
| 5.2 | Apr 9, 2018 | ended Dec 15, 2021 | ended Jun 1, 2022 | End of life |
If you want the patch level too: as of July 29, 2026 the newest releases are 8.1.3.1, 8.0.5.1, and 7.2.3.2, and being on a supported series only helps if you actually install them.
Where the clock stands right now
Reading that table from the top, the July 2026 picture is narrow: Rails 8.1 is the only series with full support, meaning both bug fixes and security fixes. Rails 8.0 left its bug-fix window on May 7, 2026 and keeps security coverage through November 7, 2026, so it has months left. And Rails 7.2 receives its last security patches on August 9, 2026, which is days away as we write this. After that date, the oldest Rails with any support at all will be 8.0, and 8.0 itself will be inside its final quarter.
Everything below that line has been unsupported for a while: 7.1 since October 2025, 7.0 since April 2025, 6.1 since October 2024, and the 6.0 and 5.x series for years. If your app sits in one of those rows, support has already ended, and the question is how long you’re comfortable running without it.
The second clock: Ruby
Rails runs on Ruby, and Ruby’s support schedule ticks independently. Since Ruby 2.1, a new version has shipped every December 25, and each one gets roughly three years and three months of life, so the end-of-life dates land at the close of March: Ruby 3.2 reached end of life on March 31, 2026, Ruby 3.3 follows on March 31, 2027, Ruby 3.4 on March 31, 2028, and Ruby 4.0 (released December 25, 2025) runs until March 31, 2029.
Each Rails version also sets a Ruby floor. Per the official upgrade guide, Rails 8.0 and 8.1 require Ruby 3.2 or newer, Rails 7.2 requires 3.1 or newer, and the 7.0 and 7.1 series run back to Ruby 2.7.
Put those two lists side by side and you hit a trap that none of the version tables call out: the minimum Ruby for both currently supported Rails series is itself already past end of life. Ruby 3.2 stopped receiving patches on March 31, 2026, so an app running Rails 8.1 on Ruby 3.2 meets every requirement Rails sets and still carries an unpatched interpreter into production. So when you check your Rails row in the table above, confirm your Ruby is 3.3 or newer while you’re at it. The official guide’s advice for getting there is to upgrade Ruby separately from the Rails work, Ruby first, as its own deploy.
What end of life actually costs
End of life is invisible on the day it happens. The app boots, the tests pass, and nothing changes, which is exactly why so many apps drift years past their dates. The cost arrives with every security release you no longer receive, because each advisory for the supported versions doubles as a public description of holes that will never be patched in yours.
March 2026 made this concrete. The Rails team shipped security releases for its three supported series (7.2.3.1, 8.0.4.1, and 8.1.2.1) fixing ten vulnerabilities in one round, among them an Active Storage path traversal, cross-site scripting in tag helpers, and a denial-of-service in number helpers, per HeroDevs’ breakdown of the releases. Apps still on 7.0 or 7.1 received none of those fixes, and the advisories describing them are public. Unsupported framework versions are also the kind of line item that security questionnaires and compliance reviews ask about directly, so the exposure tends to show up in sales and audit conversations long before anything goes wrong in production.
What to do, based on the version you’re on
If you’re on 8.1, you’re in the good row. Stay on the newest patch release (8.1.3.1 as of late July 2026), confirm your Ruby is 3.3 or newer, and note October 10, 2026 in your calendar, because that’s when 8.1’s bug-fix window closes and the next series becomes the one to plan for.
If you’re on 8.0, this is a scheduling problem, and a small one. Security coverage runs through November 7, 2026, and the 8.0 to 8.1 hop is modest next to the major-version climbs, but it deserves the same careful rhythm: bump, deploy the bump alone, watch it under real traffic, then flip the new defaults on gradually. Our Rails 7 to 8 upgrade checklist describes that rhythm, and most of it applies to this hop unchanged.
If you’re on 7.2, act now. Your security fixes end on August 9, 2026, and the sensible target is 8.1, because 8.0 is already inside its final months. Our Rails 7 to 8 guide walks the hop end to end, with the checklist as the run sheet. Check Ruby while you’re in there: 7.2’s floor is Ruby 3.1, which has been out of support since March 2025, so most 7.2 apps owe a Ruby hop as part of the same project.
If you’re on 7.1 or 7.0, the app is already past end of life, and the important decision is the target. 7.2 would be a dead end, since its own support closes on August 9, 2026; the upgrade guide’s path still moves through it one minor at a time, but the project should plan to land on 8.1. How long does a Rails upgrade take shows how to size that project against your own app in about an hour, and the 7-to-8 materials above cover the later hops.
If you’re on 6.1 or older, the version bump is the small piece at the end, because at several majors of distance the preparation usually dominates: test coverage, abandoned gems, and the front-end era set the real timeline, and the framework hops follow from there. Our Rails 6 to 7 guide covers the first climb, the duration estimator will tell you what you’re actually looking at, and this is the situation our Ruby on Rails practice most often starts with: an audit that turns “we’re behind” into a plan with dates on it.
Staying ahead of the schedule
The cheapest way to handle this table is to never appear in its bottom rows. Take each hop while your current series is still in its bug-fix window. On that rhythm each upgrade stays a small project, because you’re never crossing more than one series or racing a security cutoff, and the dates in this post turn into routine calendar entries. We’ve made the longer argument for why waiting gets more expensive in the economics of Rails maintenance, and our maintenance retainer post describes what keeping an app current involves as an ongoing arrangement. We run our own site this way (eclipticideas.com is a Rails 8 app on Render), and the hop-at-a-time rhythm is how we deliver major Rails and Ruby upgrades with zero downtime.
Your next step takes five minutes. Open your Gemfile.lock, find the rails line, find your row in the table above, and put its next date on your calendar. If you land on a row that’s already past end of life, or the date is closer than you’d like, tell us where you are and we’ll help you scope the path back to a supported version.
