Rails support calendar: 2026–2027 deadlines explained

In the Rails support calendar, 7 November 2026 marks the end of published security support for Rails 8.0. That date changes where its next security correction can come from, even if the application still boots, passes its tests and serves customers normally.

The next relevant fix has to reach production. Check that your Rails version, Ruby runtime and operating system still receive the updates you need, and that your team can test and deploy them.

The policy changed because counting releases was not enough

Rails publicly set out its maintenance policy on 24 February 2013, while Rails 3.2 was current. The announcement addressed confusion after recent patch releases. Ordinary bug fixes followed the newest series; security fixes covered recent series; a separate severe-security category extended coverage at the core team’s discretion. This was a policy tied to the position of a release, rather than a fixed calendar window.

The guide was added later in 2013. The guide’s first commit is not the first publication of the policy. The documented problem was uncertainty about which versions received which fixes.

The time-based policy entered the source in July 2024 and received a public announcement that October. Its baseline is a year of bug fixes and two years of security fixes for a series. The separate severe-security tier disappeared. A team maintaining an older application should therefore stop relying on the recollection that a sufficiently serious issue will receive a patch on an old major version.

Resolve compatibility problems while you can plan the work, before an applicable security advisory makes the upgrade urgent.

Rails support calendar: published dates and exceptions

The table records published support cutoffs, checked on 6 September 2026, and the Ruby requirements in the linked release tags. “Ended” means that the series is outside the relevant window; it does not diagnose a vulnerability in an individual application. The concise reference is Allerin’s Rails support calendar.

*These are policy cutoffs, not dates of the last gem. The 2024 announcement allowed additional releases after some cutoffs. The 29 October 2025 announcement subsequently identified 7.0.10 and 7.1.6 as final. A precise single bug-fix cutoff for the older rows would conceal that history.

For Rails 8.0, the general formula would have suggested an earlier bug-fix deadline. The core team’s dated announcement explicitly extended it to 7 May 2026. That was an extension of bug-fix support; it did not move the published November security deadline.

Rails 8.1 has conflicting dates. Its release announcement is dated 22 October 2025, while the maintenance page specifies 10 October for the support anniversaries. This table follows the explicit support dates. It does not silently replace them with dates calculated from the announcement.

The practical meaning of the October bug-fix cutoff is that a team on Rails 8.1 must distinguish a general defect from a security issue when seeking a framework correction. It does not mean that security support disappears that day. Equally, a new feature appearing on the development branch does not extend the support period of an installed release.

The older rows require action for different reasons. Rails 7.2 already crossed its security deadline; installing its July patch does not reopen that window. Rails 7.0 and 7.1 reached published cutoffs before their final announcements. Rails 6.1 received an explicitly announced extra release opportunity after regular maintenance ended. None of those historical exceptions is a commitment to produce the next patch.

A Ruby floor is an installation constraint, not a destination

Rails 7.2 changed the Ruby compatibility policy in 2024: minor Rails releases could now drop Ruby versions whose maintenance had ended. Previously, concentrating those removals at major Rails boundaries meant retaining old runtime compatibility for longer, or removing several versions together. For an application on an older series, even a minor framework step can require a runtime step.

The floors above were checked against each exact tagged gemspec and the corresponding published gem. Here is the executed query for the Rails 8.1 patch used in that check:

gem specification rails -v 8.1.3.1 required_ruby_version

Its actual output:

--- !ruby/object:Gem::Requirement
requirements:
- - ">="
  - !ruby/object:Gem::Version
    version: 3.2.0

Run that query where the named gem is installed. It reads package metadata; it does not boot your application, exercise a native extension, or establish that all dependencies support a newer Ruby. The verification for this article installed only the Rails package metadata, without its dependencies. No application compatibility claim follows from that exercise.

A current interpreter patch also does not establish that every bundled gem is current. Ruby’s 27 August 2026 Resolv advisory calls for a gem update. Keep applicable gem advisories alongside the runtime record.

Record three results separately: whether the Rails gem installs, whether Ruby is maintained, and whether the application’s dependencies work on that runtime. Include startup failures in the comparison between the current and proposed versions.

The July advisory shows why a patch and support differ

The 29 July 2026 Active Storage advisory lists fixed versions 7.2.3.2, 8.0.5.1 and 8.1.3.1. It lists no patched 7.1, 7.0 or 6.1 release. Its affected-application conditions include libvips image processing and uploads from untrusted users. A version alone is not the whole applicability check.

Active Storage arrived in Rails 5.2 in 2018 to upload files to storage services and attach them to Active Record objects. Rails 7.0 changed the default processor for new applications to libvips in 2021 to reduce processing time and resource use. The advisory identifies the newer framework defaults as the switch to vips. For an upgraded application, inspect the effective processor and overrides rather than infer them from the Rails version.

The advisory requires libvips 8.13 or newer. The patched source also checks for the ruby-vips capability supplied from 2.2.1 and raises when its prerequisites are absent. Updating the gem therefore belongs with checking the image it runs in.

For an affected application on an older series, the official workarounds deserve immediate assessment while an upgrade proceeds. The advisory also requires attention to potentially exposed secrets. A supported destination restores eligibility for future framework patches; it does not prove that a past incident has been resolved.

The completion record should identify the deployed package, runtime image, relevant native library and effective configuration. Keep the evidence from the deployed environment. A developer’s successful dependency update cannot establish what a separately built worker or web process actually loaded.

The operating system has its own support boundary

Heroku-22 is based on Ubuntu 22.04 and reaches its published end of life on 30 April 2027. That deadline belongs in the same inventory, but it calls for a separate decision about the stack and native packages. It does not require leaving Heroku.

Keep the stack change distinguishable from the Rails change in the deployment record. When both change together and an image-processing operation fails, the team needs to know whether the framework configuration, native library, build process or application behavior changed. A stack upgrade can be necessary without turning it into a hosting migration.

What to do this week

1. Record the deployed versions. Capture Rails, Ruby, the operating-system image and any native libraries involved in the application’s critical paths. Record where each fact was obtained.
2. Assign each deadline to a decision. Separate the next framework-support boundary, runtime-support boundary and stack-support boundary. Give each an engineering owner and a specific next step.
3. Check applicability before closing an advisory. Keep the relevant configuration, fixed package version, native-library requirements and any required secret-handling work together.
4. Verify the next upgrade step. Identify which runtime can run that step, which dependencies block it and which business workflows must pass before deployment. Use the calendar to choose the destination; use the code to determine the route.

For the route from an application’s current version to a supported destination, see Allerin’s Rails upgrade approach.

Sources

• Current Rails maintenance dates and full policy.
• Original policy announcement; guide introduction; time-based policy change.
• Transition dates and exceptions; final releases and extended support; Rails 8.1 announcement.
• Ruby maintenance branches; Ruby releases; Resolv advisory. Exact Rails gemspecs are linked in each table row.
• Ruby compatibility-policy change; Active Storage introduction; image-processing lineage.
• Active Storage advisory; patched native-library checks; Heroku-22 support period.