Ruby on Rails 8.0: What's New, Release History & Support Lifecycle

Does Rails 8.0 Replace Redis and Sidekiq with Database-Backed Alternatives?

Yes -- Rails 8.0 ships three new "Solid" adapters that let you drop Redis, Memcached, and most background job frameworks in favour of your existing relational database. This is the headline story of this release and it represents a deliberate philosophy shift: fewer moving parts, simpler production stacks, and SQLite-friendly architecture for apps that don't need the throughput of a dedicated in-memory store.

The three adapters and what they replace:

• Solid Cable -- replaces Redis as the Action Cable pubsub backend. Messages are retained in the database for 24 hours by default, which also gives you built-in message replay.
• Solid Cache -- replaces Redis or Memcached for HTML fragment caching. Fragment caches now live in your database, with no external service required.
• Solid Queue -- replaces Sidekiq, Resque, and Delayed Job for background job processing. On PostgreSQL 9.5+ and MySQL 8.0+, it uses the FOR UPDATE SKIP LOCKED mechanism for contention-free queue polling. SQLite is also fully supported.

In practice, smaller and mid-sized applications will see a real reduction in infrastructure complexity. For high-traffic apps already running Redis clusters, the trade-off deserves benchmarking before migrating. Watch out for write amplification if your cache hit rate is low -- every miss still writes to the database.

# config/environments/production.rb

# Switch to Solid Cache
config.cache_store = :solid_cache_store

# Switch to Solid Queue
config.active_job.queue_adapter = :solid_queue

# Solid Cable is configured in config/cable.yml
# adapter: solid_cable

What Is the New Rails 8.0 Authentication Generator and What Does It Produce?

Rails 8.0 ships a first-party authentication generator that scaffolds a complete, session-based authentication system without any gem dependency. Run bin/rails generate authentication and you get a fully functional starting point with password reset flows, session management, and metadata tracking (IP address, user agent) baked in.

This matters if your team has historically reached for Devise on every new project by reflex. The generated code is plain Rails -- no engine, no configuration DSL, nothing opaque. It is designed to be read, understood, and modified. You own the code from day one.

Most teams will want to review the generated migrations and model callbacks carefully before going to production. The generator provides a solid security baseline -- bcrypt passwords, secure session tokens, and reset token expiry -- but customizations like OAuth, two-factor authentication, or account lockout still require your own implementation on top of it.

# Generate the authentication scaffold
bin/rails generate authentication

# This creates:
# app/models/user.rb
# app/models/session.rb
# app/controllers/sessions_controller.rb
# app/controllers/passwords_controller.rb
# app/mailers/passwords_mailer.rb
# db/migrate/..._create_users.rb
# db/migrate/..._create_sessions.rb

How Does Rails 8.0 Change Deployment with Kamal 2 and Thruster?

Rails 8.0 ships with Kamal 2 preconfigured in new applications, making zero-dependency container deployment a first-class part of the framework for the first time. A single kamal setup command provisions a fresh Linux server, builds your Docker image, pushes it to a registry, and starts the application with TLS handled automatically.

Kamal 2 also replaces Traefik with its own proxy called Kamal Proxy, which is lighter, purpose-built for Rails deployments, and requires no external configuration files. Alongside this, the default Rails Dockerfile now includes Thruster -- a small Go proxy that sits in front of Puma and handles X-Sendfile acceleration, asset compression (gzip/brotli), and asset caching at the HTTP layer, offloading work that would otherwise hit the Ruby process.

In practice, this means a brand-new Rails 8 app can go from rails new to production on a $6/month VPS with almost no infrastructure configuration. Teams that already have established CI/CD pipelines and container orchestration can continue using them -- Kamal is opt-in, not mandatory.

What Breaking Changes and Removals Should You Know Before Upgrading to Rails 8.0?

Rails 8.0 finalizes the removal of a large batch of APIs that were deprecated in 7.x. Most of these are Active Record configuration keys, but several touch other parts of the stack. The upgrade guide from 7.2 to 8.0 is the authoritative source, but here are the removals most likely to affect real applications:

• Active Record: config.active_record.commit_transaction_on_non_local_return, config.active_record.allow_deprecated_singular_associations_name, config.active_record.warn_on_records_fetched_greater_than, and keyword-argument-style enum definitions are all gone.
• Action Pack: config.action_controller.allow_deprecated_parameters_hash_equality is removed. Routes defined with multiple paths on a single call are now deprecated -- expect warnings and a future removal.
• Active Job: config.active_job.use_big_decimal_serializer is removed.
• Active Support: ActiveSupport::ProxyObject is gone, along with the @-prefix format for attr_internal_naming_format.
• Asset Pipeline: Propshaft is now the default. Applications that still depend on Sprockets-specific features (ERB preprocessing in assets, Sass via sprockets-rails) will need to keep the Sprockets gem explicitly or migrate their assets.
• db:migrate behaviour: On a fresh database, db:migrate now loads schema.rb or structure.sql first and then runs only pending migrations. Use db:migrate:reset if you need the old behaviour of replaying every migration from scratch.

Watch out for the Active Storage Azure deprecation -- if you use the Azure backend, plan your migration path to a supported adapter now since removal is coming in a future version.

What Security and Parameter Handling Improvements Come with Rails 8.0?

Rails 8.0 introduces two security-oriented changes that affect day-to-day controller code and server-side regex processing. Together they close real attack surfaces without requiring significant application changes.

Regexp timeout: Regexp.timeout is now set to 1 second globally by default. This is a direct defence against Regular Expression Denial of Service (ReDoS) attacks, where a malicious input string causes catastrophic backtracking in a regex and pegs a thread indefinitely. If your application uses complex regexes on user-provided input -- validation patterns, route constraints, search parsers -- test them under this timeout. Legitimate patterns should complete in microseconds; anything that takes longer is worth reviewing.

params#expect: A new, more explicit method for strong parameters replaces the params.require(:table).permit(:attr) pattern for many common cases. The new style is:

# Old style (still works, not deprecated)
params.require(:user).permit(:name, :email)

# New style with params#expect
params.expect(user: [:name, :email])

# For arrays of permitted hashes
params.expect(table: [[:attr]])

The expect method raises on unexpected types rather than silently coercing them, reducing a class of subtle bugs where a client sends an array where a scalar is expected (or vice versa). Most teams should adopt params#expect in new controllers and migrate existing ones incrementally.