The Rails maintenance policy gives each minor release series bug fixes for one year and security fixes for two years after its first release. After that, the series is unsupported and handling bugs and security issues becomes your own responsibility. Plan to upgrade within the two year window.
The three groups
The official maintenance page divides support into new features, bug fixes and security issues.
| Group | Policy |
|---|---|
| New features | A release with new features aimed for every six months |
| Bug fixes | Minor releases get bug fixes for one year after the first release in the series |
| Security issues | Minor releases get security fixes for two years after the first release in the series |
The page adds that for an unsupported series, it is your own responsibility to deal with bugs and security issues. It says backports of fixes may be provided in git, but with no guarantee of a gem release.
The page also lists the currently supported series with dates. Those dates change as new versions ship, so read the live list instead of relying on a blog post, including this one.
Reading the two clocks
Bug fix support ends first. Between the end of year one and the end of year two, a series gets only security fixes. That middle year is when many teams feel fine, because nothing is on fire, while quietly falling off the path of ordinary patches.
A useful rule is to treat the end of bug fix support as your planning trigger, and the end of security support as a hard deadline. If you plan at year one, you have a full year of slack for the upgrade. If you plan at year two, you do not.
Step by step: an upgrade cadence
- List every Rails app you own and the minor series each runs.
- Look up each series on the maintenance page and note both end dates in your tracker.
- Set a reminder at the bug fix end date for each app, with a ticket to schedule the next minor.
- Upgrade one minor at a time, running tests and checking deprecation warnings in each step.
- When you reach the latest supported series, set the next reminder before you close the ticket.
If you maintain many apps, stagger the work so that you do not have all of them hitting the same date.
What to do if you cannot upgrade in time
Some apps have constraints: a gem that has not been updated, a database version, a freeze. Write an exception that states the end date you are missing, the owner, the reason, and the controls in place such as network restrictions and extra monitoring. Revisit the exception monthly. An exception without an expiry date is just a decision to stop looking.
A pinned old gem is a signal too. If the gem that blocks your upgrade is abandoned, the real project is replacing it, and the sooner that starts, the cheaper it is.
Quick check
How long do Rails minor releases get security fixes?
Two years after the first release in the series, per the maintenance policy.
What happens after a series becomes unsupported?
Dealing with bugs and security issues becomes your responsibility. Backports may appear in git without a guaranteed gem release.
Safeguard scans your gem dependencies, flags components past support, and shows reachability for known vulnerabilities. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
