VVersions.dev

Upgrade to Rails 8

Rails 8 is a recommended upgrade for apps already on Rails 7. The headline changes are the database-backed Solid adapters (Queue/Cache/Cable), Kamal 2 deploys, Propshaft as the default asset pipeline, and a built-in authentication generator. Because upgrades touch the database and deploy stack, treat this as a high-risk change.

Version upgradeDifficulty: hardEffort: 1–5 days for a typical apphigh risk

Last verified · Updated May 22, 2026

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.
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

VersionStatusReleasedNotes
6.xEOL2019-08-16Upgrade off urgently — no security fixes
7.xMaintenance2021-12-15Security and bug fixes only
8.xActive (current)2024-11-07Solid adapters, Kamal 2, Propshaft
Migration executionAI-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

Official sources

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.