Why CTOs Still Choose Ruby on Rails in 2025

Every few years someone declares Ruby on Rails dead. If you own a Rails product, the version you hear most is from a developer or agency telling you it needs a rewrite. This post gives you the checks that can be verified, so you can judge that advice yourself. I left out popularity statistics, salary figures and speed-comparison numbers: I could not trace any of them to a source worth citing.

What Rails 8 ships #

Rails 8.0 came out in November 2024. The official release notes list six highlights: Kamal 2, Thruster, Solid Cable, Solid Cache, Propshaft as the default asset pipeline, and an authentication generator. In plain terms, from the notes:

• Deploying. Rails comes preconfigured with Kamal 2, which “takes a fresh Linux box and turns it into an application or accessory server with just a single ‘kamal setup’ command.” Thruster is a proxy in front of the web server that handles asset caching and compression.
• Fewer services to run. Solid Queue “replaces the need for Redis, also a separate job-running framework, like Resque, Delayed Job, or Sidekiq.” Solid Cable replaces Redis for relaying WebSocket messages, and Solid Cache replaces Redis or Memcached for fragment caches. Per the release notes, Solid Queue works with PostgreSQL, MySQL 8.0+ and SQLite. Fewer moving parts means fewer things for someone to be on call for.
• Login. An authentication generator creates a starting point for sign-in, password reset and session tracking.

Rails 8.1 followed. Its release notes highlight Active Job Continuations (long background jobs resume from the last finished step after a restart), a local CI command, and structured event reporting.

These are changes to what you have to build or run yourself. They say nothing about how fast any particular app is, and I am not claiming a speed gain.

Check one thing first: is your version still supported? #

For a Rails product, the most useful question is not “is Rails alive?” but “is our version still getting security fixes?” The Rails maintenance policy is specific. Minor releases get bug fixes for one year and security fixes for two years after the first release in the series. As of 30 October 2026, the page lists:

For anything older, the policy says “it’s your own responsibility to deal with bugs and security issues.” Ask your developers which Rails version production runs and where it sits on this table. An app several versions behind is the real risk, and it is fixed by upgrading, which is a smaller job than a rewrite. Each upgrade is easier if it is done one version at a time and the app has decent tests.

What Shopify says about a very large Rails app #

Shopify has written about its main application in detail. In a September 2020 engineering post, its author says the core monolith had “over 2.8 million lines of Ruby code and 500,000 commits”, and describe it as “one of the oldest, largest Rails codebases on the planet, under continuous development since at least 2006, with hundreds of developers currently adding features”. Those figures are from 2020.

Two things in that post are more useful to a founder than the size.

First, Shopify’s answer to a big, tangled Rails app was not a full rewrite. It was to make the monolith modular: split the code into components with owners and enforced boundaries. The author is candid that this is slow and mostly about people: “making a fundamental architecture change to a system that’s being actively worked on is in large part a people problem.”

Second, they did split some things out, for stated reasons. They write that they are “very deliberate about when to split functionality out into separate services, and we only do it for good reasons. That’s because splitting a single monolithic application into a distributed system of services increases the overall complexity considerably.” Their examples: storefront rendering, because it is “a read-only use case with very high throughput”, and credit card vaulting, “because it processes sensitive data that shouldn’t flow through other parts of the system.”

That is a model for your own decision. Split out a part when it has a specific reason, such as very different load or sensitive data. Do not split the whole thing because a pattern is fashionable.

Questions to ask before you agree to a rewrite #

These come from the evidence above, not from a statistic.

1. Which Rails and Ruby versions does production run, and are they supported? If not, the first job is an upgrade.
2. What exactly is wrong? “Slow” needs a measured number for a named page. “Hard to change” needs an example of a change that took too long and why.
3. Could the problem be fixed inside the app? Shopify’s route was modularizing. An agency proposing a rewrite should say why that cannot work for you.
4. Is there a specific part with a different need (high read load, sensitive data, heavy computation)? Then a separate service for that part may be justified, and only that part.
5. Who owns the code after the rewrite? If the answer depends on the same people who wrote the first version, the risk has not moved.

Where JetThoughts fits #

One public result of ours, from our Crosslake case study: on a legacy Rails and React product, the average request time went from 5 s to 0.5 s.

We work as an embedded team of senior, self-managed full-stack developers who drive the development while you run the rest of the business. If you want a second opinion on whether your Rails app needs work and what kind, see how we work.

Sources #

• Ruby on Rails 8.0 release notes - Kamal 2, Thruster, Solid Cable, Solid Cache, Solid Queue, Propshaft, authentication generator
• Ruby on Rails 8.1 release notes - Active Job Continuations, local CI, structured event reporting
• Rails maintenance policy - support periods, as read on 2026-10-30
• Shopify Engineering, Under Deconstruction: The State of Shopify’s Monolith (September 2020) - size of the monolith, modularization, reasons for extracting services

Related: Rails 8 Solid Queue migration guide and Kamal 2: first deploy.