Wiring an LLM into a Rails app takes a handful of lines. Understanding what it actually costs you (feature by feature, user by user) is harder. Most providers and SDKs already report tokens, latency, and even cost, but that data lives in their dashboard. It’s disconnected from your requests, your users, and the feature that made the call. And it sits apart from the APM and logs where you already watch the rest of your app.

In a previous post, we introduced Rails.event.notify(...) opens a new window , the tool-agnostic Event Reporter shipping in Rails 8.1. In this post, we’ll put it to work on a real problem: instrumenting every LLM call in your app so token usage, latency, and cost become structured events you can log, graph, and forward to any APM or data warehouse.

It’s common for Rails applications to serve massive CSS files filled with unused Bootstrap, Tailwind, or custom utility classes as projects grow. This bloat isn’t just a developer annoyance—it has a real impact on your users. Every unused kilobyte adds milliseconds to page load time. In this post, we’ll explore what PurgeCSS opens a new window is and how your Rails project can benefit from it.

This is a short post to show the compatibility between Sidekiq opens a new window and Ruby opens a new window across different versions. In the process of upgrading really old applications to more modern versions of Ruby and Sidekiq we have run into a lot of these combinations.

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.

In this article we will present compatibility between Ruby opens a new window and Heroku opens a new window 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.

For developers, segmentation faults can feel like a sudden nightmare—cryptic errors that crash your application out of nowhere. This frustration is amplified when they show up in high-level languages like Ruby, where memory management is typically handled behind the scenes. Recently, while running my Ruby application, I experienced a segmentation fault caused by a gem. The crash not only halted my program but also left me facing a daunting debugging challenge. In this post, I’ll talk about how I identified the issue, debugged it, and eventually found a solution.

Ruby 3.4 has been released, and the Ruby Core team continues to refine the language for a better developer experience and enhancements so our Ruby apps can have the best performance. In this blog post, we will talk about an interesting discussion happening about the # frozen_string_literal comment at the top of Ruby files.

When building a Rails application you will need to think about scaling as you get more and more users and data. One way in which your application may need to scale is at the database level. Rails supports using multiple databases, so you don’t have to store all your data in one place.

Rails progression emphasizes simplicity and productivity. Through versions, Rails integrated tools, enhanced performance, and adapted to industry standards, keeping a focus on developer happiness and efficiency. ActiveModel::Error is an example of that. On this blog post, we’ll dive into the evolution of this object.

A default Rails application is typically built with a relational database, such as PostgreSQL or MySQL, as its default data store. Building a Rails application with a NoSQL database can bring some benefits.

Imagine having the ability to deploy the next version of Rails in a dual booted application on your Heroku staging server or review app before deploying it to production. This capability can help you avoid bugs and downtime in your live environment. In this blog post, we will guide you on how to deploy a Rails upgrade to a staging environment, allowing you to thoroughly test it before it goes live.

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.