The Best Rails Gems (2026)

The framework first

Most Rails apps have too many gems. Each one is a transitive dependency, a security surface, an upgrade burden, a place future-you will hesitate to debug. The senior reflex is to use Rails defaults aggressively and reach for a gem only when there is a concrete reason the framework alone does not handle.

With that lens, the list below is short. Each gem earned its spot because the senior teams running production Rails apps reach for it consistently, and the cost of writing the equivalent in-house outweighs the dependency cost. Gems that did not earn their spot are listed at the end with the reason most teams removed them.

The recommendations apply to Rails 8 in 2026. Older apps may have different rational defaults.

Authentication

Default: Rails 8's bin/rails generate authentication. Scaffolds users, sessions, password reset, and email confirmation in plain Rails code using has_secure_password. ~200 lines you own and can modify. Right for any app with standard email-password auth.

When you outgrow it: devise. Still the dominant choice when OAuth integrations, magic links, MFA, account locking, or unusual flows enter the picture. The plugin ecosystem is unmatched. Devise's reputation for complexity is fair, but every alternative has the same complexity if you actually need its features.

Niche alternative: rodauth-rails. A different architectural take: framework-agnostic auth with thoroughness Devise's plugins approximate. Adoption is small but growing. Worth a look if you found Devise's plugin model frustrating in a previous app.

Authorization

Default: pundit. Per-class policy objects. Tiny API, quick to test, plays well with Rails service objects. The pattern is unchanged across years of evolution. Most senior Rails apps either use Pundit or use the same pattern by hand.

For complex authorization (role-based or tenant-based): action_policy. Newer, more features (rules with arguments, namespaces, pre-checks). The right pick when authorization itself is non-trivial.

Mostly abandoned: cancancan. The Ability-class-with-everything pattern aged poorly. Apps that still use it usually inherited it; new apps almost never reach for it.

Background jobs

Default: solid_queue (Rails 8 built-in). Right for new apps under ~5,000 jobs/sec. Removes the Redis dependency. Detailed reasoning in Sidekiq vs Solid Queue.

Right for high throughput: sidekiq. Still the gold standard above ~5,000 jobs/sec, when ops teams have deep Redis experience, or when the Sidekiq Web UI's depth is load-bearing.

Companion for both: good_job. Database-backed like Solid Queue, but predates it and has its own ecosystem. Some teams stayed on it through the Rails 8 transition.

For management UI on Solid Queue: mission_control-jobs. 37signals's queue inspector. Production-ready in 2026.

Caching

Default: solid_cache (Rails 8 built-in). Postgres-backed cache that benchmarks competitively with Memcached. The easiest infrastructure simplification on the Rails 8 table. Adoption is wide.

If Solid Cache underperforms: redis (via redis-rails or direct). For extremely high cache traffic or when Redis is already in the stack for other reasons.

Forms

Default: Rails 7+ native form helpers. form_with plus partials covers most cases cleanly. With Tailwind, the styling story is fine.

When forms are the product: simple_form. Still used in apps where forms appear constantly and consistency matters. The DSL is concise. Active maintenance.

Mostly removed: formtastic. Older syntax, dwindling community, no compelling advantage over simple_form or native helpers in 2026.

Admin interfaces

For most teams: avo. Modern, well-maintained, Hotwire-native, paid pro tier. The right pick for a team that wants admin shipped this week without configuring forty things.

Open-source alternative: administrate. Thoughtbot's take. Lighter weight, more code in your repo, slower to iterate. Good if you want full control of the admin views.

The DIY pattern. Many senior teams skip admin gems entirely: they ship internal pages as ordinary Rails resources with a basic authorization scope. Less magic, more control. Sustainable if the admin surface is small.

Mostly abandoned: rails_admin and activeadmin. Both still ship, both still get used in mature apps. New apps in 2026 rarely pick them.

Testing

The split: Minitest vs RSpec. Minitest is Rails default; RSpec dominates open source and many large companies. Both work. The senior position is "use what your team already knows; do not migrate without a clear reason." New apps in 2026 increasingly default to Minitest because Rails 8 polished the integration.

