The benefits of building software with Ruby on Rails are speed and economy for one kind of project in particular: a web application backed by a database, built by a small team. Rails makes most of the routine decisions for the developer, includes nearly everything such an application needs, and since version 8 can be hosted with very few extra services. The trade-offs are a smaller pool of developers than .NET, PHP or JavaScript, a brisk upgrade cycle, and a poor fit for an organisation whose other systems and skills sit on a different technology.
What Ruby on Rails is
Ruby is a programming language. Rails is a framework written in Ruby for building web applications: the screens, the business rules and the database access together. It is open source under the MIT licence, so there is nothing to pay for it.
The current release series is Rails 8.1, and version 8.1.4 was released on 24 September 2026. Rails has a non-profit foundation behind it whose core members include Shopify, GitHub and 37signals, the company where Rails began. The Rails website lists Shopify, GitHub, Basecamp and Airbnb among the organisations that use it.
The benefits
A working application sooner. Rails follows a principle its authors call convention over configuration. The framework decides how files are named, how the database is reached and how a web address maps to code, so developers spend their time on your requirements and not on plumbing. For a standard business application, with records, forms, searches and workflows, this means less code to write and to pay for.
Most of what you need is included. Database changes, background jobs, email, file uploads, caching and automated testing are part of the framework. Rails 8 went further. Background jobs, caching and live page updates can now run on the application’s own database, where earlier versions normally needed a separate service such as Redis. It also includes a generator for sign-in screens and comes with Kamal, a tool for releasing to an ordinary Linux server. Fewer moving parts means lower hosting costs and less to go wrong.
Every Rails application has the same shape. Because the conventions are shared, a developer who knows Rails can find their way around an unfamiliar Rails application quickly. That matters on the day your developer or supplier changes.
Sensible security defaults. Rails protects against the common web attacks, including SQL injection, cross-site scripting and forged form submissions, as long as developers use the framework as intended and keep it up to date.
Testing is built in. Rails creates test files alongside the code it generates, and the Rails community expects them to be filled in. A test suite is what makes later changes and upgrades safe.
The trade-offs
Fewer people know it. In the Stack Overflow Developer Survey 2025, about 6% of respondents had worked with Ruby in the previous year, against about 28% for C# and 19% for PHP. Rails developers tend to be experienced, but there are fewer of them and fewer suppliers. Before committing, find out how many firms and contractors within reach of you work with Rails.
Upgrades come round quickly. The Rails project aims to publish a release with new features every six months, and each release series gets security fixes for two years from its first release. A Rails application therefore needs a framework upgrade at least every two years to stay supported. By comparison, a long-term support version of .NET is supported for three years and a PHP version for four.
It rests on libraries maintained by volunteers. A typical Rails application uses dozens of add-on libraries, called gems. Most are well looked after. One that has been abandoned can block an upgrade until it is replaced. Every modern technology shares this risk, and it needs checking from time to time.
It is a second set of skills if you are a Microsoft organisation. Rails is normally run on Linux with a database such as PostgreSQL or MySQL. If your other systems are .NET and SQL Server, a Rails application means separate hosting and separate people.
On scale, the old worry that Rails cannot cope with heavy use does not stand up, given the size of some of the sites that run on it. For a business application with a few hundred users it is not a consideration.
Support dates to know
| Component | Position in October 2026 |
|---|---|
| Rails 8.1 | Bug fixes until 10 October 2026, security fixes until 10 October 2027 |
| Rails 8.0 | Security fixes until 7 November 2026 |
| Rails 7.2 and earlier | No longer on the Rails project’s list of supported releases |
| Ruby 4.0 and 3.4 | Fully maintained. Ruby 4.0 is the current stable version |
| Ruby 3.3 | Security fixes only, expected to end on 31 March 2027 |
| Ruby 3.2 and earlier | Unsupported. Ruby 3.2 ended on 1 April 2026 |
Rails and Ruby have separate dates, and an application needs both to be in support.
If you have inherited a Rails application
Start by finding out what you have. A file in the code called Gemfile.lock records the exact Rails version and every gem in use, and the Ruby version is normally recorded alongside it. Compare them with the table above.
Then ask three things. Does the application have automated tests, and do they pass? When was it last released, and can anyone still release it? Who holds the accounts for the hosting, the domain and the code repository? Our software takeover checklist covers these checks for a system on any technology, and our page on what to do when your developer has left covers the first week.
An application several versions behind is upgraded one release series at a time, running the tests at each step. It is slower than jumping straight to the newest version, and much less likely to break something unnoticed.
A Rails application is not a reason to rewrite. If it works and can be brought back into support, the usual case for keeping what you have applies, as our answer on rewriting or modernising legacy software explains. The exception is when you cannot find anyone to maintain it at a price that makes sense.
We should be plain about where we stand. CodeFirst works mostly with Microsoft technology, so we are not Rails specialists, and a Rails specialist is the right choice for Rails work. Our article on choosing the right technology sets out the tests we would apply to any option.
Questions to ask a supplier who proposes Rails
- Which Rails and Ruby versions will you use, and what will the upgrade in two years cost?
- How many Rails developers do you have, and what happens if they leave?
- Which gems will the application depend on, and how do you check they are maintained?
- Will there be automated tests, and will we own the code and the hosting accounts?
- Who else could take this application over?
If the answers are specific, Rails is a sound choice for the kind of application it was designed for. If the supplier has one Rails developer and no answer to the fifth question, the risk is the supplier and not the framework.