Upgrading to Rails 8.2 Without Downtime

Rails upgrades fail for boring reasons.

Not because Rails 8.2 is unstable. Not because Ruby 4.0 is risky. They fail because production systems have state, traffic, and timing — and most upgrade guides pretend those don’t exist.

If you run a real Rails app, upgrading to Rails 8.2 requires planning, sequencing, and rollback paths. Let’s walk through what actually works in production.

The Wrong Mental Model: “If Tests Pass, We’re Safe”

Tests validate correctness. They don’t validate behavior under load.

Rails 8.2 introduces new defaults, stricter Active Record behavior, and subtle concurrency changes. Ruby 4.0 removes execution slack. Together, they surface problems tests never catch.

If your upgrade plan is “bundle update rails and deploy,” you’re gambling.

Production failures happen at integration boundaries — not in unit tests.

Audit Rails 8.2 Defaults Before You Enable Them

Rails 8.2 ships with defaults that change runtime behavior:

• Transaction boundaries
• Association loading semantics
• Concurrency assumptions

Don’t enable them blindly.

# config/application.rb
config.load_defaults 7.2

Upgrade Rails first. Opt into 8.2 defaults later, one by one.

This lets you isolate regressions instead of debugging everything at once.

Migrations Are the Most Dangerous Part

Schema changes cause more downtime than code.

Rails 8.2 migration helpers make it easy to do the wrong thing safely — like locking a table during peak traffic.

Avoid this pattern:

add_column :users, :status, :string, default: "active"

Instead:

add_column :users, :status, :string
# backfill in batches
# add default later

Ruby 4.0 won’t save you from database locks.

Staged Rollouts Beat Big Bang Deploys

What works:

• Dual-boot Rails versions
• Feature-flag framework behavior
• Canary deploys

Ship Rails 8.2 code paths dark. Enable them gradually. Measure P95 and P99, not averages.

If you can’t roll back in minutes, you’re not ready to deploy.

Final Thoughts

Rails 8.2 and Ruby 4.0 are production-ready. Your upgrade process might not be.

Treat upgrades as operational changes, not code changes. When you do, Rails 8.2 is predictable, boring, and safe — exactly what you want in production. To solve rails, see Ruby 3.5 Preview: What Matters for Rails in Production.