System tests: built into Rails. Capybara + Selenium are bundled. For most teams this is enough. Add webdrivers if you need browser automation that survives Chrome updates.

Factories: factory_bot. Still dominant. Fixtures get used in performance-sensitive test suites but lose the readability war.

For HTTP stubs: webmock or vcr. WebMock for fine-grained stubs; VCR for recording real responses to disk. Most teams use both.

Code quality and security

rubocop + rubocop-rails + rubocop-rspec. Universal. Configure to match the team's actual taste, not the defaults.

brakeman. Static security scanner. Runs in CI on every PR for security-critical apps.

strong_migrations. Blocks unsafe migrations in development before they hit production. Detailed reasoning in Zero-Downtime Rails Migrations. Recommended for any app deploying to a production with real data.

bundler-audit. Checks Gemfile.lock against the vulnerability database. Add to CI.

Observability

lograge. Replaces Rails's noisy multi-line log output with one line per request. Still essential for any app shipping logs to an external service. Pair with structured-JSON output if you ship to Datadog, Honeycomb, or similar.

prometheus_exporter or platform-native instrumentation. If you run on Render, Fly, or similar, use their built-in metrics. For self-hosted Kamal deploys, Prometheus + Grafana is the open-source path.

Application performance monitoring: AppSignal, Datadog, Honeybadger, Skylight, or Scout. All work. Pick by pricing and team familiarity. AppSignal is the Rails-niche default.

sentry-ruby. Default error reporter for most Rails apps. Honeybadger and Rollbar are competing alternatives with similar features.

JSON API rendering

alba or panko_serializer for performance. Both significantly faster than jbuilder for large payloads. Alba has the cleaner DSL; Panko is the speed king.

jbuilder for simple cases. Built into Rails. Fine for small payloads. Pay the migration cost only when serialization is a measured bottleneck.

Mostly abandoned: active_model_serializers. Long unmaintained. Apps still using it should plan a migration to alba or panko when convenient.

Frontend tooling

turbo-rails + stimulus-rails. Rails 8 defaults. Covers most Rails frontends.

view_component. GitHub's component framework. Useful in apps with significant view reuse. Pair with Lookbook for design-system visibility.

tailwindcss-rails or cssbundling-rails. Tailwind has won as the default styling approach in the Rails community.

inertia-rails for SPA-style apps. The middle-ground option covered in Hotwire vs Inertia vs React.

Gems most teams removed

Five categories where senior teams quietly dropped the gem and lived with native Rails or wrote a few lines themselves.

• State machines. aasm and state_machines add complexity that a hand-rolled state column with validation often handles cleaner. Most apps that started with state-machine gems eventually removed them.
• Pagination. kaminari and will_paginate still work, but for apps that grew past offset pagination (see Pagination at Scale), the gem becomes a constraint and is replaced by cursor-based logic.
• Soft delete. paranoia and discard get added early and removed later. A deleted_at column plus a default scope and a few model methods is usually enough.
• Settings / configuration gems. rails-settings-cached and similar. Most teams that use them eventually replace with explicit config classes or feature flags.
• API documentation auto-gen. rswag, apipie-rails. Maintenance burden usually outweighs the auto-generated docs. Teams revert to writing OpenAPI by hand or using Postman.

The pattern: each of these solves a problem in a way that feels like help at first and becomes a constraint at scale. The senior heuristic is to add gems for problems that are genuinely hard (auth, background jobs, observability) and write code for problems that are only verbose (state, pagination, soft delete).

The principle at play

Every gem is a debt. Maintainable for now, frozen later, deprecated eventually, plus a security review on every CVE. The teams that move fastest are the ones who use gems for the load-bearing parts of an app (auth, async work, persistence) and write the rest themselves. The teams that move slowest are the ones whose Gemfile is 80 lines long and whose bundle update is a six-hour event.

The 2026 default is shorter than the 2020 default. Rails 8 absorbed several common gem categories (auth, queue, cache, deploy) into the framework itself. The senior reflex is to use what the framework offers, and to add gems only when the framework's option does not fit the actual problem.