Here is a pattern we see again and again. A team calls us about a Rails app that “just needs a small fix,” and within an hour we find the real story: the app has been running on a version of Ruby or Rails that stopped getting security updates a long time ago, and nobody realized it.
The app still works, so the version number never got touched. Then one day a security hole gets announced, or a tool refuses to install, or a new developer spends their entire first week wrestling with a tangle of outdated libraries.
Upgrading is not exciting work. It does not add a shiny feature your users will notice. But keeping your app current is one of the smartest, cheapest things you can do for it, and skipping it quietly gets more expensive every month.
This post is a plain walkthrough. We will cover why upgrading matters, what you actually get in the newest versions, the real benefits, the warning signs that your app is overdue, and a step by step guide for doing it safely. Along the way we will flag the moments where it makes sense to bring in help.
Why Upgrade at All?
The short answer is safety. Ruby and Rails each stay “supported” for a set amount of time, and once that clock runs out, you stop getting security fixes. From that point on, if a new vulnerability shows up, patching it is entirely your problem.
If your application has reached end-of-life versions, it may be time to consider professional Ruby on Rails Development Services for modernization and long-term maintenance.
Here is how long support lasts today. Rails supports each release for about one year of bug fixes and two years of security fixes [2]. Ruby supports each yearly version for a little over three years [1]. Put simply, the calendar decides this for you whether you plan for it or not:
- Ruby 3.1 lost support in March 2025.
- Ruby 3.2 lost support in March 2026.
- Rails 7.1, 7.0, 6.1 and older no longer get security fixes.
- Rails 7.2 gets its final security fix in August 2026.
If your app runs on any of these, you are running code that nobody is patching anymore. Everything else we mention below (aging libraries, harder hiring, slower performance) is real too, but security is the thing that turns “we should upgrade someday” into “we need to upgrade this quarter.”
There is also a momentum problem. Ruby and Rails move forward together, and the wider ecosystem follows. Libraries drop support for old Ruby versions. New Rails features expect a modern setup. So the longer you wait, the bigger the eventual jump becomes. Think of it like home maintenance: repainting every few years is easy, but ignoring it for a decade means you are now repairing the walls too.
What Is New in the Latest Versions?
As of August 2026, the current stable versions are Ruby 4.0.6 and Rails 8.1.3 [6]. Here is what changed and why it is worth caring about.
Rails 8: fewer moving parts
The big idea in Rails 8 is “you do not need a fancy hosting platform anymore.” It now ships with almost everything a real app needs built in, so you do not have to glue on extra services [3].
- One database, fewer dependencies. Three new tools, Solid Queue (for background jobs), Solid Cache (for caching), and Solid Cable (for live updates), all run on your regular database instead of needing a separate system like Redis. Solid Queue already handles 20 million jobs a day at the email company HEY [3]. For a lot of apps, this means you can remove Redis and Sidekiq entirely.
- Easy deployment. A tool called Kamal 2 comes ready to go. One command takes a plain Linux server and turns it into your running app, no expensive hosting platform required.
- A simpler asset pipeline. A new tool called Propshaft replaces the old, complicated Sprockets system with something much lighter.
- Login built in. Rails now generates a basic sign in and password reset system for you, so you do not have to add a heavy third party library on day one.
- SQLite is now good enough for production, which makes small apps and prototypes genuinely easy to launch.
Rails 8.1: reliability polish
Rails 8.1 adds a genuinely useful feature called Active Job Continuations. In plain terms: a long running background job can now pick up where it left off after a restart or deploy, instead of starting over from scratch. It also added cleaner event logging and the ability to render Markdown directly, which is handy for content heavy or AI powered features [3].
Ruby 4.0: an exciting version, but pace yourself
Ruby 4.0 is a big milestone and it introduces some ambitious ideas: a new engine called ZJIT meant to eventually make code run faster, better support for doing work in parallel, and an experimental feature that lets two different versions of the same library live side by side.
Now the important part, the kind of detail that saves you a rough weekend. The headline features are not ready for real world use yet. ZJIT is still experimental and is currently slower than the existing YJIT engine, so the Ruby team openly recommends not using it in production for now [4]. The practical advice from the community is to keep ZJIT off, keep using YJIT, and treat moving to Ruby 4.0 as its own separate project rather than bundling it with your Rails upgrade [5].
The takeaway: get onto Ruby 3.4 and Rails 8.1 now, and treat Ruby 4.0 as a deliberate next step once it settles down.
The Benefits of Upgrading
Beyond “do not get hacked,” here is what you actually gain.
Security you do not have to babysit. On a supported version, fixes arrive automatically as part of normal updates. On an old one, every new vulnerability becomes a manual investigation you have to do yourself.
Free speed. Ruby and Rails get faster and lighter on memory with almost every release. Upgrading is often the cheapest performance boost available, since you get it without changing a single line of your own code.
A simpler setup. As mentioned, Rails 8 can let you drop Redis, Sidekiq, and their configuration. Fewer services means fewer things to watch, secure, and pay for.
Access to the good stuff. New libraries are built for modern Ruby. Staying current keeps updates boring and predictable instead of turning them into a puzzle, and it lets you add new tools without a fight.
Modern Ruby and Rails versions also make it easier to build and maintain scalable APIs. Whether you’re creating new endpoints or modernising existing ones, using the right tools can simplify versioning, parameter validation, and API documentation. If you’re building API-first Rails applications, check out our guide on building RESTful APIs with Grape in Ruby on Rails.
Modern Rails versions also make day-to-day maintenance easier. Whether you’re debugging an issue, automating repetitive work, or running rake tasks from Rails console during development, newer versions provide better tooling, improved compatibility, and fewer dependency-related headaches. Keeping your application up to date ensures these workflows remain reliable and predictable.
Happier developers. Engineers want to work on current technology. An app stuck on an ancient version is hard to hire for and draining to maintain. A modern one is something people are glad to work on.
Cheaper upgrades later. This is the one that really adds up. Upgrading one version at a time is routine. Upgrading five versions at once is a months long project with real risk. Staying near the front of the line keeps every future upgrade small and calm.
Modernizing your Rails application also creates a stronger foundation for integrating AI-powered features, automation, and intelligent workflows using our AI Integration Services.
Once your application is on a supported Ruby and Rails version, it’s much easier to adopt modern AI-assisted development practices and reliable engineering workflows. Learn more in our Beyond Vibe Coding: Building Reliable Software with Agentic Coding Loops article, where we explain how planning, testing, verification, and review loops help teams ship AI-assisted code with confidence.
Upgrading also makes it easier to follow modern Rails conventions and maintain a clean, predictable codebase. As we explored in our Agentic Engineering in Practice: Bringing a Vibe-Coded Rails Project Back to Life article, AI can generate code quickly, but long-term success depends on solid architecture, Rails best practices, and ongoing maintenance. A modern Rails version gives teams the foundation to apply those practices consistently.
Signs Your App Needs Upgrading
Not sure whether you are overdue? These are the clear signals:
- You are past the end of life. Check your Ruby and Rails versions against the support dates. If either one is no longer supported, you are already behind.
- Updating one library breaks ten others. When a single update sets off a chain reaction of conflicts, your dependencies have aged past the easy point.
- Your libraries are frozen on old versions. A project pinned to years old versions of everything is a sign the whole thing is stuck in time.
- Your logs are full of deprecation warnings. These are Rails politely telling you what it is about to remove. Ignored warnings become tomorrow’s broken app.
- New teammates cannot get it running. If a setup needs an old Ruby, obsolete system tools, or secret tribal knowledge, your stack has drifted away from the rest of the world.
- Security scanners keep flagging problems with no fix available. This is the loudest alarm of all.
- You cannot use a tool you want because it needs a newer Ruby or Rails than you have.
Any one of these is a nudge. Two or more is a plan. This is usually the point where teams bring in outside help, because spotting the problem is easy but doing the actual upgrade is where the hours disappear.
How to Upgrade: A Practical Step by Step Guide
The golden rule: upgrade one small version at a time, and never upgrade Ruby and Rails together. Do them as separate steps you can check independently.
- Build your safety net first. An upgrade is only as safe as your tests. If your test coverage is thin, improve it before touching any version numbers, because your tests are what prove the upgrade actually worked.
- Read the upgrade guide. The official Rails upgrade guide (https://guides.rubyonrails.org/upgrading_ruby_on_rails.html) lists what changes in each version. Do not skip it. It is your map.
- Do Ruby and Rails separately. Upgrade Ruby first to a supported version, get everything passing, and deploy. Then upgrade Rails. If you change both at once and something breaks, you will not know which one caused it.
- Move one version at a time. If you are on Rails 6.1, go to 7.0, then 7.1, then 7.2, then 8.0, then 8.1. Do not leap straight to the newest. Each hop has its own guide and its own cleanup.
- Let Rails help. After bumping the version, the built in update task walks you through configuration changes one by one. Review each change instead of accepting it blindly.
- Turn on new defaults carefully. Rails hides its newest behavior changes behind a switch. Upgrade first with the old behavior kept, get stable, then flip the new settings on one at a time.
- Clear every warning before the next hop. Treat deprecation warnings as errors waiting to happen. Fixing them now is what makes the next version boring instead of painful.
- Test against the new version early. Add the new Ruby and Rails to your automated testing before you commit to them. This catches problems while you still have a working version to fall back on.
- Check your libraries first. Make sure each one supports the version you are targeting. Abandoned libraries are the most common thing that blocks an upgrade, so plan to replace them.
- Roll out through staging, not straight to users. Never let a version’s first real traffic be your live site. Test it in a staging environment, check everything, then release.
A reliable deployment pipeline is equally important. Our DevOps & Cloud Engineering team helps organisations automate deployments, reduce downtime, and safely release application upgrades.
If your team does not have the time to run this from start to finish, this is exactly the kind of work our organisation takes on. We look at where your app is today, map out the version by version path, clear the warnings, replace dead libraries, and get you back onto a supported version with your tests passing and your site stable.
The Bottom Line
If your Ruby or Rails version is no longer supported, this is not a someday task. It is the next thing on your list, because right now you are running code that nobody is patching. If you are supported but a version or two behind, schedule one small hop this quarter while it is still easy.
Either way the move is the same: get to Ruby 3.4 and Rails 8.1 along the well travelled path, clean up your warnings, and keep Ruby 4.0 in view as a deliberate next step rather than a rushed leap. The best time to upgrade is before you are forced to. The second best time is now.
And if you would rather not do it alone, our organisation helps teams upgrade and modernize Ruby on Rails apps safely, from a stalled old version all the way to the current release. Get in touch and we will start with an honest look at where your app stands and what it will take to bring it up to date.
Abbreviations and Terms
- CVE: Common Vulnerabilities and Exposures. A publicly listed, officially recognised security flaw.
- EOL: End of Life. The date after which a version stops receiving official updates, including security fixes.
- Gem: A packaged Ruby library that you add to your app (managed with a tool called Bundler).
- JIT: Just In Time compiler. Technology that speeds up code by compiling parts of it while the app runs.
- YJIT: The current, production ready JIT engine in Ruby.
- ZJIT: A newer, still experimental JIT engine in Ruby 4.0, not yet recommended for production.
- PaaS: Platform as a Service. A hosting service that runs your app for you, such as Heroku.
- Redis: A separate in memory data store often used for caching and background jobs.
- Sidekiq: A popular background job library that traditionally relies on Redis.
- SQLite: A lightweight database that stores everything in a single file.
- Staging environment: A private copy of your live site used to test changes before real users see them.
- Deprecation warning: A notice that a feature still works today but is scheduled to be removed in a future version.
Frequently Asked Questions
Should I upgrade to Ruby 4.0 right now?
Move to a supported Ruby (version 3.4 is the sweet spot today) and Rails 8.1 now for safety and stability. Keep Ruby 4.0 as a separate, later project, because its headline features are still experimental and the Ruby team recommends waiting before using them in production [4].
Can I upgrade Ruby and Rails at the same time?
You can, but you should not. Doing them one at a time means that if something breaks, you know exactly which change caused it. Upgrade Ruby to a supported version first, get stable and deploy, then upgrade Rails one version at a time.
How often should I upgrade a Rails app?
Try to stay within the supported window, roughly the two most recent versions. In practice, plan for a small upgrade every 6 to 12 months. Regular small steps are easy. Letting it slide for years turns the next one into a major project.
What happens if I stay on an unsupported Ruby on Rails bersion?
The app keeps running, but nobody is patching security holes anymore. Every new vulnerability becomes your team’s job to find and fix by hand, and over time the wider ecosystem stops supporting you, which makes the eventual upgrade harder the longer you wait.
Is it worth upgrading if my Ruby on Rails app already works fine?
Yes. “Works fine” describes today, not tomorrow. The risk is the security announcement you did not see coming, the tool you suddenly cannot install, or the huge forced migration you are quietly setting up for future you. Staying current is cheap insurance against expensive surprises.
