7 Must-Have Ruby on Rails Gems

The seven Ruby on Rails gems we reach for on almost every project are Bundler, RuboCop, Bullet, bundler-audit, Brakeman, Devise and Sidekiq. Together they cover dependency management, code quality, database performance, security and the two features nearly every web app needs: user authentication and background jobs.

Since we first published this list, Rails has caught up: new Rails 8.1 apps already ship with four of the seven, and Rails 8 offers built-in alternatives to the other two.

This guide explains what each gem does, how to set it up, and when the default Rails option is the better call. It's based on our team's experience delivering over 100 Ruby on Rails projects.

What is a Ruby on Rails gem?

A Ruby on Rails gem is a packaged Ruby library you add to an application so you don't have to write common functionality, like authentication or job processing, from scratch. Gems are published on RubyGems.org, which hosts over 198,000 of them as of November 2026.

You don't need to install anything extra to use them. Ruby ships with RubyGems, the package manager, and with Bundler, which installs the exact gem versions your project lists in its Gemfile. In a Rails project you add a gem to the Gemfile and run bundle install instead of installing gems one by one with gem install.

Which Ruby on Rails gems should every project use in 2026?

These are the seven we add, or keep, in almost every Rails app. Download counts come from RubyGems.org and GitHub stars from each project's repository, both checked in November 2026.

Bundler

Bundler gives every developer and server the same set of gems at the same versions. You list dependencies in a Gemfile, and Bundler resolves them and records the exact versions in Gemfile.lock:

# Gemfile
source "https://rubygems.org"

gem "rails", "~> 8.1"
gem "devise"

group :development do
  gem "bullet"
end

Running bundle install installs everything in one go. Bundler 4.0 was released together with RubyGems 4.0 in December 2025, and its code now lives in the ruby/rubygems repository. Commit Gemfile.lock for applications, so production runs the versions you tested.

RuboCop

RuboCop is a linter and formatter that checks Ruby code against the community Ruby Style Guide or your own rules. On a team, it ends style debates in code review, because the rules live in .rubocop.yml and the tool enforces them.

New Rails apps since Rails 7.2 come with RuboCop configured through rubocop-rails-omakase, a deliberately small rule set. Run it with bin/rubocop, and add -a to autocorrect safe offenses. On an older codebase, generate a .rubocop_todo.yml with rubocop --auto-gen-config so you can switch it on without fixing thousands of offenses in one pull request.

Bullet

Bullet watches your queries in development and tells you when to add eager loading to fix an N+1 query, when existing eager loading is unnecessary, and when a counter cache would help. N+1 queries rarely show up with seed data, but they slow pages down badly once tables grow, which makes Bullet one of the cheapest performance tools you can add.

Add it to the development group, then run the generator, which writes the default configuration into config/environments/development.rb:

bundle add bullet --group development
bin/rails g bullet:install

Rails' built-in strict_loading mode can raise an error on lazy-loaded associations, and some teams use it instead. Bullet is the gentler option for an existing app, because it warns rather than breaking pages. See the Bullet documentation for the logging and notification options.

bundler-audit

