If you are a CTO or founder running a production Rails 7 app, you have probably Googled “rails 7 lts” at least once in the last year. You have customers, revenue, and a backlog. You do not want to stop everything to chase the latest Rails release, but you also cannot let your stack drift into CVE territory.

That is what “Rails 7 LTS” conversations are really about. Not the version number. The question behind the question is: how do I keep this app safe and supportable without pulling the team off product work for six months?

This post walks through what long-term support actually means in the Rails world, how the official maintenance policy works, what third-party LTS offerings do (and do not) provide, and when it is the right business call to stay on Rails 7 a little longer.

What “LTS” Usually Means Everywhere Else

In most ecosystems - Ubuntu, Node, Java - LTS is a formal thing. A vendor picks a release, commits to a fixed number of years of security patches and bug fixes, and publishes an end-of-life date. You install it, you sleep at night, you plan your upgrade a year before EOL.

Rails does not work exactly the same way. And that is the first thing most teams get wrong when they start searching for “rails 7 lts”.

How Rails Actually Handles Long-Term Support

The official Rails maintenance policy follows a simple rolling model:

Translation: when Rails 8.0 is current, Rails 7.2 is usually still receiving attention. When Rails 8.1 ships, Rails 7.x starts sliding down the priority list. When Rails 8.2 ships, vanilla Rails 7 is effectively unsupported by the core team.

So “Rails 7 LTS” is not a version. It is a strategy you have to assemble.

The Three Realistic Options

If you are on Rails 7 today, you essentially have three paths:

Option 1: Upgrade to Rails 8 on the normal cadence

This is the default Rails community answer. Plan a quarter, do the upgrade work, move on. For apps with good test coverage and modest customizations, this is usually the cheapest long-term option - even though it feels expensive today.

Option 2: Pay for commercial LTS support

There are third-party vendors (the most established is the “Rails LTS” project, which has been around for older Rails major versions) that backport security fixes to older Rails releases for a subscription fee. These are legitimately useful for shops that cannot upgrade right now - regulated industries, frozen contracts, giant legacy codebases.

What you get:

What you do not get:

Option 3: Run your own internal LTS

Some teams self-manage: they fork Rails, cherry-pick security patches from upstream, and maintain their own internal gem. This is cheaper than commercial LTS in dollars and vastly more expensive in engineering time. It only makes sense if you have a dedicated platform team and a very specific reason to avoid both Rails 8 and a vendor.

The CTO Decision Framework

Here is the short version of how I help clients pick between these options. Four questions:

1. What is your CVE exposure tolerance?

Is this app behind a VPN on an internal network with no user data? Or is it public SaaS with credit card numbers? The higher the exposure, the shorter the leash on running un-patched Rails.

2. How hard is your Rails 8 upgrade actually going to be?

Most Rails 7.1 and 7.2 apps can be moved to Rails 8 in weeks, not months, if the team is disciplined. Apps stuck on Rails 7.0 with Sprockets, Devise, Sidekiq, and a wall of custom middleware are a different story. Scope this before you decide. A real Rails technical audit beats guessing.

3. What is the opportunity cost of the team doing the upgrade?

An upgrade is not just the calendar time. It is whatever product work you are not shipping that quarter. If the team is heads-down on a revenue feature, paying for commercial LTS for six more months might be the cheaper move - even at a few thousand dollars a month.

4. Do you have a real plan to leave LTS?

This is the one most people skip. LTS is not a destination. It is a bridge. If you sign up for commercial Rails 7 LTS in 2026 and still have no Rails 8 upgrade plan in 2027, you have just bought yourself a more expensive version of the same problem.

Common Mistakes I See

Over the last few years I have watched a lot of Rails 7 apps drift. A few patterns come up again and again:

A Sensible 12-Month Plan for Rails 7 Apps

If I were stepping into a Rails 7 app today as a fractional CTO, here is what the first year would look like:

  1. Month 1: Technical audit. Understand what Rails 7 point release you are on, Ruby version, gem health, test coverage, and biggest upgrade blockers.
  2. Month 2: Decide: upgrade in the next two quarters, or bridge on LTS. Write the decision down with the dollar cost of both paths.
  3. Months 3-4: Incremental cleanup. Patch Ruby, update gems, retire dead code. The Rails 8 upgrade gets easier in direct proportion to how clean the app is.
  4. Months 5-8: Either execute the Rails 8 upgrade in stages, or stabilize on a supported Rails 7 line with LTS coverage.
  5. Months 9-12: Lock in ongoing maintenance so you never end up in the “it has been four years since we touched Rails” situation again.

That last point is the whole game. Apps that get rescued usually got rescued because nobody owned maintenance. See the hidden ROI of regular Rails maintenance for why this compounds.

When to Call for Help

You should probably bring in outside Rails expertise if:

At Rails Fever we do exactly these engagements - scoping the Rails 7 to Rails 8 path, pricing it against staying on LTS, and running the upgrade incrementally so your product roadmap does not freeze.

Need help deciding between Rails 7 LTS and a Rails 8 upgrade? We offer Rails technical audits to map your upgrade path, Rails Upgrade Express for a safe incremental migration, and Rails Care Plans so you never fall behind again.

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