If you work on a Rails 7 codebase in 2026, you have probably started thinking about the end of its supported life. Rails 8 is out. Rails 8.1 is on the horizon. The core team’s attention is moving. Your app is not.

This post is the developer-facing answer to “what does Rails 7 LTS mean, and what do I actually need to do to keep this app patchable?”. If you are looking for the CTO / business framing, I covered that in Rails 7 LTS: A CTO’s Guide. This one is about code, gems, and CVEs.

The Rails Maintenance Policy, In Plain English

The Rails core team publishes a security and maintenance policy. The short version:

When Rails 8.0.x is the current line:

Once Rails 8.1 ships, that window slides one more step. So “we’re on Rails 7, we’ll handle it eventually” is a decaying asset.

You can always check the current support status in the Rails security announcements on the Rails blog and in the Gemfile / Gemfile.lock of a maintained app.

What “Rails 7 LTS” Actually Refers To

“Rails 7 LTS” is a phrase that gets used three different ways, and conflating them is the source of most confusion:

  1. The community shorthand for “whichever Rails 7 point release still gets security fixes from upstream.” This is free but shrinking.
  2. Commercial LTS vendors who maintain patched forks of older Rails versions for paying customers. Think of it like extended support contracts for OS releases.
  3. An internal LTS - your team maintains its own patched Rails branch.

For most Rails 7 teams in 2026, the practical choices are: ride the official policy while it lasts and then upgrade, or pay a vendor to extend that runway.

What LTS Does Not Cover

This is the part developers most often get wrong. A Rails 7 LTS arrangement - official or commercial - typically covers:

It does not cover:

If you pay for commercial Rails LTS but leave Ruby 3.0 and Nokogiri 1.13 in place, you still have a security problem. LTS patches one surface of a multi-surface attack area.

A Developer’s Rails 7 LTS Checklist

If your decision is “we’re staying on Rails 7 for another 6-18 months,” here is what that actually means in the codebase.

1. Pin to the highest patched Rails 7.x

Upgrade within the 7 line as aggressively as you upgrade between majors. Move to the latest 7.2.x you can run. Within-minor upgrades are usually cheap and they extend your official support window.

# Gemfile
gem "rails", "~> 7.2.2"

bundle update rails
bundle exec rails app:update

Read every diff from rails app:update. Don’t blindly accept.

2. Lock Ruby to a supported version

Check the current Ruby release branches. As a rule of thumb, if your Ruby minor is more than two years old, it is either already EOL or about to be.

ruby -v
cat .ruby-version

Most Rails 7.2 apps should be on Ruby 3.2 or 3.3 at minimum.

3. Re-baseline your dependency tree

Run this honestly and read the output:

bundle outdated --only-explicit
bundle audit check --update

bundler-audit flags gems with known CVEs. If you have never run it, you will find surprises.

Prioritize:

These are the gems most frequently implicated in real security incidents.

4. Decide on a Rails LTS vendor before you need them

If you think you might need commercial LTS, evaluate vendors now, not the week an unpatched CVE drops. Questions to ask:

5. Set up CVE monitoring

Do not rely on Twitter or Slack to find out your framework has a new advisory.

# In CI
bundle exec bundle-audit check --update

Plus a service like GitHub Dependabot or Snyk to watch Gemfile.lock. Route the alerts to a channel humans read.

6. Keep the upgrade path warm

This is the most skipped step. If you are on Rails 7 LTS, you should still be running a “can we upgrade to Rails 8?” spike every quarter:

git checkout -b spike/rails-8-dry-run
# bump Gemfile to rails 8
bundle update rails
bundle exec rails app:update
bundle exec rspec

Even if you throw the branch away, you now know which gems blow up, which initializers need rewriting, and how big the real upgrade will be. The team that does this quarterly does a Rails 8 upgrade in 3 weeks. The team that does not is the one that eventually pays for a big-bang emergency.

Common Patterns That Make Rails 7 Apps Hard to Patch

A few things I see again and again in apps that end up calling for help:

Sprockets + jQuery + legacy JS build. Every security patch feels scary because the asset pipeline is brittle. Fix the asset pipeline separately from the framework upgrade.

Monkey-patched Rails internals. Somebody patched ActiveRecord::Relation in an initializer five years ago. Now every Rails point release is an adventure. Inventory these patches. Most can be deleted.

Pinned gem versions with no comment. gem "redcarpet", "= 3.4.0". Why? Nobody knows. These are the gems that block security updates. Hunt them down, test removing the pin.

No staging environment that mirrors prod. If you cannot test a security patch in a real staging environment, you cannot apply security patches confidently. Fix staging before you fix Rails.

When to Stop LTSing and Just Upgrade

At some point the math flips and LTS is more expensive than just doing the upgrade. A few triggers:

When any two of those are true, it is time to stop maintaining the bridge and walk across it.

Need help extending Rails 7 safely or planning the move to Rails 8? We run Rails technical audits that map your LTS vs upgrade decision in numbers, Rails Upgrade Express for incremental upgrades, and Rails Care Plans to keep patches flowing every month.

Schedule a consultation or email to talk through your Rails 7 situation.