Tooling for Ruby and Rails Engineers

Every tool here is something I've either used in production or evaluated seriously enough to have an opinion. I'm not listing everything that exists — I'm listing what I think is worth your time, organized by the kind of problem it solves.

No outbound links here. Where a tool connects to a topic I've written about on this site, I'll point you to the relevant guide or topic page. For everything else, you can find official documentation through a quick search.

Development

These are the tools that shape your day-to-day writing and running of Ruby code.

IRB

Ruby's built-in interactive shell. IRB ships with every Ruby installation and gives you a REPL for testing snippets, exploring objects and debugging interactively. Since Ruby 3.0, IRB has gained multiline editing, syntax highlighting and auto-completion. For most quick experiments, IRB is enough. Where it falls short is complex introspection — that's where Pry picks up.

Pry

An enhanced Ruby REPL that replaces IRB with a more powerful interactive environment. Pry lets you navigate code with ls, cd and show-source commands, set breakpoints with binding.pry and inspect the call stack during debugging sessions. The main gotcha is that leaving a binding.pry in production code will freeze the process waiting for input. I use Pry in development and the debug gem in production-adjacent contexts.

Bundler

The dependency manager that resolves and locks gem versions for your Ruby project. Bundler reads your Gemfile, figures out which versions of which gems are mutually compatible and writes the result to Gemfile.lock. The lock file is what makes your builds reproducible. If you're running into version conflicts during upgrades, bundle update --conservative is your friend — it updates only the gem you specify and its direct dependencies.

RuboCop

A static analysis and code formatting tool for Ruby. RuboCop enforces style rules and catches potential bugs before runtime. The default configuration is aggressively opinionated — most teams customize it heavily via .rubocop.yml. My advice: start with RuboCop's defaults on a new project, but on existing codebases, enable cops incrementally rather than trying to fix everything at once. The rubocop-rails and rubocop-performance extensions add Rails-specific and performance-specific checks.

Solargraph

A language server for Ruby that provides autocompletion, hover documentation, go-to-definition and diagnostics in editors that support the Language Server Protocol. Solargraph works by analyzing your code and yard documentation. It's not perfect — Ruby's dynamic nature makes static analysis inherently incomplete — but it catches enough to be worth configuring. The biggest pain point is initial setup with complex projects that use metaprogramming heavily.

Testing

Good tools don't replace good judgment about what to test, but they do remove friction.

RSpec

A behavior-driven testing framework for Ruby. RSpec uses a descriptive describe/it syntax that reads like specifications. It's the most widely used testing framework in the Rails ecosystem. The learning curve is steeper than Minitest — RSpec has its own DSL for mocking, stubbing, matchers and shared contexts. The payoff is expressiveness, especially for complex test setups. If your team already uses Minitest and is productive with it, there's no strong reason to switch.

Minitest

The testing framework that ships with Ruby and Rails. Minitest is smaller and faster than RSpec, uses plain Ruby syntax and has a much thinner abstraction layer. A Minitest test is just a Ruby class with methods. For new Rails projects, the framework generates Minitest tests by default. I prefer Minitest for smaller projects and libraries, and RSpec for larger applications where the additional structure pays for itself.

FactoryBot

A fixtures replacement that lets you define blueprints for test data and create objects on demand. FactoryBot (formerly FactoryGirl) integrates with both RSpec and Minitest. The biggest trap is factory cascades — a factory that creates associated objects, each of which creates more associated objects, leading to slow tests and confusing data. Define factories with minimal associations and add traits for specific scenarios.

VCR

A gem that records HTTP interactions during tests and replays them on subsequent runs. VCR is essential for testing code that calls external APIs without hitting those APIs on every test run. The cassettes (recorded responses) are stored as YAML or JSON files. The gotcha: cassettes go stale. If the external API changes its response format, your tests still pass against the old recording. Periodically delete cassettes and re-record to catch drift.

Deployment

The tools that get your code from your machine to your servers. For the full deployment picture, see the Rails Deployment topic and Deploy Ruby on Rails on a VPS.

Kamal

A deployment tool from 37signals that deploys Docker containers to bare servers over SSH. Kamal handles building your image, pushing to a registry, pulling on the target server, running health checks, draining connections and rolling over to the new version. It's the default deployment tool for Rails 8 and represents a clear opinion: you own your servers, you deploy containers, you don't need Kubernetes. The learning curve is modest if you already understand Docker and SSH.

Capistrano

A remote server automation and deployment tool that's been the Rails deployment standard for over a decade. Capistrano connects to servers via SSH and runs a sequence of tasks: checkout code, install dependencies, compile assets, run migrations, restart the app server. It's battle-tested and well-documented. The downside is complexity — Capistrano configurations accumulate custom tasks and conditionals over time, and debugging a failed deploy means reading through task execution logs.

Docker

A containerization platform that packages your application, runtime and dependencies into an image that runs identically everywhere. For Rails, Docker means your development environment, CI and production all run the same Ruby version, system libraries and gem versions. The trade-off is image build times, image size management (multi-stage builds help) and an additional layer of abstraction to debug through when things go wrong.

