Rails Has Been Dying Since 2010. I'm Still Building Production On It in 2026.

Introduction

The first time I read that Ruby on Rails was dying, Obama was in his first term.

I’ve kept a loose mental log of the obituary headlines since then. “Rails Doesn’t Scale.” “Rails Is Yesterday’s Framework.” “Why I Left Rails for Node.” “Rails Is Boring.” “Rails Is Dead, Long Live JavaScript.” There is a new version of this article roughly every eighteen months, written by someone who has just discovered a new framework and confused their excitement for an industry trend.

It is now 2026. I am still building production systems on Rails. I am not building them on Rails because I am stubborn, or sentimental, or unaware of what else exists. I am building them on Rails because nothing has actually replaced the thing Rails decided to do — and most of the frameworks declared as its successor are quietly rebuilding the same conveniences with worse defaults.

This article is for developers who keep seeing Rails declared dead, suspect the headline is wrong, and want a clear case for or against without the rah-rah and without the hate. If you have never shipped a production application yet, this is not your starting point — go build something end-to-end first, on any stack, and come back when you have opinions earned from outages.

I am going to tell you why the obituary keeps being written, why it keeps being wrong, and why I still reach for Rails when a real project lands on my desk. I will also tell you where Rails is genuinely the wrong call, because anyone who pretends a framework wins every fight is selling something.

Here’s who this is for: Developers who have shipped products, gotten paged at 2am, and earned the right to be skeptical of hype. Tech leads who keep getting asked “is Rails still a real option?” and want a better answer than vibes.

Not for: People shopping for a stack that will look good on a slide. This assumes you care more about systems that work in production than the framework du jour.

The question is not “is Rails still relevant?” The question is “why does the industry keep needing to declare it dead?”

The Core Judgment: Rails Refuses to Die Because the Problems It Solves Don’t

Here is my default position after twenty years of building production software in Rails, Node, Go, PHP, and whatever the client happened to be running: Rails is still the fastest path from idea to a maintainable production system for the overwhelming majority of business applications.

Not the trendiest. Not the most fashionable. Not the framework that will get the most Twitter engagement. The fastest path to a system that ships, scales reasonably, and still makes sense in three years.

The reason is not magic. It is that Rails made a set of decisions in 2004, kept making them deliberately, and the alternatives keep arriving with those same decisions un-made.

You want authentication. You want background jobs. You want database migrations. You want file uploads. You want email. You want session management. You want CSRF protection. You want sensible defaults for every cross-cutting concern in a web application. Rails decided what to do about all of those things, and then committed to those decisions for two decades. Every framework that arrives to replace Rails immediately discovers that none of those problems went away, and quietly starts solving them again — usually less coherently, usually with three competing libraries per problem, and usually billed as “flexibility.”

The Rails-is-dead crowd reads “fewer decisions” as “less power.” That is exactly backward. Fewer decisions is the value. The decision is the cost. Every time you choose your ORM, your auth library, your job runner, your mailer, your file store, you are not building a product. You are running a procurement department.

Rails refuses to die because it refuses to forget what it learned. The frameworks that keep getting declared its successor refuse to remember.

Why the Obituary Keeps Getting Written

The “Rails is dying” narrative has structural reasons that have nothing to do with Rails. Three of them in particular.

1. JavaScript Has Gravity, and the Industry Confuses Gravity for Direction

JavaScript runs in browsers. Everyone working on the web is touching it at some level. So when a new framework appears in the JavaScript ecosystem, it gets a disproportionate amount of attention regardless of whether it actually improves anything. The flood of new framework releases reads, externally, like Rails is being left behind. It is not. It is sitting still and shipping while everyone around it churns.

2. The Hype Cycle Has Marketing Money Behind It

Modern JavaScript frameworks are often backed by venture-funded companies with full-time developer relations teams. Rails is backed by a foundation, a community, and a handful of companies who use it. There is no incentive structure pushing “Rails is great in 2026” into your feed. There is enormous incentive pushing “our new framework is the future.”

3. Boring Doesn’t Generate Posts

A framework that has not had a paradigm-shifting controversy in five years does not produce content. A framework releasing major versions with breaking changes every twelve months produces an endless stream of tutorials, hot takes, migration guides, and “is X dead?” articles. Rails has gotten less dramatic over time. Drama is what fuels the perception of relevance, but drama is also the thing you absolutely do not want in a production framework.

The obituary keeps getting written because the writers need something to write about, not because Rails is actually fading.

Why I Still Reach for Rails

Removing the cultural noise, here is what I actually evaluate when I start a new project.

The Decisions Are Already Made, and They Are Mostly Right

I have built authentication systems from scratch on three different stacks. They were all worse than Devise. I have wired up background job runners by hand. They were all worse than Sidekiq or Solid Queue. I have built file upload pipelines into S3 with progress states and retry logic. They were all worse than Active Storage.

