Years of work,
kept up to date
We build features and upgrades for Ruby on Rails applications, move them to supported Rails and Ruby versions one step at a time, and test every change, so new work doesn’t have to wait for the upgrade.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When the deprecation warnings pile up
Rails ships a release with new features about every six months, and each release series gets security fixes for two years from its first release. An app that isn’t moved up regularly ends on a series that gets none.
Each move can change behavior. Rails pairs its breaking changes with deprecation warnings a release ahead, so the warnings in the logs and the test run are the early notice, and the easiest thing to leave for later.
Ruby keeps its own schedule, so an app can be current on one and not the other. And the move often waits on the app’s gems, the libraries it’s built with, each of which has to support the new version. None of this is the same for every app: it depends on its age, its gems and its tests.
What we build
Every change runs the tests, the security scans and the style checks before anyone reviews it, and every upgrade waits on a branch until it passes, so the app you run keeps working while the work goes on.
New Rails applications
Started on the current release and its defaults, with tests written from the first commit.
Features for the app you run
New features in the codebase you have, with tests added first around the code they touch, and written the way the rest of the app is written.
Upgrades, one release at a time
Rails moved up one minor release at a time and Ruby in a step of its own, the deprecation warnings fixed first. Each move waits on a branch until the tests pass, then merges.
Background jobs
Work that runs outside the request, on Active Job and the queue your app already uses, with retries, and long jobs that continue from their last finished step after a restart, as Rails 8.1 allows.
Pages that update in place
Hotwire’s Turbo and Stimulus, so a page changes only the part that needs to, with little JavaScript, or a JSON API for a separate front end.
APIs and integrations
JSON APIs for your apps and partners, and the services your app talks to, with every incoming payload validated before the app uses it.
Faster pages and queries
Slow and repeated queries found and fixed, and caching where it helps, with timings taken before and after each change.
Checks on every change
The tests, the code scanner, the gem audit and the style checks run on every change, in your CI or in the local CI Rails 8.1 added, and nothing merges until they pass.
AI where it helps
Changes drafted with AI coding assistants go through the same checks and the same review as anyone’s, and a person approves each one before it merges.
- For hosting and deploys:Cloud, DevOps & Security
- Older apps, improved a part at a time:Legacy Modernization
- APIs between your systems:Systems & API Integration
- The tests behind each change:QA & Test Automation
- Developers in your own team:Hire developers for Ruby on Rails applications
Rails and Ruby, each on its own schedule
Rails gives each release series security fixes for two years from its first release. Today that’s Rails 8.1, until October 10, 2027, and Rails 8.0, until November 7, 2026. Rails 7.2 had its last release on September 24, 2026.
Ruby’s branches keep dates of their own. Today Ruby 4.0 and 3.4 are in normal maintenance, with bug fixes and security fixes; 3.3 gets security fixes only, until its expected end of life on March 31, 2027; and 3.2 reached its end of life on April 1, 2026.
An app gets security fixes only while both its Rails and its Ruby do. So we move one of the two at a time, on a branch, with the tests passing, after fixing the warnings each move brings. Choose the pair your app runs on.
Rails across, Ruby down
Both get security fixes today
Rails 8.1: security fixes until October 10, 2027.
Ruby 4.0: normal maintenance, with bug fixes and security fixes. No end of life set yet.
Together: both get security fixes today. The next step is each patch and security release, as it comes.
Rails 8.0: security fixes until November 7, 2026.
Ruby 4.0: normal maintenance, with bug fixes and security fixes. No end of life set yet.
Together: security fixes for both until November 7, 2026, Rails 8.0’s date. The next step is Rails 8.1.
Rails 7.2: no longer on the security list. Its last release came on September 24, 2026.
Ruby 4.0: normal maintenance, with bug fixes and security fixes. No end of life set yet.
Together: Rails 7.2 no longer gets security fixes. The next step is Rails 8.0.
Rails 8.1: security fixes until October 10, 2027.
Ruby 3.4: normal maintenance, with bug fixes and security fixes. No end of life set yet.
Together: both get security fixes today. The next step is each patch and security release, and Ruby 4.0 once your gems run on it.
Rails 8.0: security fixes until November 7, 2026.
Ruby 3.4: normal maintenance, with bug fixes and security fixes. No end of life set yet.
Together: security fixes for both until November 7, 2026, Rails 8.0’s date. The next step is Rails 8.1.
Rails 7.2: no longer on the security list. Its last release came on September 24, 2026.
Ruby 3.4: normal maintenance, with bug fixes and security fixes. No end of life set yet.
Together: Rails 7.2 no longer gets security fixes. The next step is Rails 8.0.
Rails 8.1: security fixes until October 10, 2027.
Ruby 3.3: security fixes only, until its expected end of life on March 31, 2027.
Together: security fixes for both until March 31, 2027, Ruby 3.3’s expected end of life. The next step is a newer Ruby.
Rails 8.0: security fixes until November 7, 2026.
Ruby 3.3: security fixes only, until its expected end of life on March 31, 2027.
Together: security fixes for both until November 7, 2026, Rails 8.0’s date. The next step is Rails 8.1.
Rails 7.2: no longer on the security list. Its last release came on September 24, 2026.
Ruby 3.3: security fixes only, until its expected end of life on March 31, 2027.
Together: Rails 7.2 no longer gets security fixes. The next step is Rails 8.0.
Rails 8.1: security fixes until October 10, 2027.
Ruby 3.2: end of life since April 1, 2026, with no further fixes.
Together: Ruby 3.2 no longer gets fixes. The next step is a newer Ruby.
Rails 8.0: security fixes until November 7, 2026.
Ruby 3.2: end of life since April 1, 2026, with no further fixes.
Together: Ruby 3.2 no longer gets fixes, and Rails 8.0’s security fixes end on November 7, 2026. The next step is a newer Ruby.
Rails 7.2: no longer on the security list. Its last release came on September 24, 2026.
Ruby 3.2: end of life since April 1, 2026, with no further fixes.
Together: neither gets fixes now. The next step is a newer Ruby, then Rails 8.0.
We move one of the two at a time, with your tests passing.
{{ vsStatus }}
New defaults, turned on one at a time
After a move to a new release, an app keeps the earlier release’s behavior until its defaults are raised, with the config.load_defaults setting.
The update task, bin/rails app:update, writes a file listing the new release’s defaults, so each can be turned on and tested on its own, over several deploys if needed, before that setting is raised.
Deprecation warnings say what the next release will change, and Rails 8.1 can also report each use of an association marked as deprecated, as a warning or as an error.
So we fix the warnings, move up one release, then turn on the new defaults one at a time, each with the tests passing.
Start with the Gemfile and the warnings
The review covers the Rails series and the Ruby version the app runs on, in development, in CI, in production and in its images, against both lists; the Gemfile and its lock file: the gems that block the next release, the ones no longer maintained and what the gem audit reports; the deprecation warnings in the logs and the test run; config.load_defaults, and any new defaults file left half done; the tests: what the busiest paths have, the system tests, and how long a CI run takes; background jobs: the queue, the retries and the long jobs that can’t pick up after a restart; performance: slow pages, repeated queries and caching, measured as a baseline for the review; security: the code scanner’s report, credentials and the sign-in the app uses; and how the app is built and deployed, and how its assets and JavaScript are served.
The first step is one of these, each tried on a branch: the deprecation warnings fixed, with the tests passing; Ruby moved to a supported branch; Rails moved up one minor release; the code scanner and the gem audit added to CI; or one slow page profiled, with one change measured before and after.
What you receive is a written review and a proposal for that first step.
Questions worth asking
Which Rails versions get security fixes?
Each release series gets security fixes for two years from its first release. Today that’s Rails 8.1, until October 10, 2027, and Rails 8.0, until November 7, 2026. Past its date, a series gets no new versions, and its bugs and security issues are the app owner’s to deal with.
Which Ruby versions are supported?
Ruby lists its own branches. Today 4.0 and 3.4 are in normal maintenance, 3.3 gets security fixes only, until its expected end of life on March 31, 2027, and 3.2 reached its end of life on April 1, 2026. Ruby calls the list preliminary, so we check it again before each move.
Should we upgrade Ruby or Rails first?
One at a time, each with the tests passing. Rails’ upgrade guide suggests moving to the newest Ruby you can first, then Rails, and each Rails release names the oldest Ruby it needs. When one of the two loses its security fixes much sooner, that one often goes first.
We’re several releases behind. Where do we start?
With the tests and the warnings. We get the tests passing, move to the newest patch of the release you’re on, fix its deprecation warnings, then move up one minor release and turn on its new defaults one by one, each step on a branch. Then the next release, the same way.
Will our gems work on the new version?
We check each one before the move and update it, and we replace only the gems that are no longer maintained. The gem audit runs alongside, for known vulnerabilities.
Should we rewrite our Rails app?
Usually not. An app that does its job tends to be better improved a part at a time: the parts that hold you back first, each change tested and released on its own, while the rest keeps running.
Will Rails keep up as we grow?
That depends on where the time is spent: often in queries, in work a background job could do outside the request, or in pages that could be cached. We measure first, change what the measurements show, and measure again.
Do you work with Hotwire, or with a separate front end?
Both. With Hotwire, the app sends HTML rather than JSON, Turbo updates the part of the page that changed, and Stimulus adds the little JavaScript that’s left. Where a separate front end fits better, the app serves it a JSON API instead.
How do you keep our Rails app secure?
We keep it on a series that gets security fixes, apply security releases as they’re announced, run the code scanner and the gem audit on every change, and validate what users and other systems send.
Can AI assistants help with our Rails code?
Yes, within the same rules as everyone’s code. An assistant can draft routine changes and their tests, and a person reviews each change, after the full checks pass, before it merges.
Can you take over our existing app?
Yes. First we read it: the Gemfile, the tests, the jobs and how it’s deployed. Then we agree a first piece of work and who on our side owns it, and work with any developers you already have.
What does it cost?
It depends on your app, its size and the first step you choose. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can we hire developers for our own team?
Yes. Within 48 hours of your request we introduce developers who know Ruby on Rails applications and work in your time zone. You meet them first, and decide who joins.
Rails and Ruby on Rails are registered trademarks of David Heinemeier Hansson, exclusively licensed to The Rails Foundation. Webair is independent of Rails, its trademark owner and The Rails Foundation, and isn’t sponsored by, endorsed by or affiliated with any of them.
Let’s build it better
Tell us which Rails and Ruby versions your app runs on, and how it’s deployed. We’ll agree on a first step in a short call.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}