VVersions.dev

Rails 7 → Rails 8

This guide covers upgrading from Rails 7 to Rails 8 — a single major step centered on adopting the new Solid infrastructure adapters and advancing config.load_defaults to 8.0. Because it can touch the database and deploy stack, treat it as high-risk.

Version upgradeDifficulty: hardEffort: 1–4 dayshigh risk

Last verified · Updated May 22, 2026

Migrating from Rails 7 to Rails 8 is a single major step. The work is adopting the new defaults — Solid Queue/Cache/Cable, Propshaft, Kamal 2 — and walking config.load_defaults to 8.0 once the suite is green. It is high-risk because it can change your job/cache/cable backends and require migrations.

Should you upgrade directly?

Yes. Rails 7 → 8 is a single supported major step. Run bin/rails app:update, get the app booting and the suite green on the new gem, then advance config.load_defaults to 8.0 and decide whether to adopt the Solid adapters now or later.

Key differences

  • Solid Queue/Cache/Cable replace Redis as the default job, cache, and cable backends.
  • Kamal 2 is the default deploy tool; Thruster fronts Puma for HTTP/2 and asset caching.
  • Propshaft is the default asset pipeline for new apps, replacing Sprockets.
  • A built-in authentication generator scaffolds sessions and password reset.
  • SQLite gains production-grade defaults.

Files and patterns to inspect

  • config/application.rb — the current config.load_defaults value.
  • config/cable.yml, config/cache.yml, and any queue config for adapter changes.
  • Gemfile — gems pinned to Rails 7 that lack a Rails 8 release.
  • Asset setup — Sprockets vs Propshaft, and any importmap/jsbundling config.
  • Deploy config — Capistrano/Docker vs Kamal 2.

Pre-migration checklist

  • Green test suite on the current Rails 7 version
  • Gemfile.lock committed; `bundle outdated` reviewed for Rails 8 support
  • A dedicated upgrade branch and a database backup

Run the update task

shell
# Bump rails in the Gemfile, then run the update task$ bundle update rails$ bin/rails app:update# Review every prompted config diff before accepting

Related paths

Official sources

Copy-ready AI prompts

Structured prompts for an AI coding assistant. Inspect first, then execute incrementally, and keep a human in the review loop.

Repo inspectionRepo inspection prompt
You are helping upgrade a Ruby on Rails codebase from rails-7 to rails-8.

Do not edit files yet. First inspect the repository and report:
1. The exact rails version in the Gemfile and Gemfile.lock, plus the Ruby version in .ruby-version and gemspec.
2. The current config.load_defaults value in config/application.rb.
3. Gems that may block the upgrade — run `bundle outdated` and flag anything unmaintained or version-pinned.
4. Custom autoloading patterns (require_dependency, non-conventional file/constant names) that Zeitwerk may reject.
5. The asset pipeline in use (Webpacker, Sprockets, jsbundling, importmap, Propshaft) and any deprecated config.
6. Pending and irreversible database migrations, plus the test and CI commands.

Return: a risk summary, the files and gems most likely to break, a suggested upgrade order, the commands to run before editing, and any questions that need human confirmation.

Safety: Inspection only. The agent must not modify files, run migrations, or change the Gemfile in this step.

Works with Claude Code, Cursor, GitHub Copilot

Migration executionMigration execution prompt
Upgrade this Rails app from rails-7 to rails-8, one concern at a time.

Work in this order and pause for review after each: (1) align the Ruby version if required, (2) bump the rails gem in the Gemfile and run `bundle update rails`, (3) run `bin/rails app:update` and review every prompted config diff (do not blindly overwrite), (4) resolve boot/autoload errors, (5) only after the suite is green, advance `config.load_defaults` to the new version and fix each deprecation it surfaces.

After each step run `bin/rails test` (or the project's test command) and report results before continuing. Never run pending database migrations without explicit confirmation, and do not bundle unrelated refactors.

Safety: Apply changes incrementally and keep each step reviewable. Database migrations and config.load_defaults bumps require explicit human confirmation.

Works with Claude Code, Cursor, GitHub Copilot

Test plan

Commands

  • bundle exec rails test
  • bundle exec rails test:system
  • bundle exec rubocop
  • bin/rails db:migrate:status
  • bin/rails assets:precompile

Manual checks

  • Boot: run `bin/rails runner 'puts Rails.version'` and confirm the app boots without autoload errors.
  • Background jobs: enqueue and process a job to confirm the queue adapter still works.
  • Assets: load a page and confirm the asset pipeline serves CSS/JS with no 404s.

Regression risks

  • Zeitwerk rejecting non-conventional file or constant names at boot.
  • Deprecated framework defaults flipping behavior when config.load_defaults advances.
  • Database migrations that are hard to roll back in production.

Acceptance criteria

  • App boots and the full test suite passes on the target Rails version.
  • No deprecation warnings remain after config.load_defaults is advanced.
  • Assets precompile and background jobs process on the new adapters.

Frequently asked questions

Can I upgrade to Rails 8 without switching to the Solid adapters?

Yes. The Solid adapters are the new defaults for fresh apps but are opt-in for existing ones. Upgrade the framework first while keeping your current Redis/Sidekiq/Action Cable setup, then migrate to Solid Queue/Cache/Cable as a separate, well-tested change.

Do I have to move to Kamal 2 and Propshaft?

No. Kamal 2 and Propshaft are defaults for new apps, not requirements for the upgrade. You can stay on your existing deploy tooling and Sprockets, and adopt them later once the version bump is stable.