Every one of those rebuilds cost me weeks of work and produced a worse outcome than the gem I refused to use. The third or fourth time I lived that lesson, I stopped trying to be clever. Rails decided what authentication should look like, and instead of fighting it, I let the decision compound across a career.

Hotwire Quietly Won the Interactivity Argument

The case against Rails for years was “modern apps need rich client-side interactivity, and Rails is server-rendered, therefore Rails is for old apps.” Hotwire blew that argument apart without anyone fully noticing.

Turbo gives me SPA-feeling navigation without a SPA. Stimulus gives me targeted JavaScript without a build pipeline. Turbo Frames let me update parts of the page without writing a single line of API serialization. I have shipped features in an afternoon on Hotwire that would have taken a sprint on React. The interactivity-tax-versus-server-rendering tradeoff has collapsed, and the people who built their identity around being on the “modern” side of it haven’t updated their priors.

Rails 8 Folded Half the Infra Stack Into the Framework

Solid Queue. Solid Cache. Solid Cable. Kamal for deployment. The Rails 8 release absorbed pieces of infrastructure that, on other stacks, are still entire side projects to set up. I no longer need Redis to run background jobs. I no longer need a separate cache layer to start. I no longer need a complicated deployment pipeline. A single rails new plus a kamal deploy puts a real production system on a real server. That is not a small change. That is a framework absorbing operational complexity that its competitors still farm out.

Twenty Years of Compounding

This is the one I do not see talked about enough. A framework that has stayed cohesive for twenty years is paying you dividends every project. Rails I built in 2010 still teaches me things about Rails I am writing in 2026. The conventions are the same. The mental model is the same. The upgrade paths are real.

Compare to the JavaScript side, where the patterns I learned in 2018 are useless to me by 2022. That is not “moving fast.” That is throwing away the senior developer’s main advantage — accumulated judgment — every three to four years. Rails honors the time I have already put in. Most of its successors silently demand I start over.

A Real Example: Bookend

Earlier this year, over the course of about two months, I built Bookend — a production management platform for film and live theatre. Cast, crew, rehearsal scheduling, a marketplace for props and equipment, a community feed for the industry, multi-tenant organization structure for theatre companies and production crews. “First call to final wrap,” in the tagline. It is in pilot now.

Look at that feature surface for a moment. Multi-tenant organizations. User accounts with permissions and social sign-in. Calendar and RSVP flows. File uploads with image variants for assets and marketplace listings. A community feed. Transactional email. Marketplace payments. Cross-organization messaging.

The Gemfile for the whole thing is roughly twenty lines of meaningful application gems on top of stock Rails 8. Hotwire — Turbo and Stimulus — handles all of the interactivity. Solid Queue runs the background jobs against Postgres. Solid Cache and Solid Cable handle caching and websockets the same way. No Redis. No separate job infrastructure to babysit. Active Storage with image_processing handles uploads and variants. Authentication is the authentication-zero generator plus OmniAuth for Google and Facebook sign-in. Stripe handles payments. Kamal deploys the whole thing as a Docker container.

That is the entire operational footprint. None of it is interesting work. None of it took meaningful time to set up. Rails 8 absorbed the layer that, three years ago, would have been a Redis cluster, a separate job runner, a session store decision, and a deployment pipeline assembled from a handful of parts.

The interesting problem on Bookend was the domain itself — how a film production actually moves from pre-production to wrap, how rehearsal scheduling differs between a touring theatre company and a single-venue producer, how the marketplace should treat time-limited rentals versus outright sales. That is where I wanted my hours to go, and that is where they went. The framework did not claim them back to solve auth for the fifth time in my career.

The fact that I got Bookend to pilot in about two months, as a single developer working on a domain this broad, is the entire argument of this article in one project.

Common Mistakes I Keep Seeing

Treating Rails like it’s 2012. Modern Rails has Hotwire, Solid Queue, Solid Cache, Action Cable, Active Storage, and Kamal. If your last serious Rails experience predates Hotwire, your mental model of what Rails feels like is wrong. Update it before forming an opinion.

Splitting into microservices before you have product-market fit. This is the most consistent killer of Rails projects, and it is almost always self-inflicted. The framework wants to be a monolith. Let it be a monolith until the monolith demonstrably fails. Most monoliths never fail.

Rolling auth and authorization yourself from scratch. I understand the appeal. I have done it. It is a waste of your career. Use a proven auth library or generator — there are several good ones. Spend the time you save on the part of the application no one else has built.

Treating the boring parts as boring. Rails ships boring infrastructure. The boring infrastructure is the point. It frees you to spend your interesting hours on the thing that is actually interesting, which is your domain.

Comparing Rails to the JS ecosystem as a whole rather than to a specific framework. “Rails versus JavaScript” is not a real comparison. “Rails versus Next plus Prisma plus NextAuth plus Resend plus UploadThing plus a queue you have not picked yet” is the real comparison. Rails is one box. The other side is a shopping list.

