Ruby on Rails FAQ

Ruby on Rails is a mature, actively maintained web framework that gets a working product in front of users faster than most alternatives and keeps operating costs low once it is live.

This Ruby on Rails FAQ answers the questions technical decision-makers raise when weighing Rails against Node.js, Django, or Elixir for a new build or a rescue: what it costs to run, where it scales, where it stops, and what a competent partner should be able to prove.

Monterail's Ruby on Rails engineering team has delivered over 100 Rails projects, and the answers below draw on that work.

How Does Rails Compare to Node.js, Django, and Phoenix?

Choose Rails when delivery speed and a small operating surface matter most, Node.js or Phoenix when concurrency binds, and Django when the product sits close to Python's data tooling.

The 2025 Stack Overflow Developer Survey separates the most and least adopted options below by over an order of magnitude (Phoenix sits at 2.4%, and Node.js at 48.7%), which shapes how quickly you can staff each stack.

Django ships sessions and caching but leaves background jobs and deployment to add-ons; Node builds assemble all four from separate packages. Rails ships them as defaults, trading a smaller hiring pool for fewer systems to run.

Only the adoption column comes from survey data. The rest is Monterail's engineering assessment from client projects; a team already fluent in one of these stacks should weight the hiring column differently.

How Do Rails Defaults Translate Into Lower Run Costs?

Rails 8 moved the operational layer into the framework itself. Solid Queue took over background jobs from Redis and Sidekiq, Solid Cache took over from Memcached, Solid Cable replaced Redis as the WebSocket pubsub, Kamal 2 handles deployment without a platform-as-a-service bill, and the Thruster proxy removes the need for Nginx in front of the app.

The Rails 8 release announcement reports Solid Queue "running 20 million jobs per day for HEY alone at 37signals" and Solid Cache storing 10 terabytes of data in production at Basecamp.

A team that skips four vendor integrations also skips the glue code, the extra status pages, and four separate upgrade windows a year. Rails 8.1 extended the same logic to delivery with a CI declaration in config/ci.rb run by bin/ci, plus Active Job continuations that let long jobs resume from the last completed step instead of restarting, both documented in the Rails 8.1 release notes. Testing sits in the same category: Rails generates test files and fixtures alongside every model and controller, so test-driven work starts from a running suite.

The measurable effect shows up on the infrastructure line. The Register reported in May 2025 that 37signals expected its yearly infrastructure bill to fall from $3.2 million on cloud to well under $1 million on owned hardware, after $700,000 spent on servers that took over AWS workloads cut its cloud bills by about $2 million a year.

Where Does Ruby on Rails Fit Best?

Rails suits products where business logic is complex, data is relational, and traffic is substantial but not extreme.

Marketplaces and booking platforms match the framework's strengths, because transactions, profiles, search, and scheduling all touch one relational model. The Seat Unique premium ticketing platform runs Rails alongside React, Next.js, and Elixir for ticket sales; in 2025 it sold 193,000 tickets to more than 56,000 customers, and it serves over a million visitors a month.

E-commerce is the other established use case: Spree and Solidus supply catalog, cart, and checkout as mountable engines rather than custom code, with payment gateways wired in through maintained adapters. Our case for Rails in e-commerce development sets out where the buy-not-build line falls.

Constrained-bandwidth and regulated products work well too, when payload size and browser support become product requirements. The Merck DORA diabetes risk assessment app pairs Rails with Vue.js and was cut to 0.7MB for African markets, where 60% of users are on Opera Mini; it now runs in nine countries.

SaaS products with heavy back-office logic, subscription billing, and reporting are another natural fit, since Active Record and background jobs cover most of what those applications need. The same applies to internal platforms and admin-heavy web application development, where generated CRUD and a mature authorization layer beat rebuilding the same screens in a front-end framework.

Which Companies Run Ruby on Rails at Scale in 2026?

Shopify and GitHub run Rails at production scale today, and the framework's development is funded directly by the companies that depend on it.

How Does Shopify Use Rails?