bundler-audit compares your Gemfile.lock against the Ruby Advisory Database and reports gems with known vulnerabilities. It also flags insecure gem sources (http:// and git://) and lets you ignore advisories you've already mitigated.

Rails 8.1 adds it to the Gemfile of new apps, with a bin/bundler-audit script and a config/bundler-audit.yml file for ignored advisories. On an older app, install it and run:

bundle-audit check --update

The --update flag refreshes the advisory database first. Without it, you are checking against whatever was downloaded last time.

Brakeman

Brakeman is a static analysis tool that scans Rails source code for security issues such as SQL injection, cross-site scripting and unsafe redirects. Because it reads code rather than attacking a running server, it needs no configuration and can run on every commit. The OWASP Ruby on Rails Cheat Sheet recommends it.

Brakeman has two limits. It errs on the side of caution, so expect false positives that someone who knows the code has to triage. And it can't see problems outside the code, like web server or database misconfiguration, so it doesn't replace dynamic scanning or a penetration test. New Rails apps include it by default; run it with bin/brakeman.

Devise

Devise is the most widely used authentication gem for Rails. Out of the box it handles registration, login, password recovery, email confirmation, account locking after failed attempts and session timeouts, and it integrates with OmniAuth for social and single sign-on login. Devise 5.0, released in January 2026, supports Rails 7.0 and later.

Since Rails 8, bin/rails generate authentication creates a simpler, session-based login with password resets as plain code inside your app. It doesn't include sign-up, so you build that yourself. We cover both options in more detail in our guide to authentication and authorization in Ruby on Rails.

Sidekiq

Sidekiq runs background jobs, like sending emails, processing payments or generating reports, outside the request cycle. It uses threads to process many jobs at once and stores its queues in Redis, which keeps it fast under heavy load. Sidekiq 8 requires Ruby 3.2+, Rails 7.0+ and Redis 7.0+ (or Valkey 7.2+ or DragonflyDB 1.27+).

Add gem "sidekiq" to the Gemfile, then generate a job:

bin/rails generate sidekiq:job generate_report

That creates app/sidekiq/generate_report_job.rb and a matching test file:

class GenerateReportJob
  include Sidekiq::Job

  def perform(account_id, period)
    # report generation code goes here
  end
end

Job arguments must be simple JSON types (strings, integers, booleans, arrays and hashes of those), so pass a record's ID rather than the record itself. Enqueue jobs with perform_async, perform_in or perform_at, for example GenerateReportJob.perform_async(42, "2026-10"), and start the worker with bundle exec sidekiq.

Which gems does Rails 8 already include or replace?

Rails 8 now covers part of what these gems do. For new apps, that means less setup. For existing apps, it's a chance to drop a dependency, though not always a reason to.

Which security and style tools come with a new Rails app?

Rails 7.2 added Brakeman, RuboCop and a GitHub Actions CI workflow to new apps, and the Rails 8.1 app template adds bundler-audit. Rails 8.1 also introduced a local CI file, config/ci.rb, run with bin/ci, which chains RuboCop, bundler-audit, Brakeman and your tests. If you're upgrading an older app, adding these is a quick win.

Should you use Solid Queue or Sidekiq for background jobs?

The Rails guides call Solid Queue the default queue backend from Rails 8.0 onward. It stores jobs in your existing database, so you don't run or pay for Redis. That's the right starting point for most new apps. Sidekiq still earns its place when job volume is high, latency matters, or you already run Redis and rely on Sidekiq's dashboard, batching or the paid Pro and Enterprise features. Migrating a working Sidekiq setup to Solid Queue only to follow the default rarely pays off.

Should you use the Rails 8 authentication generator or Devise?

The Rails 8 generator gives you code you own and can read in an afternoon, which suits apps with simple email-and-password login. Devise is the better fit when you need confirmable accounts, lockouts, OmniAuth or multiple user models, since you'd otherwise rebuild those features yourself and maintain them.

How do you choose and maintain gems in a Rails project?

Every gem you add is code you'll have to upgrade, secure and eventually maybe replace, so treat each one as a long-term dependency rather than a shortcut. Before adding a gem, check three things:

1. Is it maintained? Look at the dates of the last release and commit, the open issues and whether it supports your Rails and Ruby versions. An abandoned gem can block your next Rails upgrade.

2. Is the problem big enough? If a gem saves you twenty lines of code, write the twenty lines. Gems pay off for problems that are hard to get right, like authentication, background processing or security scanning.

3. Is it documented, tested and clean on security? Check the README, the test suite and the gem's past advisories in the Ruby Advisory Database.

Once a gem is in, automate the upkeep. Run bundler-audit and Brakeman on every pull request in CI, and turn on Dependabot or a similar tool so update pull requests arrive in small batches. Small, regular updates are far cheaper than a year of skipped versions landing during a Rails upgrade.

How should you build your Rails gem stack?

Start from what Rails 8 gives you, then add gems only where they solve a real problem: Bullet for query performance, Devise when authentication goes beyond the basics, and Sidekiq when job volume or existing infrastructure justifies Redis. Keep the security tools running in CI and your dependency list short and current, and Rails upgrades stay manageable. If you're weighing these trade-offs on a large or aging Rails codebase, our Ruby on Rails team, which has worked on the Seat Unique ticketing platform for eight years, can help you review your stack and plan the upgrade.