Upgrade to Rails 8

Rails 8 is a recommended upgrade for apps already on Rails 7. Most work is in adopting the new defaults — Solid Queue/Cache/Cable, Propshaft, Kamal 2 — and walking config.load_defaults to 8.0. Budget one to five days depending on your asset pipeline and deploy setup, and treat it as high-risk because it touches the database and infrastructure.

Who should upgrade

• Apps on Rails 7 wanting to drop Redis for the database-backed Solid adapters.
• Teams adopting Kamal 2 for container deploys or Thruster for asset acceleration.
• Apps on Rails 6 should first reach Rails 7, then 8 — never skip a major.

Who should wait

• Apps with a critical gem that has no Rails 8-compatible release yet.
• Apps mid-migration off Webpacker that should finish that move on Rails 7 first.

What changed

• Solid Queue, Solid Cache, and Solid Cable: database-backed adapters that replace Redis for jobs, caching, and Action Cable.
• Kamal 2 is the default deploy tooling, with Thruster fronting Puma for HTTP/2 and asset caching.
• Propshaft is the default asset pipeline, replacing Sprockets for new apps.
• A built-in authentication generator scaffolds sessions and password reset without a gem.
• SQLite is now production-ready for many workloads thanks to tuned defaults.

New in Rails 8.1 (current: 8.1.3)

• Active Job continuations: split long jobs into steps so they resume from the last completed step after a deploy or restart instead of starting over.
• Structured event reporting via a unified Event Reporter (Rails.event) for emitting structured application events.
• Local CI: a default CI DSL in config/ci.rb, run with bin/ci.
• Active Record associations can be marked deprecated (:warn, :raise, or :notify), and apps can render Markdown responses out of the box.
• Mostly additive over 8.0 — most apps advance config.load_defaults 8.1 after a clean app:update with little code change.

⛔ Rails upgrades touch the database and infrastructure

Unlike a frontend library bump, a Rails upgrade can change job, cache, and cable backends and may require migrations. Run it on a release branch against a copy of production data, and never run pending migrations without explicit sign-off.

Recommended upgrade path

Fast path for apps already on Rails 7

# 1. Bump the rails gem in the Gemfile, then:
bundle update rails

# 2. Run the interactive update task and review every config diff
bin/rails app:update

# 3. Boot + test before advancing defaults
bin/rails runner 'puts Rails.version' && bin/rails test

Advancing framework defaults

Flip new framework defaults deliberately

# config/application.rb — advance ONE minor at a time, only after the suite is green
module MyApp
  class Application < Rails::Application
    # was: config.load_defaults 7.2
    config.load_defaults 8.0
  end
end

Version support matrix

AI-assisted migration workflow

Upgrade this app to Rails 8. First inspect for blocking gems (bundle outdated), the current config.load_defaults value, and the asset pipeline in use. Then bump the rails gem, run `bundle update rails`, run `bin/rails app:update` and review each config diff, fix boot/autoload errors, and only after tests pass advance config.load_defaults to 8.0 and fix the deprecations it surfaces. Run `bin/rails test` after each step and report before continuing. Never run pending database migrations without confirmation.

Safety: Incremental edits only. Pause for review after app:update and before advancing config.load_defaults. Database migrations require explicit human sign-off.

PR review checklist

• rails and ruby versions are pinned and Gemfile.lock is committed
• Every bin/rails app:update config diff was reviewed, not blindly accepted
• config.load_defaults was advanced only after the suite went green
• Job, cache, and cable adapters are explicitly configured (Solid or existing)
• Pending database migrations are reviewed and reversible

Rollback strategy

• Keep the gem bump, app:update diffs, fixes, and the load_defaults change in separate commits.
• Revert the Gemfile to the prior rails version and run bundle install if a blocking incompatibility appears.
• Hold the upgrade behind a release branch until the full suite and a staging deploy are green.
• Back up the database before any migration so you can restore on rollback.

Common errors

• NameError/LoadError at boot — a file or constant name Zeitwerk rejects (carried over from the 7 upgrade).
• Jobs silently not processing after the queue adapter default changed — set the adapter explicitly.
• Asset 404s after the Propshaft switch — confirm the manifest and precompile step.

Related migration paths

• Modernize a Legacy Rails App — Earlier step in the upgrade chain
• Rails 6 to Rails 7 Migration Guide — Related version path
• Rails 7 to Rails 8 Migration Guide — Upgrade path to same target
• Fix Rails Upgrade Test Failures — Earlier step in the upgrade chain

Official sources

• Ruby on Rails 8.1 Release Notes — guides.rubyonrails.org (reliability 98%)
• Ruby on Rails 8.0 Release Notes — guides.rubyonrails.org (reliability 98%)
• rails/rails releases — rails/rails (reliability 92%)
• A Guide for Upgrading Ruby on Rails — guides.rubyonrails.org (reliability 98%)

Frequently asked questions

Is Rails 8 a hard upgrade?

For modern Rails 7 apps the framework changes are manageable, but the upgrade is high-risk because it can touch your job/cache/cable backends, asset pipeline, and deploy tooling. The effort scales with how much custom infrastructure you have and whether you adopt the new Solid adapters and Kamal 2.

Do I have to adopt the Solid adapters and Kamal 2?

No. Solid Queue/Cache/Cable, Kamal 2, and Propshaft are the new defaults for fresh apps but are opt-in for existing ones. You can upgrade to Rails 8 while keeping your current Redis, Sidekiq, Sprockets, and deploy setup, then migrate infrastructure separately.