How to Prepare for Rails 8.0 End-of-Life

Rails 8.0 was a significant release. Released in November 2024, it introduced a new default stack - Kamal 2 for deployments, Solid Queue for jobs, Propshaft for assets. Many teams were very excited to use these new approaches. All three - deployment, background jobs, asset management - do have other solutions, of course. For some teams, keeping their existing solutions makes sense.

Of course, this wasn’t the last Rails release - and, significantly, Rails 8.0 support ends in November 2026: no further security patches from the core team. Non-security related bug fixes end even early in May 7, 2026. This means that even if the new stack or other Rails 8.0 features aren’t particularly enticing for your team, its important to begin planning for Rails 8.0 upgrade.

In this article, we will review the timeline, weigh the risks, and outline a practical path forward. Together, we’ll cover the maintenance policy, practical implications of end-of-life, and a step-by-step upgrade to Rails 8.1.

Lets talk about the Rails maintenance policy first, and what it means for our timing.

The Rails Maintenance Policy

Rails employs a time-based maintenance policy for predictable support periods-essential for upgrade planning and technical debt management. We appreciate this approach because it gives us clear expectations about how long we can expect support for each Rails version. The core team targets new minor versions every six months, and each series then enters a two-phase support model that we can plan around.

The core team targets new minor versions every six months. Each series then enters a two-phase support model:

Bug fixes phase: One year from release, covering performance regressions, logical bugs, and edge cases. During this period, we can expect the core team to address any issues that arise, making it ideal for production deployments.

Security-only phase: An additional year of security patches, for two years total support. Though bug fixes cease during this phase, critical security vulnerabilities continue to be addressed - though we should note that this is the final stage of support for any Rails version.

Note that the policy treats all vulnerabilities equally - no “severe” vs. “regular” distinction. All issues receive patches while in their security window. This does mean that the existence of a vulnerability does not, necessarily, mean that your production app is vulnerable; vulnerabilities often require a very specific set of circumstances to trigger, as you can see by glancing through some of the historical Rails vulnerabilities. Some vulnerabilities even require circumstances that are unlikely to occur in a normal production app.

That, though, doesn’t mean that some new vulnerability won’t cause you grief; the wise course is still to stay as current as you can, because the potential downside for a business critical app is significant.

Of course, the costs can be significant, as well; many apps that are crucial to business operations are feature-complete and may not be undergoing active development; therefore, time and resources from other projects may need to be diverted to make the upgrade happen in a timely manner.

On that front, interestingly, the maintenance policy includes a contingency: if no new release ships within a year, support for the previous release is extended until the new release arrives. This exact scenario occurred with Rails 8.0.

Rails 8.1 required extensive engineering for features like Active Job Continuations, and its release was delayed beyond the typical six-month window. The core team responded by extending Rails 8.0 support by six months.

Rails 8.0 gained a six-month extension due to 8.1 delays. As noted, bug fixes now run to May 7, 2026; security to November 7, 2026.

Given that its already had an extension, one must expect these new deadlines to hold firm, though. Post-May: no framework bugs or leaks fixed. Post-November: fully unsupported-no patches.

As an aside, note that Rails 8.1 offers bug fixes through October 10, 2026, and security patches until October 10, 2027; it is never too early to start planning for the next upgrade.

The Upgrade Process

Speaking generally, the 8.0 to 8.1 upgrades is one of the easier ones; troubled projects usually suffer from poor preparation or weak tests, rather than impossible tech hurdles. Rails upgrades have become smoother since 5.2 and earlier, so if you’re thinking of a traumatic experience with, say, a Rails 4.0 upgrade, this shouldn’t be nearly as bad.

Preparation Steps

A good first step is to audit your source control. Is there more than one repository for this project? For a small team, this may seem an odd question - but for a larger team, its quite possible for more than one repository to exist, though likely not as an intentional choice. Likewise, make sure that all the important source code is commited to source control - and not just the application itself, but things like deployment scripts, Dockerfiles, per-server Puma or other web server configurations, and so on.

Next, take a look at your Ruby versions. Are you using a Ruby management tool, like rbenv ¹ or rvm ². If so, are all your developers using it, or are some relying on system packages? Is the same system being used by the production and staging servers? Ascertain exactly what versions are running, and first, syncronize them - make sure all your development team is using the same version of Ruby.

Assuming your frontend stack requires it, do you know what NodeJS ³ version your developers, production, and staging environment are using? If they aren’t already the same, standardize them at this point.

Using a tool like mise ⁴ or devenv ⁵ is helpful; at Durable Programming, we’ve standardized on Nix ⁶-based solutions, primarily through devenv, but our clients use a wide variety of approaches. Devcontainers ⁷ are also a possibility - much heavier weight, but they offer real advantages for some teams. The big difference between these tools and something like rbenv is the ability to use multiple versions of non-Ruby languages - like NodeJS or Python.

A good next step is to audit dependencies for vulnerabilities and outdated gems:

$ bundle outdated
$ bundle-audit check --update  # bundler-audit (https://github.com/rubysec/bundler-audit)

Trim redundant gems, and look for gems that don’t clearly indicate compatibility with the latest Rails versions.

Focus in particular on gems that tightly integrate with Rails; these are far and away the most likely to break. Something like the ruby-progressbar gem, which does not depend on Rails at all, is much less likely to be broken by a Rails upgrade.

Is it ready?

Rails 8.1 is stable and is in production for many teams-it’s certainly ready from that perspective.

However, for many teams, it took a while for the ecosystem to catch up with Ruby on Rails. Gems like devise, devise-jwt, ActiveAdmin, rails_semantic_logger, paranoia and others all had compatibility issues-but fortunately, as of the time of this article, these problems are largely resolved. If you previously tried to upgrade to Rails 8.1 and were met by a fusillade of gem incompatibilities, you may be pleasantly surprised by the state of the ecosystem now.

Most of the popular gems that still lack 8.1 support also lack 8.0 support-such as the audited gem, which only supports up to Rails 7.2. In those cases, we recommend transitioning to an alternative. For the audited gem, for example, you could look at the paper_trail gem, which does support modern Rails versions.

Next, aim for higher test coverage. Some teams recommend focusing on integration tests; we, however, recommend focusing on unit tests first, as they are more specific - meaning that if something breaks in the upgrade, a good unit test suite will help you pinpoint the problem quickly.

Post-upgrade, test suite optimizations - such as parallel execution enabled by Rails 8.1’s local CI and Ruby 3.4 general speed improvements - accelerate feedback loops dramatically. This enables faster iterations without sacrificing coverage, and generally leads to better developer comfort.

Next Steps

Rails 8.0 EOL approaches-bug fixes end May 7, 2026; security support November 7. We strongy recommend planing the upgrade now to avoid rushed decisions.

We’ve examined the maintenance policy, security risks, Rails 8.1 improvements, dependency considerations, and a methodical upgrade process. Though no single approach fits every application, prioritizing tests, dual booting, and incremental changes yields long-term benefits.

Experiment with these steps in staging first. For deeper details, consult the official Rails upgrade guides or recent RubyConf presentations. Together, we position your application for sustained maintainability.