Ruby on Rails turned 21 in 2025, and far from retiring, it is running the internet’s most critical infrastructure. We’re talking about platforms worth hundreds of billions of dollars, serving millions of users every single day. Yet the debate never dies: “Does Rails actually scale?” The answer is hiding in plain sight. Companies that hire Ruby on Rails developers are building some of the most famous web apps built with Ruby on Rails on the planet, and they keep choosing this framework for good reason. This post digs into those apps and, more importantly, what each one teaches us.
If you’re evaluating Rails for your next project, whether you’re a CTO weighing infrastructure risk or a developer looking at build speed, these real-world examples give you the clearest signal available.
Why Engineers Keep Choosing Ruby on Rails for Production Web Apps
Before the app-by-app breakdown, one stat worth anchoring to: according to the 2025 Stack Overflow Developer Survey, Ruby remains in the top 15 most-used languages globally, with Rails as its dominant web framework. That’s after two decades and multiple waves of “Rails is dead” commentary.
Rails earned that staying power the hard way. Convention over configuration means developers spend less time arguing about folder structure and more time shipping features. The opinionated defaults (ActiveRecord for database abstraction, Action Mailer for email, built-in testing) mean a small team can build what would take a larger team months on other stacks. And as the apps below prove, those same conventions hold at massive scale when the architecture is respected.
GitHub: A 2-Million-Line Rails Codebase That Deploys 20 Times a Day
GitHub.com is one of the most-cited web apps built with Ruby on Rails and it’s a textbook case in what Rails can actually sustain. According to GitHub’s own engineering blog, the application is nearly two million lines of code, with more than 1,000 engineers collaborating on it daily. They deploy as often as 20 times a day.
That’s not a small script. That’s the world’s largest developer platform, still running on a Rails monolith, at extraordinary frequency.
What makes this possible? GitHub runs weekly automated Rails upgrades. A scheduled GitHub Action bumps the Rails version every Monday, runs the full test suite, and ships it Tuesday if green. This discipline means they’re never more than a week behind main. The lesson for developers: the “Rails doesn’t scale” argument collapses when your architecture prioritizes test coverage, deployment automation, and incremental upgrades rather than big-bang migrations.
For engineering leaders, GitHub scaled to 50 million developers and over 100 million repositories on a Rails monolith. The framework didn’t hold them back. Undisciplined code organization would have. Rails gave them a shared language across 1,000+ engineers that let the company double its headcount without rewriting the stack.
Shopify: Web Apps Built with Ruby on Rails Handling 489 Million Requests Per Minute
If one data point closes the Rails scalability debate forever, it’s Shopify on Black Friday 2025. According to Shopify’s official BFCM 2025 announcement, the Rails monolith powered $14.6 billion in merchant sales, a 27% increase from the prior year. Per Style Arcade’s Black Friday 2025 report, the platform peaked at 489 million requests per minute on edge and over 117 million on app servers. All on Rails.
Shopify has run Rails since version 0.5. Today their codebase sits at 2.8 million lines of Ruby code with over 500,000 commits. Rather than fracturing into microservices to chase that scale, Shopify doubled down. They treat the development environment as a product, use Ruby LSP for editor intelligence, run on Edge Rails to catch regressions before release, and have contributed major improvements back to both Ruby (YJIT, ZJIT compilers) and the Rails framework itself.
The developer takeaway: Shopify’s performance isn’t despite Rails. It’s partly because of their investment in making Rails faster. According to Shopify Engineering’s YJIT blog, YJIT delivers 15-25% performance improvements in production Rails applications, with some CPU-intensive workloads seeing gains exceeding 40%. You get those gains for free on Rails 8.0+ just by upgrading.
For product decision-makers: Shopify’s “majestic monolith” approach means 3,100+ engineers ship features without the coordination overhead of microservices. Fewer moving parts at deployment time means fewer failure modes under peak load.
Airbnb, Kickstarter & Basecamp: Ruby on Rails MVP Development Done Right
Three companies that define their categories all used web apps built with Ruby on Rails to go from zero to product-market fit:
- Airbnb launched its original marketplace on Rails. The framework’s built-in scaffolding, authentication patterns, and database migrations let a tiny team ship a two-sided marketplace (hosts and guests, listings and bookings) in weeks, not quarters. By the time Airbnb needed to move some services to other stacks, Rails had already de-risked the entire business model.
- Kickstarter built its entire crowdfunding platform on Rails and has kept it there. Their engineers have written publicly about managing a Rails monolith at scale, including how they handle database migrations on live tables with millions of rows without downtime. It’s a real operational challenge that Rails tooling handles well with gems like strong_migrations.
- Basecamp is Rails’s origin story. David Heinemeier Hansson extracted Rails from building Basecamp in 2004. The project management tool still runs on Rails today. In fact, 37signals’ own dev blog reports Basecamp runs about 18% faster after enabling YJIT, with 98% of their code now executed by the JIT compiler rather than the interpreter. DHH and team use Basecamp as the proving ground for new Rails features, which means real production feedback loops drive the framework’s evolution.
The shared pattern: all three prioritized shipping a working product over premature architectural purity. Rails made that possible by handling the boilerplate (sessions, routing, ORM, migrations) so the teams could focus on what made their products different.
Zendesk & SoundCloud: Ruby on Rails SaaS Applications at Enterprise Scale
Zendesk, the customer service platform used by 100,000+ companies, started on Rails and scaled to enterprise level before making selective architectural decisions. In a talk at Balkan Ruby 2024, Zendesk engineers confirmed their own monolith sits at 2 million lines of code with 2,000 engineers. The key word is selective. Zendesk didn’t abandon Rails. They extracted specific high-throughput components to specialized services while keeping their core product logic in Rails where developer productivity mattered most.
SoundCloud, the audio streaming platform with 175 million registered users, similarly started as one of the web apps built with Ruby on Rails and later introduced microservices for specific audio processing pipelines. But the core product (user accounts, tracks, comments, playlists) remained Rails for years because that’s where iteration speed matters.
The lesson both companies teach: Rails and microservices aren’t opposites. Smart teams use Rails for the 80% of their application where developer velocity matters, and introduce specialized services only where specific technical constraints demand it, not as a default architectural religion.
What These Famous Web Apps Built with Ruby on Rails Actually Have in Common
Strip away the brand names and a clear pattern emerges across every web apps built with Ruby on Rails that made it to scale:
- Strong test culture: GitHub’s weekly Rails upgrades only work because of a thorough test suite. Shopify’s deployment confidence at 53 million DB queries per second comes from the same place.
- Incremental architecture: none of these companies did a big-bang rewrite. They evolved their Rails apps, extracted services surgically, and upgraded the framework continuously rather than falling years behind and paying a painful catch-up cost.
- Community investment: Shopify employs Rails Core team members. GitHub’s production testing of Rails main catches bugs before release. Basecamp is literally where Rails comes from. The companies that scale on Rails tend to give back to the framework, which is why Rails 8.0’s “No PaaS Required” philosophy reflects real-world operator experience built over years.
None of these are accidents. They’re the result of teams that understood the Rails philosophy (convention, productivity, and the pit of success) and built with it rather than against it.
Is Rails the Right Choice for Your Next Web App?
The evidence from GitHub, Shopify, Airbnb, Kickstarter, Basecamp, Zendesk, and SoundCloud points to the same conclusion: Rails is not a framework you outgrow. It’s a framework you can underinvest in. Teams that ship bad Rails code will hit walls. Teams that respect the conventions, invest in testing, and keep their dependencies lean ship faster and scale further than they expected.
If you’re building a new product and want the fastest path from idea to production-ready web app, Rails in 2026 is a stronger choice than ever. Rails 8.0 ships with Solid Queue, Solid Cache, and Solid Cable baked in, eliminating the need for Redis and external job queue services on most deployments. The “No PaaS Required” era means lower infrastructure costs and fewer moving parts from day one.
Whether you’re building a marketplace, a SaaS platform, or an internal tool, working with a proven ruby on rails development company gives you access to engineers who know how to use the framework’s conventions to ship fast and build systems that hold up, just like the platforms above.
