Building enterprise Rails applications means picking gems that will not collapse under real production load. This is not a “top 10 list” pulled from GitHub stars. These are gems we deploy in production across client projects, with notes on what actually works, what we replaced, and where the documentation lies to you.
Search: Ransack for Complex Filtering
Ransack (v4.2+) generates complex search forms from ActiveRecord models without writing raw SQL. It handles sorting, multi-condition filtering, and nested associations out of the box. The catch: Ransack predicates can expose your entire model surface area if you skip ransackable_attributes whitelisting. Always define explicit allowlists in your models.
Authentication: Devise Still Wins (With Caveats)
Devise 4.9+ remains the default for Rails authentication, and for good reason: it handles registration, password recovery, session management, account locking, and OmniAuth integration through a modular architecture. Each module (:database_authenticatable, :recoverable, :trackable, etc.) can be toggled independently.
I18n support is solid. The devise-i18n gem ships with 60+ locale files. For multilingual apps (German, French, Italian, English), you get translated views, flash messages, and mailer templates without manual work.
The downside: Devise’s generator-heavy approach creates a lot of code you need to understand but did not write. Debugging authentication flows means reading through Warden middleware, which is not intuitive. For API-only apps, consider devise-jwt or skip Devise entirely in favor of a lightweight token solution.
Authorization: Pundit vs. CanCanCan
Pundit: Policy Objects That Scale
Pundit 2.4+ uses plain Ruby policy classes. Each model gets a corresponding policy file defining create?, update?, destroy? methods. The authorize call in controllers raises Pundit::NotAuthorizedError on violations. policy_scope filters collections so users only see permitted records.
Key strengths:
- Each policy is a standalone class, testable with plain RSpec
permitted_attributesprevents mass assignment vulnerabilities- No DSL to learn, just Ruby methods returning booleans
- Scales linearly: 50 models means 50 small policy files
CanCanCan: Centralized but Risky at Scale
CanCanCan 3.6+ centralizes all permissions in a single Ability class. The load_and_authorize_resource macro combines resource loading and authorization. accessible_by generates scoped queries for index actions.
The be_able_to RSpec matcher makes testing readable. But the centralized model is also its biggest weakness: in complex apps, ability.rb grows into a 500+ line monster mixing concerns from every domain.
| Aspect | Pundit 2.4 | CanCanCan 3.6 |
|---|---|---|
| Architecture | Distributed policy classes | Single Ability class |
| Learning curve | Low (plain Ruby) | Low (DSL) |
| Testability | Standard unit tests | be_able_to matcher |
| Scaling past 30 models | Clean | Painful |
| Mass assignment protection | Built-in | Manual |
Background Jobs: Sidekiq’s Throughput Advantage
Sidekiq 7.3+ uses threads instead of processes, giving it roughly 10-25x throughput over Delayed Job on equivalent hardware. A single Sidekiq process with 25 threads can handle 5,000-8,000 simple jobs/second on a 2-core machine. Compare that to Delayed Job’s ~200-400 jobs/second with the same resources.
Key production features:
- Priority queues:
critical,default,lowwith weighted processing - Retry with exponential backoff: failed jobs retry up to 25 times over ~21 days
- Dead job queue: jobs exceeding retry limits land here for manual inspection
- Web UI: real-time dashboard for queue depth, latency, and failure rates
- Redis SSL/TLS: encrypted connections for data in transit
The trade-off is Redis as a hard dependency. Budget ~128MB RAM for Redis per 1M enqueued jobs. For Sidekiq Pro/Enterprise, batch jobs and rate limiting add significant value, but the license starts at $980/year.
Admin Panels: ActiveAdmin for Internal Tools
ActiveAdmin 3.2+ generates CRUD admin interfaces from ActiveRecord models with minimal code. A basic resource registration (ActiveAdmin.register Post) gives you index, show, edit, and delete views with filtering and pagination.
It integrates Devise for authentication by default. For authorization, plug in Pundit or CanCanCan via the active_admin_pundit_adapter or built-in CanCanCan support.
Limitations: ActiveAdmin’s Arbre DSL fights you when you need custom UI. For admin panels requiring heavy JavaScript interactivity, consider Avo or building a custom React/Hotwire admin. ActiveAdmin is best for straightforward data management interfaces where speed of delivery matters more than UI polish.
USEO’s Take: What We Actually Ship
After 8+ years building Rails apps for enterprise clients, here is what our production stacks actually look like:
We dropped CanCanCan for Pundit 3 years ago. The tipping point was a fintech project where ability.rb hit 600 lines with nested conditional blocks spanning 4 user roles. Refactoring to Pundit took 2 weeks, but the result was 40+ small policy files averaging 25 lines each. Every new developer onboards faster because policies live next to the models they protect.
Sidekiq Enterprise pays for itself in month one. On a project processing 2M+ background jobs/day (PDF generation, webhook delivery, report compilation), Sidekiq Enterprise’s rate limiting and batch callbacks saved us from building custom orchestration. The $980/year license is noise compared to the engineering hours it saves.
We never use Bullet in production. It is a development/test tool only. Enabling it in production adds measurable overhead to every ActiveRecord query. Our setup: Bullet in development and test environments, with bullet.raise = true in test to fail the CI build on N+1 regressions. This catches 95% of issues before they reach staging.
ActiveAdmin is our “80% solution.” For internal dashboards and back-office tools, ActiveAdmin ships in days. But we have migrated two projects away from it when clients needed complex multi-step workflows in the admin. The Arbre DSL becomes a bottleneck once you need custom JavaScript behavior beyond simple filters.
Pagy over Kaminari, every time. We benchmarked both on a table with 2M rows. Kaminari’s COUNT(*) query added 80-120ms per page load. Pagy’s countless mode skips the count entirely, dropping pagination overhead to under 5ms. For API endpoints serving mobile apps, this difference is visible in user experience metrics.
Money-Rails with a gotcha: always set config.default_currency = :CHF in the initializer and store amounts as integer cents in the database. We had a production incident where a developer used decimal columns instead of integer, leading to 0.01 CHF rounding errors on aggregated invoices totaling CHF 340K+. Integer storage with Money-Rails eliminated the class of bug entirely.
Pagination: Kaminari vs. Pagy
Kaminari: Feature-Rich, Heavier
Kaminari 1.2+ integrates deeply with ActiveRecord, Mongoid, and array-based collections. Its I18n-aware helpers (paginate, page_entries_info) support locale-specific labels out of the box. The pagination approach is conventional and well-documented.
The kaminari-i18n gem provides pre-built translations for 40+ locales. Custom locale files (e.g., de-CH.yml) override defaults easily.
The cost: Kaminari executes a COUNT(*) query on every paginated request. On tables exceeding 500K rows without a covering index, this adds 50-200ms latency.
Pagy: Minimal Overhead, More Configuration
Pagy 9.x has zero dependencies and allocates ~40x less memory than Kaminari per request (measured by the Pagy team’s benchmarks). Its countless extra skips the count query entirely, using LIMIT + 1 to detect if a next page exists.
| Metric | Kaminari 1.2 | Pagy 9.x |
|---|---|---|
| Memory per request | ~1,400 bytes | ~40 bytes |
| COUNT query | Always | Optional (countless) |
| Dependencies | 3 | 0 |
| I18n support | Built-in + gem | Built-in |
| Best for | Feature-rich apps | High-traffic APIs |
For high-performance pagination, Pagy is the clear winner. For apps where developer convenience matters more than microseconds, Kaminari works fine.
Security Scanning: Brakeman in CI
Brakeman 7.1+ performs static analysis on Rails code without executing it. It detects SQL injection, XSS, command injection, unsafe redirects, mass assignment, and dangerous eval() usage. No runtime dependency, no test suite required.
CI integration is where Brakeman earns its keep. Add brakeman --no-pager -q to your CI pipeline. New warnings break the build. Teams we work with typically see 15-30 warnings on first run in legacy codebases, dropping to 0-2 after a focused remediation sprint.
Brakeman 7.1.0 improved scan performance for large apps. A 200-controller Rails app scans in ~8 seconds on modern hardware. For very large monoliths (500+ models), consider --only flags to scan specific check types per pipeline stage.
False positive rate: expect 5-15% false positives depending on codebase style. Use brakeman.ignore to suppress confirmed false positives with documented justification.
N+1 Detection: Bullet in Development
Bullet 8.x monitors ActiveRecord queries in real time and alerts on:
- N+1 queries: missing
includes/preload/eager_load - Unused eager loading:
includesthat load associations never accessed - Counter cache candidates: associations where
sizetriggers a COUNT query
Configuration for CI enforcement:
# config/environments/test.rb
config.after_initialize do
Bullet.enable = true
Bullet.raise = true # fail tests on N+1
endThis single setting has prevented more performance regressions in our projects than any monitoring tool. Every N+1 query caught in test is one fewer slow endpoint in production.
Request Throttling: Rack::Attack
Rack::Attack 6.7+ operates as Rack middleware, intercepting requests before they hit your Rails app. Core features:
- Throttle: limit requests per IP/key per time window (e.g., 60 req/min for API endpoints)
- Blocklist: reject requests matching specific patterns (known bad IPs, suspicious user agents)
- Safelist: always allow trusted IPs (office, monitoring services)
- Track: log matching requests without blocking for analysis
# config/initializers/rack_attack.rb
Rack::Attack.throttle("api/ip", limit: 60, period: 1.minute) do |req|
req.ip if req.path.start_with?("/api/")
endCritical warning: misconfigured throttle rules will silently block legitimate users. Always implement Rack::Attack.track first to observe traffic patterns before enabling throttle or blocklist in production. Monitor 429 response rates after deployment.
Financial Precision: Money-Rails
Money-Rails 1.15+ wraps the money gem for ActiveRecord integration. It stores monetary values as integers (cents) and handles currency conversion, formatting, and arithmetic without floating-point errors.
Key configuration for CHF:
# config/initializers/money.rb
MoneyRails.configure do |config|
config.default_currency = :CHF
config.rounding_mode = BigDecimal::ROUND_HALF_UP
endCHF formatting follows the 1'234.50 convention automatically. Multi-currency support handles EUR, USD, and GBP conversions using exchange rate stores (Open Exchange Rates, EU Central Bank).
Why integer storage matters: 10.2 + 10.1 in floating-point Ruby returns 20.299999999999997. Money-Rails stores 1020 + 1010 = 2030 cents and formats on output. This eliminates an entire class of rounding bugs in financial calculations, which is non-negotiable for applications handling transactions under FADP/GDPR compliance requirements.
Choosing the Right Gem for Each Layer
| Layer | Recommended | Alternative | When to Switch |
|---|---|---|---|
| Authentication | Devise 4.9 | Rodauth | API-only apps, tighter security model |
| Authorization | Pundit 2.4 | Action Policy | 50+ policies, need caching |
| Background jobs | Sidekiq 7.3 | GoodJob | Cannot run Redis in your infrastructure |
| Admin | ActiveAdmin 3.2 | Avo, Trestle | Need custom JS-heavy UI |
| Pagination | Pagy 9.x | Kaminari 1.2 | Need out-of-box I18n templates |
| Security scan | Brakeman 7.1 | Bearer | Need API-specific scanning |
| N+1 detection | Bullet 8.x | Prosopite | Bullet’s monkey-patching conflicts |
| Rate limiting | Rack::Attack 6.7 | Custom middleware | Very specific throttle logic |
| Currency | Money-Rails 1.15 | Custom + BigDecimal | Single-currency, simple math |
The pattern across all these choices: pick the gem that solves your current problem with the least abstraction. Over-abstracting authorization or pagination creates maintenance debt that compounds over years. Start simple, measure, and switch only when you hit a documented wall.
FAQs
When should I pick Pundit over CanCanCan?
Pick Pundit when your app has more than 15-20 models with distinct access rules. Pundit’s distributed policy files keep each authorization concern isolated and testable. CanCanCan’s single Ability class works fine for small apps but becomes a merge-conflict magnet on teams with 3+ developers touching permissions simultaneously.
How do I handle CHF formatting correctly in Money-Rails?
Set config.default_currency = :CHF in the initializer. Store all amounts as integer cents in the database (use add_monetize :price_cents migration helper). Money-Rails formats output as CHF 1’234.50 automatically. Never use decimal or float columns for monetary values.
How do I ensure compliance with FADP when using these gems?
The Swiss Federal Act on Data Protection (FADP) shares core principles with GDPR: data minimization, encryption at rest and in transit, audit logging, and explicit user consent. For gems handling user data (Devise, Sidekiq with PII in job arguments), ensure you configure encryption (Redis TLS for Sidekiq, attr_encrypted for sensitive Devise fields) and implement data retention policies. Brakeman catches common vulnerability patterns, but compliance requires architectural decisions beyond gem configuration.