A typical scenario in the Rails world, after spending some time using it and playing with forms and requests, you realize that not everything is magic, there is some code that is in charge of cleaning things up so that you get in your controller the params, headers, and other request data that you need.

That’s where Rack comes in. Rack is the code that lives between the layers, from the moment the request starts until it reaches your controller. But it’s not just about input, the output works the same way. When you return something from your controller, Rack is there too.

In this post, we’ll cover a few examples where understanding how middleware works can help you solve real-life problems.

Rails 8.1 is set to bring a new API, Rails.event.notify(...), that will help make it simple to publish structured events that are immediately consumable by monitoring and Application Performance Monitoring (APM) platforms like Datadog, AppSignal, New Relic, or Honeycomb.

In this post, we’ll look at how it works, why it matters, and how to prepare your app for data-hungry observability tools.

DHH unveiled Rails 8.1 during his keynote at Rails World 2025, releasing the first beta live on stage. This new version brings a suite of tools aimed at making Rails apps simpler to build, maintain, and collaborate on. With a strong focus on developer experience and consistent workflows, Rails 8.1 helps teams sidestep common frustrations and work together more smoothly.

Maintaining a Ruby on Rails application often slips down the priority list. Everything seems fine, until suddenly it isn’t. A gem update breaks a feature, a security flaw makes headlines, or your app refuses to deploy after a server upgrade. When that happens, teams scramble to find help, often at the worst possible time. This “as-needed” upgrading approach may appear cost-effective in the short term, but it leads to stress, downtime, and unpredictable expenses.

But there is a smarter path forward: fixed-cost monthly maintenance. In this post, you’ll see why investing in a maintenance retainer is better than reactive upgrades, and how our service delivers value month after month.

Ruby on Rails has always moved at a steady, thoughtful pace: each new version brings not only features and performance improvements but also important security hardening. But with every release cycle, older versions reach the end of their lifespan. When a version is officially End-of-Life (EOL), it no longer receives bug fixes or security patches — leaving applications increasingly vulnerable as new threats emerge.

Rails 7.1 has been a dependable workhorse since its release in 2023. But on October 1, 2025, Rails 7.1.x will lose official security support. That means no more patches for new vulnerabilities, no more backports, and no safety net if a zero-day exploit lands in your stack.

If you’re running Rails 7.1, your risk level depends heavily on which Ruby version you pair it with. Some Rails and Ruby combinations will be doubly unsupported after October 1st, creating “dangerous pairings” that should be upgraded immediately.

In this post, we’ll break down:

• Which Ruby on Rails setups will lose support after October 1, 2025.
• Why those combinations are risky.
• How to quickly check your environment using our table below.
• What to do if you are using a vulnerable pair.

The Roadmap to Upgrade Rails is FastRuby.io’s discovery product that helps teams plan and execute their Rails upgrade projects.

We’re happy to introduce an Automated Version of the Roadmap, powered by an AI agent, available completely for free!

Check it out on the Automated Roadmap to Upgrade Rails page and keep reading to learn more about how it works.

At FastRuby.io, we spend our days deep in Rails codebases, upgrading, refactoring, and occasionally wondering, “Wait… is this method from Ruby or Rails?”.

Now, we’re turning that moment of confusion into a game. We’re excited to introduce Is It Ruby or Rails?, a brand new Discord bot that delivers daily puzzles to challenge your Ruby knowledge and fuel a little friendly competition.

You can install it using the Discord install link and start playing right away!

When people hear the phrase “technical debt”, they often picture broken code, outdated infrastructure, or a total rewrite waiting to happen. But in our experience at Planet Argon, technical debt usually shows up more quietly.

It’s not a crisis. It’s a pattern.

It shows up in how long it takes to make changes, how often bugs sneak in, and how hesitant developers are to touch certain parts of the codebase. And while it rarely announces itself, it always costs something — whether in time, budget, or momentum.

In this post, we’ll highlight real-world examples of how technical debt has surfaced in Rails applications we’ve worked on. These aren’t horror stories — they’re common issues we see even in well-run projects. More importantly, we’ll share some ways teams can manage debt strategically without a massive rewrite.

At FastRuby.io, we deeply value the Ruby and Rails communities and believe in giving back through open source contributions. We wouldn’t be where we are today if it wasn’t thanks to a lot of open source projects we use on a daily basis.

We actively use, maintain, and enhance several tools designed to empower developers and teams who want to handle Ruby and Rails upgrades themselves, especially those who might not have the budget to hire our services.

These open source projects facilitate upgrades by improving transparency, managing technical debt, and ensuring smooth transitions between Ruby and Rails versions.

Here’s an overview of each tool and how it can support your next upgrade project.

Whether you’re debugging a dependency issue, checking for an optional gem, or just curious about what’s loaded in your Ruby app, there’s a handy command that can help:

puts Gem.loaded_specs.keys.grep(/your_pattern_here/)

In this article, we will discuss what this command does, what exactly it’s checking for, and its limitations.

At FastRuby.io, we offer specialized Rails upgrade, maintenance, and technical debt services.

Before doing an upgrade, we strongly recommend doing the Roadmap to Upgrade Rails, a static analysis of your codebase that outlines the action plan to do the upgrade and provides time and investment estimates.

The first step in every Rails upgrade we do is addressing deprecation warnings in the current version. So recently, we set out to extract all deprecation warnings from all versions of Rails starting at Rails 2.3 to help in our static analysis of Rails applications.

Having reproducible development environments is one of the best ways to guarantee ease of application setup and code sharing in teams. Dev containers are a way to achieve this.

In this article we’ll try to give you a small introduction to what dev containers are at their core and provide a minimal example on how to set up a Rails application to use dev containers.

In this article we will present compatibility between Ruby and Heroku across different versions. In the process of upgrading really old applications to more modern versions of Ruby we have run into a lot of these combinations.

In Ruby, we often want to rename methods or attributes for clarity, to extend functionality and for compatibility. However, there are three different tools for this, each with its own use case and behavior: alias, alias_method and alias_attribute.

In this post we’ll go over each one of them, what they actually do and when to use them.