Where Rails Is Genuinely Not the Answer

I am not arguing that Rails wins every fight. It does not.

Don’t use Rails when:

• You are building a real-time collaborative document editor. Phoenix or a Node-based stack with established CRDT support will get you there faster.
• The application is overwhelmingly client-side, with the server mostly storing JSON. Rails works fine for this but you are not getting most of its value.
• You need to deploy at the edge with extremely low cold-start latency. Rails is not optimized for serverless edge functions.
• Your entire team is JavaScript-first and reluctant to learn Ruby. The cost of switching languages will dwarf the productivity Rails offers.
• You are building a CLI tool, a numerical workload, an ML training pipeline, or anything else that is fundamentally not a web application. Rails is a web framework. Use it for web applications.

Real limitations of Rails I am honest about:

• Ruby is slower than Go for CPU-bound work. Most web apps are I/O bound, so this rarely matters, but if you are doing image processing in-process or running a compute-heavy endpoint, you will notice.
• Real-time at scale is hard. Action Cable works, but if your entire product is real-time multi-user collaboration, frameworks built for that from day one will treat you better.
• The frontend ecosystem assumes JavaScript-first patterns. If you need a specific React or Vue ecosystem library, integrating it through importmaps is fine, but you are no longer working entirely in Rails’s grain.

If your project lives in those zones, do not choose Rails to make a point. The point is to ship.

Best Practices I Actually Follow

Start with the monolith. Always. Split into services only after the monolith has actually broken in a way that splitting fixes.

Embrace conventions aggressively. The productivity comes from not making decisions. Fighting Rails is the surest way to lose every benefit it gives you.

Default to Hotwire for interactivity. Reach for a JavaScript framework only when you have a specific reason that Hotwire genuinely cannot meet. Most “we need React” instincts dissolve when someone actually tries Turbo Frames.

Use the boring gems. Rails 8’s Solid Queue, Solid Cache, and Solid Cable. Active Storage. A well-supported auth library. The gems that have survived their hype cycles. Their boringness is their value.

Upgrade Rails regularly. A two-version-behind Rails app is a chore. A current Rails app is a privilege. Stay close to head.

Measure shipped features, not framework sophistication. The point is the system in production. The framework is not the product. Every hour spent on framework choice that does not produce a shipped feature is an hour wasted.

Conclusion: The Boring Bet

The framework that is still around in twenty years is, almost by definition, a framework that survives the hype cycles. Rails has now done that twice. It is going to do it again.

Choosing Rails in 2026 is the boring bet. It is the bet that the next “Rails killer” will look, in 2030, the way the 2012 Rails killers look now — quaint, dated, full of accidental complexity its successors quietly fixed. It is the bet that solving the same problems for twenty years compounds in the framework, the same way it compounds in the developer.

The obituary will get written again. Probably next year. It will get a lot of likes. I will keep building production systems on Rails, the same way I have been doing it since 2006. The clients will keep getting shipped products. The systems will keep being boring to operate.

That is the entire game.

Frequently Asked Questions (FAQs)

Is Rails still hiring?

Yes — and aggressively at the senior level. Shopify, GitHub, Stripe-adjacent companies, Basecamp, and thousands of profitable mid-size businesses pay well for Rails depth. The shortage is at the senior end, where compensation reflects it. Fewer entry-level Rails roles is not “Rails is dying,” it is “Rails is no longer the obvious bootcamp output.”

What about TypeScript? Doesn’t Ruby need types?

RBS and Sorbet exist and are usable, but I have not found type systems to be the bug-prevention tool most JavaScript developers assume they are. Comprehensive tests catch more bugs than types do, and Rails makes tests easy. If you need types badly enough that their absence is a dealbreaker, Rails is not your tool — but I would push back on the premise.

Can Rails handle scale?

Rails powers Shopify (billions in annual transactions), GitHub (millions of repos), and Basecamp (decades of operation). If your scale concerns are bigger than theirs, you are not picking a framework anymore — you are designing custom infrastructure, and the framework underneath barely matters.

Should I learn Rails in 2026?

If you are building products: yes. If you are interview-grinding at FAANG: probably no, learn whatever the interview asks for. Rails is a product-shipping tool. Optimize accordingly.

Why doesn’t anyone on Twitter talk about Rails anymore?

Because Rails works. Working software does not produce content. That is the entire explanation.

What about Phoenix, or Laravel, or Django?

All three are excellent. Phoenix is genuinely better than Rails for real-time-first applications. Laravel is essentially Rails in PHP and is also a fine choice. Django is a fine choice for Python shops. The framework matters less than your willingness to lean into its conventions. Pick the one that fits your language preference and your team’s existing depth, then commit.

Your turn: How many years has your stack been around, and how many of the conveniences you depend on were assembled by hand versus shipped with the framework? Add up the assembly time honestly. That number is what Rails saves you.