A few months ago, we were working on a Rails 7 app using Webpack 5. One of the main problems we had was that making a small change in the Javascript took around 39 seconds to recompile. You can imagine how much productivity we lost just waiting, and honestly, I personally remember getting really distracted during that dead time, just sitting there.

At that point, Webpacker had been retired, so we checked the official migration guide and found several options: the first was jsbundling-rails, the second was Shakapacker, another was Importmaps, and finally, we knew we had the option to try Vite.

We finally went with Vite, which (as noted on GitHub) is named after the French word for “quick” (pronounced /vit/, like “veet”). Our reload time improved a lot, it dropped to just one second, which felt like magic. In this post, I’ll explain why we chose it, and also why we got such a huge speed improvement.

After we’ve addressed all the deprecation warnings and successfully dual-booted an application, the next step in a Rails upgrade is often the most challenging: fixing the broken build.

At this point, the test suite is red, and our job is to bring it back to green. This phase can feel chaotic, but over the years at FastRuby.io, we’ve developed a process that makes it systematic and (relatively) predictable.

In this post, I’ll break down how we approach this step, what patterns we’ve noticed, and how we debug the trickiest failures.

At OmbuLabs, open source has always been at the core of our values. This year, for Hacktoberfest 2025, our team took the opportunity to give back to the communities that power our daily work, from Ruby developers tackling technical debt to those building the next generation of AI tools. Throughout October, we dedicated focused internal time to open source contributions. Our goal was twofold:

1. Strengthen and maintain the tools that power our work at FastRuby.io, helping teams manage technical debt and improve code quality.
2. Advance Ruby’s presence in artificial intelligence, contributing to libraries and frameworks that integrate Ruby with modern AI technologies. By aligning Hacktoberfest participation with our mission to give back, we turned this month into an opportunity for growth, learning, and meaningful community impact.

The beauty of Ruby’s open source ecosystem lies in its simplicity: add a gem, and you instantly gain powerful new features. But this same convenience can also expose your application to hidden threats. In recent years, attackers have increasingly targeted the supply chain, where dependencies, not code you write, become the weakest link. This post explores how supply chain attacks happen in RubyGems, gives real-world examples, and practical ways to protect your Rails projects.

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.

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.

For anyone that has ever used RubyCritic, churn calculations were always painful. Especially for projects with commit histories going back to when YouTube was mostly cat videos.

Here I’ll relate the story of how we were able to make churn calculations cut down from 30 minutes to just a few seconds or 4 or 5 minutes at worst.

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.

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.

Ruby 3.4.0 was released on December 25, 2024, bringing exciting new features, performance improvements, and some breaking changes. Here’s a practical guide of what’s new and what you should know before upgrading to this version.

Highlights

• New it block parameter reference: Cleaner, more readable blocks using it instead of the original _1.
• Language and core changes: Easier keyword argument handling, string literal warnings, reserved names, and updates to core classes.
• Standard library updates: RubyGems, Bundler, JSON, Tempfile, and more get useful updates.
• Compatibility and miscellaneous changes: New error message formats, hash and float handling, block and performance warnings, and deprecated features removed.
• Prism is now the default parser: Ruby’s parser is now Prism, making it possible for better tooling and error messages.
• Socket library upgrade: Happy Eyeballs v2 means faster, more reliable network connections out of the box.
• YJIT and Modular GC: Advanced performance and memory improvements for those using Ruby’s JIT or experimenting with garbage collection.

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.

Ruby 3.2, released in December 2022, introduced the Data class. A built-in, immutable value object for Rubyists who want simple, safe, and fast data structures without the boilerplate of custom classes or Structs. If you haven’t upgraded to Ruby 3.2 or later, you’re missing out on this powerful feature!