Shopify runs one of the largest Rails codebases in production and has kept its core as a modular monolith. Its Rails Foundation profile records 3,100+ engineers on the codebase, 2,200+ of them Rails engineers, with Black Friday 2025 peaking at 489 million requests per minute and over 53 million database queries per second.

How Does GitHub Use Rails?

GitHub's account of building on Rails describes "nearly two million lines of code" worked on by "more than 1,000 engineers," deploying "as often as 20 times a day, and nearly every week one of those deploys is a Rails upgrade." Migrating off its custom Rails fork once took months; upgrades now take under a week.

Who Funds Rails Development?

Institutional funding is the stronger signal for a five-year decision. The Rails Foundation is backed by ten core members paying $75,000 a year each (Shopify, GitHub, 1Password, 37signals, Procore, Doximity, Cookpad, Fleetio, Fin, and Judge.me), plus 14 contributing members at $25,000 a year.

Our roundup of companies still running Ruby on Rails in 2026 covers the wider list.

Can a Ruby on Rails App Scale, and How Do You Scale It?

Yes, provided the application is built with scalability in mind from the start. Rails applications that scale badly are typically ones where N+1 queries, missing indexes, and unbounded serialization went unnoticed until traffic exposed them. The work pays off in this order:

1. Query and index work. Slow endpoints usually trace back to slow queries; our guide to Rails database optimization techniques covers indexing, query rewriting, read replicas, and connection pooling.

2. Caching. Fragment, page, and Russian doll caching cut render cost before any hardware is added, as set out in our breakdown of Rails caching strategies that reduce response time.

3. Horizontal capacity. Adding application servers behind a load balancer is the usual first response to load, and Kamal makes it a configuration change.

4. Service extraction. As the codebase grows, moving the part under the most load into a separate service is the standard next step; our analysis of the monolith-or-microservices decision sets out how to judge the timing.

Connection limits and query plans usually bind before CPU does, so budget for the database ahead of the application servers.

Runtime performance also improves independently of your code, though unevenly. Shopify's Rails at Scale blog, in its ZJIT launch post from December 2025, says: "It's faster than the interpreter, but not yet as fast as YJIT." The same post advises holding off on production use for now, so keep planning production capacity around YJIT.

Can Rails Be Used for Building AI-Based Solutions?

Yes, with a division of labor. Model training and heavy numerical work belong in Python. Rails owns the domain model, permissions, and audit trail that AI features read from and act on, which is where most of the engineering effort in an AI product sits.

That makes AI an architectural decision, not a widget. Which records a model may see, which actions an agent may take on a user's behalf, and how every model-driven change is logged are all questions about your domain model and authorization layer, and Rails already structures both. Inference runs behind an API with its own runtime and its own cost model.

Two Ruby libraries now cover the integration layer. The RubyLLM framework provides one interface across 19 providers, including OpenAI, Anthropic, Gemini, Bedrock, and local Ollama, with Rails generators, an acts_as_chat Active Record integration, and an optional chat UI. Active Agent treats agents as controllers with actions, callbacks, and views, and supports remote Model Context Protocol servers; the core gem is MIT-licensed.

Is Ruby on Rails Still Current in 2026?

Yes. Rails 8.1 arrived on 22 October 2025 as "the work of over 500 contributors across 2500 commits," according to the Rails 8.1 release announcement, and the current stable version is 8.1.4, published 24 September 2026, per the Rails gem version history.

The Ruby 4.0.0 release announcement of 25 December 2025 adds faster Class#new, independent GC heap growth, and cheaper instance variable access, and ships the Rust-based ZJIT compiler as experimental, enabled with --zjit. Teams that stay current inherit those gains for the price of an upgrade cycle.

Hotwire delivers interactive interfaces without a separate single-page application, Propshaft became the default asset pipeline in place of Sprockets, and Rails 8.1 added structured event reporting through Rails.event.notify for observability that previously needed an external agent.

Our overview of Rails updates and development trends tracks what each release changes for existing applications, and why Rails remains a top web development framework sets out the longer argument.

When Should You Not Use Rails, and What Should You Use Instead?

Rails is not a good match for workloads bounded by concurrency, latency, boot time, or raw computation. Rails complaints beyond those usually trace back to untuned defaults and to teams without Rails performance experience: convention over configuration accelerates a team that knows the conventions and penalizes one that does not.