Nginx

A high-performance HTTP server and reverse proxy. In a Rails deployment, Nginx typically sits in front of Puma, handling SSL termination, static file serving, request buffering and connection management. Nginx configuration is powerful but terse — a small syntax error can cause silent failures. I cover Rails-specific configuration in detail in Nginx for Rails Apps.

Puma

The default application server for Rails. Puma handles incoming HTTP requests, manages a pool of worker processes and threads, and passes requests to your Rails application. Configuration decisions — how many workers, how many threads, preload vs. on-demand — have direct performance implications. Getting Puma right for your workload is one of the most impactful infrastructure decisions you'll make. See Web Performance for Rails Developers for tuning guidance.

Monitoring

You can't fix what you can't see. These tools give you visibility into what's happening in production.

Skylight

An application performance monitoring (APM) tool built specifically for Rails. Skylight instruments your application at the request level, showing you where time is spent across controller actions, database queries, view rendering and external calls. Its UI is focused and opinionated, which makes it easier to learn than more general-purpose APM tools. The main limitation is that it's Rails-specific — if you have non-Rails Ruby services, you'll need something else for those.

Scout APM

Another Rails-focused APM tool that provides request-level tracing, N+1 detection and memory bloat tracking. Scout's GitHub integration links performance data to specific commits, which is useful for identifying which deploy caused a regression. It covers similar ground to Skylight with a different UI philosophy — Scout surfaces more raw data, Skylight is more curated.

rack-mini-profiler

A middleware-level profiler that displays a small badge on every page showing render time, SQL queries and their individual timings. rack-mini-profiler runs in development by default and can be enabled in production for specific users (e.g., admins). It's the quickest way to spot N+1 queries, slow partials and unnecessary database hits. I consider it essential for any Rails development workflow. See Web Performance for Rails Developers for how it fits into a broader performance practice.

Datadog

A general-purpose infrastructure and application monitoring platform. Datadog collects metrics from servers, containers, databases and applications, and provides dashboards, alerting and distributed tracing. It's significantly more complex (and more expensive) than Rails-specific tools like Skylight. I'd reach for Datadog when you have multiple services, non-Rails components or infrastructure-level monitoring needs that outgrow a Rails-only APM tool.

Debugging

When something is wrong and you need to understand why. For a structured approach, see Debugging Production Rails Issues and the Debugging and Maintenance topic.

debug gem

The official debugging gem shipped with Ruby 3.1+. It provides breakpoints, step execution, variable inspection and a REPL at the point of execution. Unlike binding.pry, the debug gem supports remote debugging — you can attach to a running process over a socket. This makes it usable in contexts where Pry isn't practical, like debugging a background job worker or a containerized process.

byebug

A debugger for Ruby that predates the debug gem. Byebug provides step-through debugging, breakpoints and variable inspection. It was the de facto standard debugger for Ruby 2.x applications. If you're on Ruby 3.1+, the built-in debug gem has largely superseded byebug, but you'll still encounter byebug in older projects.

better_errors

A gem that replaces Rails' default error page with an interactive console at the point of failure. When an exception occurs in development, better_errors shows the full stack trace, local variables at each frame and a live REPL where you can inspect state. Pair it with the binding_of_caller gem for full frame inspection. Never enable this in production — it exposes application internals.

Bullet

A gem that detects N+1 queries and unused eager loading during development and test runs. Bullet watches your ActiveRecord queries and alerts you (via browser notifications, log entries or test failures) when it spots inefficient query patterns. It's a passive tool — add it to your Gemfile, configure the notification method and let it run in the background as you develop.

Background Jobs

Processing work outside the request cycle. For patterns and trade-offs, see Sidekiq Background Jobs Patterns.

Sidekiq

A Redis-backed background job processor that uses threads for concurrency. Sidekiq is fast, mature and handles high throughput well. The free version covers most use cases; the commercial Pro and Enterprise tiers add reliability features like unique jobs, rate limiting and batch processing. The main operational dependency is Redis — if Redis goes down, your job queue goes down.

GoodJob

A background job processor that uses your PostgreSQL database as the queue backend. GoodJob stores jobs in a database table, eliminating the need for Redis as a separate infrastructure dependency. It supports cron-style scheduling, concurrency controls and dashboard monitoring. The trade-off is that your database takes on additional write load from job enqueuing and dequeuing. For applications that already depend on PostgreSQL and want fewer moving parts, GoodJob is a compelling choice.

Solid Queue

A database-backed job queue introduced by 37signals and integrated as the default Active Job backend in Rails 8. Solid Queue uses your existing database (PostgreSQL, MySQL or SQLite) for queue storage. It supports recurring jobs, concurrency controls and mission-critical features like pausing queues. If you're on Rails 8 and prefer to minimize external dependencies, Solid Queue is the natural starting point before reaching for Sidekiq or GoodJob.

This reference reflects my current working toolkit. Tools change, ecosystems shift and what's best today won't necessarily be best in two years. I'll update this page as my recommendations evolve. If you have a question about a specific tool or want to suggest an addition, the contact page is open.