You’ve probably heard one of these: “Rails is dying.” “Nobody hires Rails developers anymore.” “Rails lost to Node and Django a decade ago.” If you’re a CTO or founder picking a stack, those claims matter, because betting on a dead framework is expensive.
This article answers the question with numbers you can go check yourself: GitHub activity on the rails/rails repo, RubyGems download counts, developer survey data, job board volume, and named companies running Rails in production today. Where a figure can’t be verified from a public source, that’s stated plainly instead of filled in with a guess.
Short answer: Rails is not dying, but it is no longer the default choice for every new web app, and those are two very different things. The honest version of the story is that Rails has settled into a specific niche (database-backed web apps built by small teams) and it is very good at that niche.
A note on versions: this article is written against Rails 8.1.3.1, released July 29, 2026, the current patch release as verified on rubyonrails.org at the time of writing.
Table of contents:
- What Relevance Means for a Mature Web Framework
- The Current State of Ruby on Rails in 2026
- Who Still Uses Rails in Production
- Why Teams Continue to Choose Rails
- Claim Versus Reality: Is Rails Dying?
- How to Decide Whether Rails Is Right for Your Team
- Frequently Asked Questions
What Relevance Means for a Mature Web Framework
“Relevant” gets used loosely. For a 20-year-old framework, it needs a definition you can measure.
A framework is relevant if it is actively maintained, downloaded, hired for, and used to run revenue-generating products. Rails clears all four bars. What it does not clear is “most talked about on tech Twitter,” which is the bar most “Rails is dead” posts are actually measuring.
Measuring Adoption Beyond Hype Cycles
There are four separate popularity signals, and blurring them together is how bad takes get made:
- Package downloads: how many machines actually install the thing.
- GitHub activity: whether maintainers are still shipping code.
- Survey-reported usage: what percentage of surveyed developers say they use it.
- Job postings: whether companies are paying people to write it.
A framework can be low on survey mindshare and still high on downloads and jobs. That is roughly where Rails sits: New-framework hype tends to spike survey numbers, and conference talks long before it shows up in production headcount.
The Difference Between Ruby Popularity and Rails Usage
Ruby and Rails are not the same data point, and people mix them up constantly. If you’re deciding between learning the language versus the framework, our Ruby vs. Ruby on Rails breakdown covers that distinction in more depth.
Ruby (the language) shows up in language rankings like TIOBE and the Stack Overflow Developer Survey. Rails (the framework) shows up in the “web frameworks and technologies” section of that same survey. A drop in Ruby’s language ranking does not automatically mean Rails apps are being retired.
In practice, most Ruby written commercially is written inside a Rails app. So Ruby’s numbers are a rough proxy for Rails, but only a proxy. When you check figures, note which one you’re looking at.
The Current State of Ruby on Rails in 2026
Maintenance status is the easiest claim to check, and the one skeptics get wrong most often.
Current Stable Release and Maintenance Status
Rails 8.0 shipped in November 2024, and the 8.x line has continued with regular releases since, most recently Rails 8.1.3.1 in July 2026. That release changed the defaults in ways worth knowing about, because a lot of “Rails is old-fashioned” criticism describes Rails 5, not Rails 8.
The Rails 8 defaults that changed the operational picture:
- Solid Queue as the built-in background job backend, running on your database instead of requiring Redis.
- Solid Cache as a database-backed cache store.
- Solid Cable as an Action Cable adapter that also runs on the database.
- Kamal for deploying containers to your own servers.
- Propshaft as the asset pipeline, replacing Sprockets in new apps.
- A built-in authentication generator, so you don’t reach for a gem on day one.
Rails 8.1 (October 22, 2025) added four features with immediate operational consequences:
- Active Job continuations: Long-running jobs can declare discrete steps and resume from the last completed step after a server restart. For teams deploying with Kamal (which gives containers 30 seconds to shut down during a deploy), this changes the math on long batch jobs — they resume rather than restart from zero.
- Structured event reporting: Rails.event.notify emits structured events with tags and context to subscribers you register — a better fit for log pipelines and observability tooling than parsing the human-oriented Rails logger.
- Local CI: A CI declaration DSL in config/ci.rb, run with bin/ci, turns developer machines into first-class test runners for small and mid-sized apps before pushing to a remote CI service.
- Markdown rendering: ActionText can now render Markdown directly, without converting to HTML intermediates — useful for content-heavy apps storing user-authored Markdown.
The article’s note on versions is written against 8.1.3.1, the current patch release as of July 29, 2026. Verify the current version and release notes at guides.rubyonrails.org/8_1_release_notes.html before building on these defaults.
Defaults move, so check the exact current version and confirm each of these in the official release notes before you build on them.
The practical effect: a new Rails app can go to production with a database and a web server, no Redis, no separate job service. For a three-person team, that removes real infrastructure work. Our guide on Rails and Agile delivery walks through what that speed looks like across a full sprint cycle.
Release Activity, Contributors, and Ecosystem Signals
The rails/rails repository on GitHub is one of the most-starred in the Ruby ecosystem, with tens of thousands of stars and thousands of contributors since 2004. Exact star and contributor counts change daily, so pull the live numbers from the repo sidebar rather than trusting a figure in any article, including this one.
What matters more than stars: commit and release cadence. Rails ships security patches and point releases on an ongoing schedule, and the maintainer team publishes advisories for supported versions under a documented maintenance policy. You can verify this yourself in the commits tab and the releases page.
Another structural signal: The Rails Foundation launched in 2022 with Core members Cookpad, Doximity, Fleetio, GitHub, Intercom (now Fin), Procore, Shopify, and 37signals, and Contributing members including 1Password, Judge.me, Honeybadger, and others; count the live list at rubyonrails.org/foundation rather than trusting any published count, as membership changes.
Companies pay meaningful annual fees to participate; organizations do not fund a foundation for a framework they plan to leave. Note that Fin appears on both this Foundation list and the production-users list above. the same company that runs Rails is also paying to develop it.
Download and Package Usage Data to Verify
Package downloads are the cleanest usage signal available, because they reflect machines, not opinions.
The rails gem page on rubygems.org displays both total downloads and downloads for the current version. As of the day this was checked, the total sits above 787 million cumulative downloads, with approximately 7.1 million downloads recorded for the current 8.1.3.1 release alone (figures checked September 14, 2026 — check rubygems.org/gems/rails directly for the live count on the day you read this).
If you want a more current signal than a lifetime total, use recent download volume for the latest stable version. RubyGems shows per-version counts, and a healthy version-level number tells you people are installing today’s Rails, not just maintaining old apps.
One caveat: download counts include CI runs, Docker builds, and mirrors, so they overstate the number of distinct humans. That’s true for every package registry, npm included, so it doesn’t distort cross-framework comparisons much.
Who Still Uses Rails in Production
Vague claims about “many major companies” prove nothing. Here are named ones.
Established Companies Running Rails at Scale
- Shopify: runs one of the largest Rails monoliths in existence, handling Black Friday/Cyber Monday traffic peaks, and employs engineers who contribute directly to Rails core. Shopify’s engineering team has published that their monolith handles billions of requests during peak shopping periods. On Black Friday 2024 alone, the Rails monolith peaked at 284 million requests per minute on app servers and processed 10.5 trillion database queries over BFCM weekend.
- GitHub: the main GitHub application has been Rails since 2008 and still is. GitHub engineers have written publicly about upgrading Rails across major versions, describing a monolith of nearly two million lines of code with over 1,000 engineers collaborating on it daily and deploying as often as 20 times a day.
- Basecamp and HEY (37signals): Rails’ origin company; both products run Rails, and 37signals builds the Solid gems and Kamal that ship as Rails defaults.
- 1Password: a Rails Foundation Contributing member running a password manager with millions of users. You can verify their membership directly on the Rails Foundation page.
- Instacart: ran Rails as its core application through its growth into a public company.
- Zendesk: built its support platform on Rails and still runs Ruby services.
- Fin (rebranded from Intercom, May 12, 2026): has run Rails since founding, written publicly about maintaining a large Rails codebase, and is a Rails Foundation member.
- Doximity: a Rails Foundation Core member running a physician network on Rails. Their original 2010 Rails monolith now powers Doximity.com for over 80% of all US doctors, 90% of graduating medical students, and 60% of nurse practitioners; after over 30,000 commits from hundreds of contributors, with 150+ developers deploying to production 80+ times a day.
- Cookpad: a Rails Foundation member and long-time Rails contributor serving a global recipe platform.
- Lago: an open-source billing platform, founded recently, that processes high API event volume on Rails alongside Go and Rust services.
Two things stand out in that list. First, these are not legacy leftovers; several of these companies fund Rails development. Second, Lago shows new companies still pick Rails, which undercuts the “only old apps use it” claim.
Where Rails Fits Best in New Products
Rails is strongest when your product is mostly forms, records, permissions, background jobs, and reports. That describes a huge share of B2B software.
It is weakest when your core problem is raw compute throughput, real-time streaming at massive concurrency, or a mobile-first app where the backend is a thin API and the interesting work is native. If your product leans toward a heavy interactive frontend, our comparison of Rails and React working together covers how teams split that work in practice.
Common Use Cases Across SaaS, Marketplaces, and Internal Tools
- B2B SaaS: multi-tenant apps with billing, roles, and admin panels. Rails has mature gems for all three.
- Marketplaces: two-sided platforms with listings, search, messaging, and payments, the pattern Airbnb and Instacart both started with.
- Internal tools and admin systems: where speed of building beats novelty, and a small team maintains a lot of surface area.
- Content and community platforms: database-heavy, server-rendered, and well-served by Hotwire instead of a separate frontend app.
Why Teams Continue to Choose Rails
The reasons teams give in 2026 are different from the reasons they gave in 2010. It’s less about “look how fast I can scaffold a blog” and more about total cost of ownership.
Monolith-First Development and Time to First Deploy
Rails ships one application you can deploy to one server. With Kamal in the box, kamal setup puts a containerized app on hardware you control, and the Solid gems mean you don’t stand up Redis or a separate job worker first.
Compare that to a typical Node or Next.js setup where you assemble an ORM, a validation library, an auth provider, a job queue, and a deployment target before writing feature code. Rails makes those decisions for you. You can override them later.
For a small team, that difference shows up as weeks, not hours. Arc’s own guidance puts production-ready Rails MVPs in the two- to six-week range for straightforward SaaS and marketplace builds with a small team.
Convention Over Configuration and Maintenance Burden
Convention over configuration is often described as a beginner convenience. Its real value is maintenance.
Any experienced Rails developer can open a Rails app they’ve never seen and find the models, controllers, jobs, and tests in seconds. That predictability matters most when someone leaves, or when you hire a contractor for three months.
It also happens to help AI coding assistants. Because file locations and naming follow strict conventions, tools like Cursor, Copilot, and Claude produce noticeably more usable Rails code than they do in a bespoke architecture. A concrete workflow: point an assistant at a legacy Rails controller, ask it to extract logic into a service object and write the RSpec spec, then run the existing test suite as your check. The conventions give the model enough structure to be reliable, and the tests give you the safety net.
Ecosystem Maturity, Security, and Long-Term Support
RubyGems hosts a deep library ecosystem for exactly the boring problems SaaS companies have: Devise for auth, Pundit for authorization, Sidekiq or Solid Queue for jobs, Stripe integrations, ActiveAdmin for back offices.
Current maintenance status, from rubyonrails.org/maintenance (verify on the day you read this, as dates shift with each new release):
| Version | Bug fixes until | Security fixes until |
| Rails 8.1 (current) | April 2027 | April 2028 |
| Rails 8.0 | Security fixes only as of May 2026 | November 2026 |
| Rails 7.2 | EOL | EOL |
| Rails 7.1 | EOL | EOL |
Rails 7.2 and 7.1 are already EOL; teams still running either should treat an upgrade to 8.1 as a security requirement, not a nice-to-have. The jump from 7.x to 8.x is meaningful but well-documented, and the Rails upgrade guide at guides.rubyonrails.org covers the path step by step.
Developer Productivity Versus Framework Churn
Framework churn is a real cost, and it doesn’t show up on a cost estimate.
Rails upgrades are not free, but the mental model has held steady for over a decade. Active Record, controllers, and routes work the way they did in 2015, so your team’s knowledge compounds instead of resetting.
Claim Versus Reality: Is Rails Dying?
The skeptics aren’t making things up. Rails genuinely lost mindshare. Here’s each specific claim against a checkable fact.
| The claim | The checkable reality |
| “No major companies use Rails anymore.” | Shopify, GitHub, Basecamp, Fin (rebranded from Intercom, May 2026), Zendesk, Instacart, Doximity, and Cookpad all run Rails in production. Shopify, GitHub, Cookpad, Doximity, and 37signals are Rails Foundation members. |
| “Development has stopped.” | Rails 8.1.3.1 shipped in July 2026, continuing regular point releases and security patches since Rails 8.0 in November 2024. Verify commit and release dates on the rails/rails GitHub releases page. |
| “The hiring pool has dried up.” | Named job boards including LinkedIn, Indeed, and Ruby-specific boards list Ruby on Rails roles continuously in the US market. Pull a live count for your region and date range rather than trusting any number in an article. |
| “Nobody downloads it anymore.” | The rails gem shows above 787 million cumulative downloads on rubygems.org, with approximately 7.1 million downloads for the current 8.1.3.1 release (checked September 14, 2026). Check rubygems.org/gems/rails for the live count. |
| “Rails can’t scale.” | Shopify handles Black Friday peaks on a Rails monolith, and GitHub serves its main application from Rails. Scaling constraints are real, but they are architectural, not framework-fatal. |
| “It’s stuck in 2010.” | Rails 8 defaults to Solid Queue, Solid Cache, Solid Cable, Kamal, and Propshaft, and ships a built-in auth generator. Confirm current defaults in the official release notes. |
| “Rails lost to Node and Django.” | Rails is no longer the default for new startups; that part is accurate. It remains one of several mainstream choices for server-rendered, database-backed apps. Losing the default slot is not the same as losing viability. |
Why Rails Looks Less Visible Than Newer Frameworks
Three reasons, none of which are “Rails stopped working:”
- Rails does server-rendered HTML, and the last decade of developer attention went to JavaScript frontends
- Rails apps also tend to be private B2B products, not the public consumer apps that generate conference talks
- Rails is stable, so there’s less to blog about; nobody writes hot takes about Active Record’s new syntax because there isn’t any
Where the Hiring Market Remains Strong
For a current job count, here’s a replicable method: go to LinkedIn Jobs, search the exact phrase “Ruby on Rails,” filter to United States, and note the result count and the date. As of September 14, 2026: approximately 2,400 open roles in the United States on LinkedIn with “Ruby on Rails” in the title or description (exact phrase search, date-checked).
That number fluctuates daily, and the split between senior and mid-level roles skews senior; consistent with the observation below that the junior pipeline is thinner. Run the same search in your own market and date-check it; any number from any article, including this one, is already stale.
Rails hiring is smaller than Node or Python hiring in absolute terms. It is also less crowded on the candidate side, which cuts both ways.
The depth is concentrated in senior developers. Fewer bootcamps teach Rails now, so the junior pipeline is thinner than it used to be, while the pool of engineers with eight to fifteen years of production Rails experience is deep. Search a job board for “Ruby on Rails” in your market and check both the posting count and the seniority split before you decide.
The Trade-Offs Teams Should Evaluate Honestly
- Raw request throughput: Ruby is slower per-process than Go or Java, though YJIT (enabled by default in Rails 8 on Ruby 3.3+) narrows that gap meaningfully in production. Shopify has published data describing it as one of the most impactful Ruby performance changes in years. For most CRUD apps, the database is your bottleneck regardless.
- Junior hiring: harder to fill entry-level Rails roles from local bootcamp pipelines than entry-level React roles.
- Heavy interactive frontends: if you need a complex SPA, you’ll pair Rails with a JS frontend, which reduces the monolith advantage.
- Machine learning workloads: the Python ecosystem is where the libraries live. Rails can call those services, but it isn’t the place to write them.
How to Decide Whether Rails Is Right for Your Team
Pick based on your constraints, not on what’s trending. If you want the full case for and against building on Rails today, our take on Ruby on Rails for web development in 2026 covers it from the build-decision side rather than the adoption-data side.
A Practical Decision Matrix for New Builds
| Your situation | Rails fit | Why |
| 1 to 8 engineers, B2B SaaS, need to ship in weeks | Strong | Monolith-first, batteries included, one deploy target |
| Marketplace or internal tool, heavy CRUD and admin | Strong | Mature gems for auth, admin, payments, jobs |
| Existing Rails app and Rails team | Strong | Upgrade beats rewrite in almost every case |
| Real-time collaborative app with complex frontend | Mixed | Rails API plus a JS frontend works, but you lose monolith simplicity |
| Latency-critical, high-concurrency service | Weak | Go, Rust, or Elixir fit better |
| ML or data-science core product | Weak | Python ecosystem, with Rails only as the web layer if at all |
| Team has zero Ruby experience and no time to learn | Weak | Use the stack your team already knows |
When a Rails Modernization Makes More Sense Than a Rewrite
Most “we need to move off Rails” conversations are actually “our Rails app is on version 5, and nobody has upgraded it.”
Upgrading through the version series, replacing dead gems, adding test coverage, and moving to Solid Queue and Kamal usually costs a fraction of a rewrite and carries far less risk. A rewrite means shipping zero customer value for months while your competitors ship.
Run the honest comparison first: the cost of an upgrade path versus the cost of a rewrite plus the feature freeze. If your app has real revenue and real users, the math usually favors modernization.
Hiring and Retaining Experienced Rails Developers
The framework is rarely what sinks a Rails project. A senior engineer who has run Rails in production through two major upgrades will make better architecture calls than any framework choice will make for you.
What to screen for: experience upgrading a real Rails app across major versions, comfort with background job architecture and database performance, and the judgment to say when Rails is the wrong tool. That last one is the tell: An engineer who thinks Rails is right for everything will eventually build you the wrong thing.
If you’ve decided Rails is still the right bet for your team, the framework was never the hard part. Finding engineers who’ve shipped and maintained production Rails apps at scale, and who can tell you honestly when Rails is not the right long-term call, is.
Arc pre-vets Rails developers for technical depth and English fluency before you see a profile. HireAI matches your requirements against a pool of vetted candidates and returns a shortlist in minutes, not weeks.
Hire vetted Ruby on Rails developers with Arc →
Frequently Asked Questions
Is Ruby on Rails dying?
No. Rails is actively maintained, actively downloaded, and actively run in production by companies including Shopify, GitHub, and Basecamp. What has changed is that it’s no longer the default choice for every new web app, as it was in the late 2000s. Losing that default slot to Node and other frameworks is a real shift in mindshare, but it’s not the same as the framework becoming unmaintained or unused.
How popular is Ruby on Rails in 2026?
Popularity depends on which signal you check. Rails ranks lower on developer survey mindshare than newer frameworks, but it remains high on two harder signals: package downloads on rubygems.org and job postings that name Rails specifically. A framework can look quiet on social media while still running production revenue for large companies, which is roughly where Rails sits today.
How many times has Ruby on Rails been downloaded?
The rails gem has been downloaded above 787 million times cumulatively on rubygems.org, with approximately 7.1 million downloads on the current 8.1.3.1 release alone (checked September 14, 2026). That total climbs by the hour, so treat any specific number, including this one, as already out of date, and check rubygems.org/gems/rails directly for the live count.
Why is Ruby on Rails still popular with development teams?
Teams cite total cost of ownership over raw speed. Convention over configuration means a new hire can find the models, controllers, and tests in an unfamiliar Rails app within minutes, and Rails 8’s Solid Queue, Solid Cache, and Solid Cable defaults let a small team run production infrastructure without standing up Redis separately. That combination means faster onboarding and lower infrastructure overhead, not just faster initial scaffolding.
Do any major companies still use Ruby on Rails?
Yes. Shopify runs one of the largest Rails codebases in production, handling Black Friday and Cyber Monday traffic. GitHub’s main application has run on Rails since 2008 and is upgraded on an ongoing basis. Basecamp and HEY, both built by 37signals (Rails’ creator), also run on Rails, and 37signals builds the Solid Queue, Solid Cache, and Kamal tools that now ship as Rails defaults.
Is Ruby on Rails still worth learning in 2026?
It depends on what you’re optimizing for. Rails is a strong choice for small teams building database-backed SaaS products, marketplaces, or internal tools who want to ship in weeks rather than months. It’s a weaker choice if your target roles lean toward high-concurrency services, machine learning infrastructure, or companies that have standardized on a different stack, since the Rails hiring pool is smaller (though less crowded) than for JavaScript-based frameworks.
What is the difference between Ruby and Ruby on Rails?
Ruby is the programming language; Rails is a web framework written in Ruby. Most commercial Ruby code is written inside a Rails application, so Ruby’s popularity rankings act as a rough proxy for Rails, but they’re not the same measurement. A dip in Ruby’s ranking on a language survey doesn’t necessarily mean Rails applications are being retired.
