Articles on Rails

When I first started thinking about private gem distribution, I approached the problem the way I always do, backward from bundle install. What does a developer need to make that command succeed for a private library? Three things: a source (URL or repo), credentials that work in CI and locally, and a reliable way to receive updates without breaking deployments.

Not all code belongs on RubyGems.org opens a new window , and that’s okay. Sometimes the goal is internal reuse- sharing an SDK or auth client across services. Sometimes it’s a business model: you ship a private gem behind a license. Either way, the constraints are the same: authentication, delivery, and trust.

In this blog post, we’ll give an overview of the options for distributing private gems.

When we think about Ruby code coverage, our go-to gem for this is SimpleCov opens a new window , which works great when the test suite uses Minitest opens a new window , RSpec opens a new window , Cucumber opens a new window , Capybara opens a new window , and all these tools that are integrated with Ruby and Rails. But many applications also use other tools like Playwright opens a new window or Cypress opens a new window to run e2e tests, and we can’t use SimpleCov the same way.

Most of the time, what we have seen is that the Ruby code executed when running these tools ends up left behind and not being counted for the total code coverage, even though we know the code is actually being tested.

The Asset Pipeline has had many changes over the years, from not needing NodeJS when using Sprockets, to supporting NodeJS to manage JS dependencies through npm packages, to requiring NodeJS by default with Webpacker, and to not needing NodeJS by default again with ImportMaps.

ImportMaps is a good way to not have NodeJS as a dependency of the application, but it has many limitations (like the lack of TypeScript support) and it requires a lot of work to migrate to it when upgrading older applications.

In this blog post, we will see how to use Bun to remove the need to install NodeJS system-wide, how to use the standalone binary to not require an installation step, and at the same time keep using npm packages as needed to make the transition easier.

Today is a sad day because last week a platform that we know, like, and trust made a surprising and disappointing announcement.

On February 6, 2026, Heroku published an update on the future of the platform opens a new window . The announcement confirms what many in the community had suspected for a while: Heroku is transitioning to a “sustaining engineering model.”

In plain English, that means maintenance model: No new features, no new Enterprise Account contracts for new customers, and a focus on stability only.

If your Rails application runs on Heroku, this is the moment to start thinking about your next move. The platform is not disappearing overnight, but the direction is clear: Heroku’s best days are behind it and it’s time to migrate on your own terms to a provider that is not on maintenance mode.

Considering all this we are announcing a new productized service by FastRuby.io: Our Heroku Migration Service.

As Rails continues to evolve, each release not only introduces new features but also addresses security vulnerabilities and enhance the framework. When a version reaches End-of-Life (EOL), it means it will stop receiving security patches. As a result, any known CVEs (Common Vulnerabilities and Exposures) remain unaddressed in applications running those unsupported versions.

In this post, we’ll break down recent Rails-related CVEs, show which versions are still affected what’s the impact and how it can be fixed.

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.

Most of the times when we use the gem install command, we only ever need to pass it a few flags like the gem version or the path, in the case of a local gem. However, RubyGems has an often overlooked option that allows us to verify the authenticity and integrity of gems before installing them.

This flag that can quietly protect your system from running code you didn’t intend to trust. In this blog post, we’ll explore how RubyGems signing works, what the trust policy actually does, and why enabling it can make your gem installs far more secure.

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 opens a new window . 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 opens a new window 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 opens a new window 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 opens a new window and start playing right away!

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 opens a new window , we offer specialized Rails upgrade, maintenance, and technical debt services.

Before doing an upgrade, we strongly recommend doing the Roadmap to Upgrade Rails opens a new window , 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.

Rails Engines are an architectural pattern that can be used to modularize a Rails application. They are self-contained applications that can be mounted within a larger Rails application. In this post, we will dive into the world of Rails Engines and explore what they are, how to create them, how to use them, when to use them, and why they are important.

You might have extended classes or instances in Rails, but do you know you can also extend Rails associations?

class Account < ActiveRecord::Base
    has_many :people, -> { extending FindOrCreateByNameExtension }
end

In this article I’ll discuss a strategy for different readability: a simple way to split your routes file on a Ruby on Rails project.

Let’s begin with a simple question:

Have you seen config.load_defaults 6 in any application?

6 is an argument and could vary, I’m just giving an example.

Rails UJS opens a new window (Unobtrusive JavaScript) is the JavaScript library that helps Rails do its magic when we use options like remote: true for many of the html helpers.

In this article I’ll try to explain the main concept of how this works to make it transparent for the user. Knowing a bit about the inner workings can help when debugging issues and also if we need to do something more complex than the provided interactions but reusing what’s provided.

If you are using an old version of Rails and you are still using jquery-ujs opens a new window , some code will not reflect how it does the magic, but most of these concepts apply as well (rails-ujs is a re-implementation of jquery-ujs removing the jquery dependency).

Have you ever had to deal with complex forms creating multiple objects and hierarchies in one request? Rails is there to help provide a set of helpers, methods and conventions to build nested forms, handle assignment, and creation of the objects involved in only a few lines of code. In this blog I’ll explain how that works using accepts_nested_attributes_for, fields_for, strong parameters and more.

Since the release of Rails 6, Webpack is the default JavaScript bundler for new Rails apps. We all struggled at first coming from a Sprockets background, and more often than not, we, as Rails developers, tried to avoid making JavaScript changes so we wouldn’t have to deal with it.

In this post, I’ll try to explain some basic concepts and ideas from the point of view of a Rails developer used to working with the Assets Pipeline, comparing how to do the same thing on both.

Service Objects are a controversial idea for several different reasons: some developers like to use them, others like to use similar patterns, and some think that they are just unnecessary because they prefer fat models.

Here at OmbuLabs we like to use service objects whenever we can, we think it’s a great way to keep our controllers skinny.

In this post I would like to discuss my idea about service objects and why it’s adopted by our team.

At OmbuLabs opens a new window , we are big fans of Ruby on Rails opens a new window and design patterns opens a new window , especially convention over configuration opens a new window ! The beauty of Rails is that you can inherit a legacy project and easily find the different layers of code in different directories.

When it comes to database migrations the policy of Rails is very clear. It’s all about altering the database structure with gradual migration files: “Migrations are a convenient way to alter your database schema over time in a consistent and easy way.” (source opens a new window )

But, what about data migrations? What’s the best way to write, maintain, and run migrations that alter the data in your production database?

In this article I will talk about three different patterns for writing and maintaining your data migrations:

1. Data migrations in db/migrate
2. Data migrations with a set of Rake tasks
3. Data migrations with data_migrate

If you are interested in Ruby and Rails performance, you have definitely read articles by Nate Berkopec opens a new window from Speedshop opens a new window . At Ombu Labs we are big fans of his work, his Complete Guide to Rails Performance book opens a new window and Slack community.

When Nate announced a series of public workshops opens a new window I didn’t hesitate and signed up as quickly as possible. Here are my notes from my experience at the workshop on October 17th.

When working on a Rails project, you may have seen present? calls on ActiveRecord relationships. This might feel natural, mostly because present? exists on all objects via ActiveSupport opens a new window , so you expect the relationship to respond to it, but it’s actually not a very good idea. If all we want to do is check if the scope returns any results from the database, there are better ways than using present?.

A few weeks ago, I noticed weird output in the RSpec opens a new window test suite (~4000 tests) for a Rails opens a new window application:

.............................................................................................unknown OID 353414: failed to recognize type of '<field>'. It will be treated as String  ...........................................................................................................................................

This Rails app uses a PostgreSQL opens a new window database. After some Googling, it turns out that this is a warning from PostgreSQL. When the database doesn’t recognize the type to use for a column, it casts to string by default.

When writing tests for services, you may sometimes want to use mock objects instead of real objects. In case you’re using ActiveRecord and real objects, your tests may hit the database and slow down your suite. The latest release of the rspec-mocks opens a new window library bundled with RSpec 3 opens a new window includes at least three different ways to implement a mock object.

Let’s discuss some of the differences between a spy, a double and an instance_double. First, the spy:

[1] pry(main)> require 'rspec/mocks/standalone'
=> true
[2] pry(main)> user_spy = spy(User)
=> #<Double User>
[3] pry(main)> spy.whatever_method
=> #<Double (anonymous)>