Should I upgrade to Rails 8 now?

Decide whether to move a production Rails app to Rails 8 now that the stack assumes newer Ruby and deployment conventions, and identify the breaking changes that block the upgrade.

Stay on Rails 7.2 briefly and upgrade Ruby plus Kamal 2 deploys first, unless you're already on Ruby 3.3+ and can validate the deploy breakages before production.

Blockers

Who this is for

Candidates

Upgrade now, but target Rails 8 on Ruby 3.3+ with Kamal 2-ready deploys

Rails 8.0 was released in November 2024 and Rails 8.1 in October 2025; the Rails upgrade guide says both Rails 8.0 and 8.1 require Ruby 3.2.0 or newer. As of 2026-04-02, Ruby 3.2 has already reached end-of-life on 2026-03-31, while Ruby 3.3 remains in normal maintenance with planned EOL on 2027-03-31. Rails 8 ships with new defaults and generated production conventions around Kamal 2, Thruster, Propshaft, and the Solid adapters. The practical blocker is not the gem bump alone: you need a Ruby upgrade plus a deployment/configuration migration if your current production stack still assumes Kamal 1, Traefik, `.env` secrets, or port 3000.

When to choose

Use this when you want the current Rails line and you can change runtime and deploy conventions in the same project window. The decisive factor is whether you can move straight to Ruby 3.3 or 3.4 and validate Kamal 2 configuration changes before production rollout.

Tradeoffs

You get onto the current Rails 8 line and avoid standardizing on an already-EOL Ruby baseline, but the upgrade spans app code, container image defaults, deploy config, and operational runbooks.

Cautions

Kamal 2 has backward-incompatible config changes, replaces Traefik with `kamal-proxy`, changes the default app port from 3000 to 80, moves secrets handling from `.env` to `.kamal/secrets`, and uses the Docker container driver by default, which does not support build caching or multiarch images. Rails 8 also changes generator-era defaults around Propshaft and database-backed Solid components, so teams with Sprockets- or Redis-centric conventions should avoid mixing framework upgrade and subsystem rewrites in one step.

Sources

Stay on Rails 7.2 briefly and first upgrade Ruby plus deployment conventions

The Rails 8 release notes explicitly recommend upgrading to Rails 7.2 first before attempting Rails 8. Rails maintenance policy says minor releases receive bug fixes for one year and security fixes for two years after first release, and the guides list Rails 7.2 as the August 2024 release line. As of 2026-04-02, this makes Rails 7.2 a reasonable short holding position only if it is buying time to remove hard blockers such as Ruby 3.2 dependency, Kamal 1 configuration, Traefik customization, or nonstandard container port assumptions. This is the lower-risk path if the production estate is not yet Kamal 2-compatible.

When to choose

Use this when the app is still on an older Ruby, still deploys with Kamal 1 or Traefik-specific settings, or needs a staged production migration. The decisive factor is whether deployment breakage is more likely than application-level Rails 8 incompatibility.

Tradeoffs

This reduces rollout risk by separating runtime, deploy, and framework changes, but it delays access to the current Rails 8 line and creates an extra upgrade step.

Cautions

Do not treat Ruby 3.2 as the long-term target: as of 2026-04-02, Ruby 3.2 EOL has already occurred. If you pause on Rails 7.2, the point should be to move to Ruby 3.3 or 3.4 and cleanly convert Kamal configuration, not to preserve the old baseline.

Sources

Facts updated: 2026-04-02
Published: 2026-04-03

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Should I upgrade to Rails 8 now?"
Missing something? Request coverage