Our Ruby vs Elixir comparison works through where the first row falls.

Is Ruby on Rails a Good Choice for MVP Development?

Yes, because an MVP's cost is dominated by work that is identical across products. Accounts, sessions, uploads, transactional email, and background processing consume most of a first build, and Rails generates or ships all of them. Permissions and an admin interface come from mature gems rather than the framework itself, which is still faster than building either. What remains is the part that distinguishes your product, which is where the budget should go.

The speed advantage has preconditions. It assumes developers who already know Rails conventions, since a team learning them concurrently will not see it. An MVP built to be discarded also needs different engineering care from one intended to become the production system, so that call has to be made deliberately at the start.

Our MVP development service treats that as a scoping question from day one. For what can be validated before any code exists, our guide to the AI-enhanced prototyping process covers the current tooling.

What Ongoing Maintenance Does a Ruby on Rails App Require?

Rails maintenance follows a predictable annual shape, and nothing breaks on the day you skip it, which is why it gets deferred.

Under the Rails maintenance policy, a minor release receives bug fixes for one year and security patches for two years from the first release in its series, with new feature releases targeted roughly every six months. Check your current series against that window before planning a release quarter, because falling outside it means backporting patches yourself or accepting known vulnerabilities.

Capacity planning should run against real traffic data. For regulated products, compliance and code audit work is a fixed recurring cost.

Teams inheriting an older application should start with an assessment rather than a rewrite. Our checklist on when to update an old Ruby codebase sets out how to sequence that work alongside feature delivery.

How Do You Choose a Ruby on Rails Development Company?

Test for Rails depth, evidence of outcomes, communication, contracted post-launch support, and cost transparency. A team fluent in Rails conventions writes code the next team can read, which is where a large share of maintenance cost hides. Each criterion below has a test you can run during the sales process.

Monterail's own record against the evidence test is 64 verified reviews at 4.8 out of 5 on Clutch, with Premier Verified status. Our buyer's guide to Ruby on Rails development companies outlines the full evaluation process, including reference-check questions to ask a partner's existing clients.

What Has to Be True Before You Commit to Rails?

Confirm these conditions in advance so you don't have surprises mid-build. Your data model needs to be relational and your workload database-bound, and your traffic profile has to fall short of the cases in the "when not to use Rails" table above.

Do Your Existing Integrations Suit Rails?

Legacy systems reached over SOAP, fixed-width files, or vendor SDKs published only for Java or .NET add an adapter layer that Rails does not shorten. Environment parity matters too: Kamal assumes you control the target machines, so a locked-down corporate hosting estate can remove the deployment savings described above.

Which Compliance Requirements Sit Outside Rails?

Rails covers the application-layer defaults documented in the Rails security guide, including CSRF tokens in generated forms, parameterized queries, encrypted session cookies, and encrypted credentials. GDPR, SOC 2, and regional data residency sit above that layer and depend on your hosting topology, data model, and retention policy. If a regulated market is in scope, those requirements should shape the first migration.

Who Owns a Rails Codebase After Launch?

At least one engineer needs to know Rails conventions well enough to deliberately override the defaults, because default-driven applications underperform in ways that surface late. Handover documentation, a written upgrade calendar, and a named owner for the annual upgrade cycle are what keep a Rails codebase maintainable after the original team moves on.

Will Your Rails Decision Still Hold in Five Years?

Whether a Rails application still serves the business in 2031 depends on three habits: upgrades budgeted annually instead of deferred, query performance reviewed before users report it, and conventions the next team can read. Rails makes the upgrade path and the conventions cheap to work with; the query discipline and the ownership are yours to supply. Rails projects usually fail for reasons the framework never touched: unclear ownership, deferred maintenance, or a scaling assumption nobody tested. And products that outgrow Rails almost always outgrow one specific part of it, which calls for a service extraction rather than a rewrite.

If you are weighing Rails for a new product or inheriting a Rails codebase that has fallen behind, Monterail's Ruby on Rails team can assess where you stand and scope the work with you. Get in touch to start that conversation.