Rails 8.0 security support ends November 7, 2026: what to do now

Rails 8.0 stops receiving security fixes on November 7, 2026. After that date, the Rails core team will not publish security patches for any 8.0.x release, so an app still on 8.0 is exposed to every vulnerability found from then on. If your app runs Rails 8.0, the practical move is to upgrade to Rails 8.1 now, while the step is small. If it runs Rails 7.2 or older, it is already past the end of security support and the upgrade is more urgent, not less.

This post is for founders, product owners, and engineering leads who run a Rails app in production and need to know what the date means and what to do this month.

What the dates are

The Rails maintenance policy page lists the supported release series. At the time of writing it shows:

• Rails 8.0.x: bug fixes ended May 7, 2026; security fixes end November 7, 2026.
• Rails 8.1.x: security fixes until October 10, 2027.

The Rails team's end of support announcement explains that Rails 8.0 support had already been extended by six months, because the policy extends support when no release is made within one year. The same announcement states that Rails 7.0 and 7.1 have reached their end of life, and it listed Rails 7.2 security fixes as supported until August 9, 2026, a date that has now passed.

What "end of security support" means in practice

• No new patches. When a vulnerability is found in Rails after November 7, there will be no official 8.0.x release that fixes it.
• Your app keeps running. Nothing switches off on the date. The risk grows quietly with every advisory that does not get a patch for your version.
• Gems move on too. Over time, gem maintainers drop support for Rails versions the core team no longer supports, so staying put also makes later upgrades harder.
• Audits and customers ask. Security reviews, compliance questionnaires, and enterprise customers often ask whether your framework is still supported.

Find out where you stand

1. Check the version. Look for the rails line in Gemfile.lock, or run bin/rails -v.
2. Check the Ruby version the app runs on, since a Rails upgrade may need a Ruby upgrade alongside it.
3. Check the tests. If the paths that make you money are not covered by tests, add those first. They are what make the upgrade safe.
4. List the gems that pin Rails or have not been updated in a long time. These are usually where an upgrade gets stuck.

If you are on Rails 8.0: upgrade to 8.1

Moving from 8.0 to 8.1 is one minor version, which is about as small as a Rails upgrade gets. A typical order:

1. Get the test suite green on Rails 8.0 and fix any deprecation warnings it prints.
2. Read the official Upgrading Ruby on Rails guide for the 8.0 to 8.1 section.
3. Update the rails gem, run bin/rails app:update, and review each changed file instead of accepting it blindly.
4. Run the tests, fix what breaks, and deploy behind your normal monitoring.
5. Move config.load_defaults to the new version once the app is stable, rather than in the same release.

If you are on Rails 7.2 or older: do not jump straight to the latest

Older apps are best upgraded one version at a time, with tests around the paths that matter and a deploy at each step, so a problem is easy to find and roll back. Skipping several versions in one go is how upgrades turn into months-long branches that never merge. Our Rails 5 or 6 to Rails 7 or 8 upgrade checklist walks through that order, and Upgrading an old Rails app without a rewrite covers why a rewrite is rarely the answer.

What if you cannot upgrade before November 7?

Many teams will not finish in three weeks, and that is fine as long as the work has started. In the meantime:

• Keep 8.0 on its latest patch release, so you at least have every fix published before the cut-off.
• Watch the security announcements on the official Rails blog and forum, and judge each advisory against your app.
• Put a date on the upgrade, and treat it as product work with an owner, not something done when there is spare time.

Not sure how big your upgrade is? Bring your Gemfile.lock to a Systems Discovery Call and we will tell you what we see.

How we handle Rails upgrades

We start with a written assessment of the current Rails and Ruby versions, gem dependencies, deprecations, and the order to upgrade in. Then we audit the app, add tests around the paths that matter, and upgrade it one version at a time while it keeps serving customers. Ruby is upgraded alongside Rails, and outdated or abandoned gems are replaced or updated. Each version step ships as a small, tested increment while the app stays live, with error tracking and monitoring so problems surface before users report them. The details are on our Rails upgrade page.

Common questions

Will my Rails 8.0 app stop working on November 7?

No. It keeps running. What stops is official security patches for 8.0.x, so new vulnerabilities found after that date will not be fixed for your version.

Is upgrading from 8.0 to 8.1 a big job?

Usually it is the smallest kind of Rails upgrade, one minor version. The size depends mostly on your test coverage and on how many gems pin older Rails versions.

We are on Rails 6 or 7. Should we rewrite instead?

Rarely. A rewrite throws away years of business logic; a stepwise upgrade keeps what works and modernizes the framework underneath it.

Next step

If your app is on Rails 8.0 or older, book a Systems Discovery Call. It is 45 minutes on your app, and you leave with a clear picture of the upgrade path, whether you hire us or not.