5.1 released 27 April 2017, latest 5.1.7.
Ruby on Rails 5.1 reached end of life on 25 August 2019.
What changed
Rails 5.1 continued the Rails 5 modernization work. It made JavaScript tooling a first-class part of new applications through Yarn and Webpacker, while retaining the asset pipeline for existing applications. It added built-in support for writing system tests with Capybara, introduced encrypted secrets management, and changed development defaults so controller caching is disabled. It also adjusted several long-standing APIs and defaults, including moving jquery-rails out of the default generated application and deprecating rails-ujs adapters for jQuery in favor of the framework’s unobtrusive JavaScript support. Applications upgrading from Rails 5.0 need to review generated JavaScript setup, test dependencies, secrets handling, and deprecation warnings rather than treating the upgrade as only a Gemfile change.
What staying costs
Rails 5.1 has reached end of life, so it no longer receives upstream fixes for newly discovered security issues, compatibility problems, or defects. Its dependency set is old relative to current Ruby, browser, database, JavaScript, and operating-system ecosystems; maintaining it commonly requires pinning transitive gems, build tools, or runtime versions. Webpacker-based applications can be especially exposed to outdated Node, Yarn, and JavaScript package dependencies. The longer an application remains on 5.1, the more likely routine dependency upgrades, platform changes, and compliance requirements will require local patches or a larger, less incremental Rails upgrade.
What to do
First inventory the application’s Ruby version, Rails-related gems, JavaScript toolchain, database adapters, test stack, deployment image, and all Rails deprecation output. Upgrade to the latest available 5.1 patch level as a short-term stabilization step, then remove or replace unmaintained dependencies and add regression coverage around authentication, authorization, background jobs, mail, uploads, and browser-facing flows. Plan a staged upgrade through each intervening Rails line rather than skipping compatibility work: resolve deprecations and behavior changes at each step, keep the test suite green, and validate the application in a production-like environment. Review the current Rails JavaScript approach early, particularly if the application uses Webpacker, jquery-rails, or custom asset-pipeline integration, because front-end tooling choices can determine the upgrade path.
We can tell you what moving off Ruby on Rails 5.1 involves.
What it takes to move off Ruby on Rails 5.1 depends on what you built on it — the version you are on, how much depends on it, and how much of the work is mechanical. Leave your email with this version and we can tell you what that looks like for you.
Not sure yet? Get my plan
