7.0 released 15 December 2021, latest 7.0.10.
Ruby on Rails 7.0 reached end of life on 1 April 2025.
What changed
Rails 7.0 made the Hotwire approach the default for newly generated applications: Turbo handles navigation and page updates, while Stimulus provides lightweight JavaScript controllers. It introduced import maps as a first-class JavaScript option, allowing many applications to load browser-ready JavaScript modules without a Node-based bundling step; jsbundling-rails and cssbundling-rails remained options for applications that need bundlers. Active Record gained application-level encryption for model attributes, including deterministic and non-deterministic encryption modes, and asynchronous query loading for selected query patterns. The cycle also continued the framework’s move toward Zeitwerk-based autoloading and removed or deprecated older compatibility paths, so applications with custom autoloading, legacy asset handling, or older JavaScript integrations can encounter upgrade work.
What staying costs
Rails 7.0 has reached end of life. It no longer receives upstream security fixes, bug fixes, or compatibility maintenance, leaving the application responsible for mitigating framework-level issues and for carrying local patches where necessary. The practical risk increases as supported Ruby versions, database adapters, Rack, web servers, browser tooling, and deployment platforms move forward. Dependency resolution may become constrained by Rails 7.0’s older requirements, while deferring the upgrade can accumulate deprecated APIs, custom workarounds, and test gaps that make a later migration more expensive. Applications using import maps, Turbo, Stimulus, asset pipelines, or encrypted attributes should also expect integration-specific regression risk during a move because those components interact with application JavaScript, build tooling, keys, and deployment configuration.
What to do
Choose a currently supported Rails target and review its Ruby, Rack, database adapter, and Node or browser-tooling requirements before changing the application. Bring the Rails 7.0 application to its latest patch level first, run the full test suite, and remove deprecation warnings and unsupported overrides. Follow the Rails upgrade guides through the intervening release lines rather than changing framework, Ruby, and major infrastructure dependencies without isolated validation. Audit custom initializers, autoload paths, Active Record callbacks and query behavior, asset configuration, Hotwire integrations, and third-party gems for version compatibility. If the application uses Active Record encryption, verify key provisioning, deterministic-query behavior, backups, and rotation procedures in a non-production environment. Deploy the upgrade through staging with production-like data and traffic checks, then use a reversible rollout plan with database migration, background-job, cache, and asset rollback considerations documented.
Release history
We can tell you what moving off Ruby on Rails 7.0 involves.
What it takes to move off Ruby on Rails 7.0 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
