Rails promises bug fixes for one year and security fixes for two years after the first release in a minor series. After that the series is unsupported, and the project says dealing with bugs and security issues becomes your own responsibility. Treat the dates on the live policy page as the authority, because they change with each release.
What the policy says
The Rails maintenance policy splits support into three groups: new features, bug fixes and security issues. The project aims for a release with new features every six months. For the other two groups the rule is a fixed clock that starts at the first release of a minor series.
| Kind of fix | How long a minor series gets it |
|---|---|
| New features | Next release, about every six months (the stated aim) |
| Bug fixes | One year after the first release in the series |
| Security fixes | Two years after the first release in the series |
The policy page lists the current supported series with dates. When I checked it on 19 October 2026, the 8.0.x series was listed for security fixes until 7 November 2026, and 8.1.x until 10 October 2027. Those dates will move, so read the page again before you plan around them.
Why the clocks differ
A bug fix can change behaviour, so the project limits how long it keeps patching old lines. A security fix is treated as more urgent, so the window for it is longer. For you, that means a series can be out of bug fix support and still receive security releases. It also means the security clock is the one that decides when you must upgrade.
What unsupported means
The policy is blunt. When a series is no longer supported, it is your own responsibility to deal with bugs and security issues. The maintainers say they may provide backports of fixes in git, but no new versions will be released. If you are not comfortable maintaining your own version, the stated advice is to upgrade to a supported one.
That has a practical consequence for scanning. Once a series leaves support, a fix may exist only as a patch in a repository, so a scanner that looks for a fixed release number can show no fix available. Read that result as a support gap, not as safety.
Steps for teams that depend on a framework
- Find the exact minor series of every framework you run, not just the major version.
- Look up the security end date for each series on the maintainer's policy page.
- Put those dates in your backlog as upgrade deadlines, with a buffer of at least one release cycle.
- Plan the upgrade when the security date is still months away, since framework upgrades often need code changes.
- If you must run an unsupported series, record who owns the risk and what compensating controls apply.
- Re-check the page each quarter, because the supported list changes with every minor release.
Why this matters to maintainers too
If you maintain a library that targets a framework, the framework's support window is a good guide for your own. Supporting a series that the framework has dropped means you carry its security debt. Say in your README which framework series you test against.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each dependency lists a version, then ask which of those versions still sit inside a support window.
Quick check
Does a security fix always come with a bug fix release?
Not necessarily. Under the Rails policy a series can be past its bug fix window and still receive security releases until its security date.
What should I do the week a series loses security support?
Move to a supported series. If that is not possible yet, record the exception, the owner and the controls you rely on, and set a firm date.
Where do I find the current dates?
On the maintainer's own policy page. Dates shown in articles go out of date quickly.
How Safeguard helps
Safeguard can help you keep the support dates in view. Its SBOM and dependency scanning list the exact versions you run, reachability analysis shows which known issues your code can actually reach, and policies and gates can stop a build that pulls in a version you have decided to retire. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try the free scan on a manifest first.
Sources
- Ruby on Rails, Maintenance Policy: bug fix and security windows, supported series list, and unsupported series wording. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
