Ruby on Rails 8.1: What's New, Release History & Support Lifecycle

What Is New in Ruby on Rails 8.1

Rails 8.1 delivers a focused set of improvements centered on job resilience, structured observability, streamlined deployment, and cleaner codebases. Below is a high-level summary of what changed.

How Do Active Job Continuations Work in Rails 8.1?

Active Job Continuations let long-running jobs resume from the last completed step instead of restarting from scratch after an interruption. This is the single most operationally significant change in Rails 8.1 for teams running background jobs during deploys.

In practice, if you use Kamal -- which gives job containers only 30 seconds to shut down -- a large import or data migration job used to either fail mid-way or require complex custom checkpointing. Now you include ActiveJob::Continuable and define discrete steps:

class ProcessImportJob < ApplicationJob
  include ActiveJob::Continuable

  def perform(import_id)
    @import = Import.find(import_id)

    step :initialize do
      @import.initialize
    end

    step :process do |step|
      @import.records.find_each(start: step.cursor) do |record|
        record.process
        step.advance! from: record.id
      end
    end

    step :finalize
  end

  private
    def finalize
      @import.finalize
    end
end

The step.cursor is automatically saved when the job is interrupted, and the job resumes from that exact record on the next execution. Watch out for jobs that have side effects which are not idempotent -- continuations assume each step can be safely re-entered from its cursor position.

Most teams doing rolling deploys with a Solid Queue backend will want to audit existing long-running jobs and migrate them to this pattern. The cursor approach is especially well-suited to find_each loops over large datasets.

What Is the New Structured Event Reporting API in Rails 8.1?

Rails 8.1 introduces Rails.event, a unified interface for emitting structured events from anywhere in a Rails application -- a direct answer to the long-standing gap between human-readable logs and machine-parseable observability data.

The API supports three core primitives:

• Notify: emit a named event with a structured payload (Rails.event.notify("user.signup", user_id: 123))
• Tagged: wrap a block so all events inside carry extra tag metadata
• Set context: attach ambient key-value pairs (e.g. request_id, tenant ID) to all events in scope

Applications control serialization by registering subscriber objects that implement an #emit method. This means you can fan out to Datadog, a log aggregator, and an internal event store simultaneously without coupling your domain code to any specific sink.

Rails.event.set_context(request_id: "abc123", shop_id: 456)

Rails.event.tagged("checkout") do
  Rails.event.notify("order.placed", order_id: order.id, total: order.total)
end

This matters if you are building multi-tenant SaaS products where attaching a shop_id to every emitted event used to require a custom middleware or thread-local hacks. The context API solves this cleanly at the framework level.

What Breaking Changes in Action Pack Should You Watch Out for When Upgrading to Rails 8.1?

Rails 8.1 ships several query string parsing behavior changes that were deprecated in earlier versions and are now fully removed -- these are the most likely to silently break API clients or form submissions.

Two changes deserve close attention before upgrading:

• Leading brackets in query strings are no longer stripped. A query string like [foo]=bar previously parsed to { "foo" => "bar" }. It now parses to { "[foo]" => "bar" }. Any client sending bracket-prefixed keys without a proper leading key will break silently.
• Semicolons are no longer treated as query string separators. foo=bar;baz=quux used to yield two separate params. Now the entire string after the semicolon is treated as part of the first param value. This affects older JavaScript libraries and some HTTP clients that generate semicolon-delimited query strings.

# Before Rails 8.1
ActionDispatch::ParamBuilder.from_query_string("[foo]=bar")
# => { "foo" => "bar" }

# After Rails 8.1
ActionDispatch::ParamBuilder.from_query_string("[foo]=bar")
# => { "[foo]" => "bar" }

The safest upgrade path is to run your full integration test suite with RAILS_ENV=test against Rails 8.1 before touching staging. Pay particular attention to any controller specs that parse query strings directly, and audit any third-party clients that send non-standard query string formats.

Active Storage teams should also note that the :azure storage service has been fully removed. If you are on Azure Blob Storage, you must migrate to the azure-blob gem adapter before upgrading.

How Do Deprecated Associations and the New Local CI Change Day-to-Day Rails Development?

Rails 8.1 adds two developer-experience improvements that are small in code footprint but large in practical impact: the ability to mark associations as deprecated, and a built-in local CI runner.

Deprecated Associations let you signal that a relationship is being phased out without immediately breaking anything. This is invaluable when refactoring a legacy data model:

class Author < ApplicationRecord
  has_many :posts, deprecated: true
end

Usage of author.posts, preloading via author.preload(:posts), and even nested attribute usage will all trigger a report. Three modes are available -- :warn (default), :raise, and :notify -- and you always get the source location of the offending call regardless of backtrace settings. Most teams will start with :warn during a migration window and switch to :raise before finally removing the association.

Local CI gives new Rails apps a config/ci.rb file and a bin/ci runner out of the box. The DSL is straightforward:

CI.run do
  step "Setup",            "bin/setup --skip-server"
  step "Style: Ruby",      "bin/rubocop"
  step "Security: Brakeman", "bin/brakeman --quiet --no-pager --exit-on-warn --exit-on-error"
  step "Tests: Rails",     "bin/rails test"

  if success?
    step "Signoff", "gh signoff"
  else
    failure "CI failed. Do not merge or deploy.", "Fix the issues and try again."
  end
end

The optional gh signoff integration blocks merges on GitHub until a passing CI run has explicitly signed off the PR. For small-to-mid-sized teams, this can completely replace a cloud CI provider for day-to-day feedback cycles.

What Active Record and Active Support Deprecations in Rails 8.1 Require Immediate Action?

Several Active Record and Active Support deprecations in Rails 8.1 will surface as warnings in your logs the moment you upgrade -- and a few of them may require non-trivial refactors before you can move to Rails 8.2.

On the Active Record side, watch out for:

• Order-less finder methods: calling #first, #last, or similar methods without an explicit order scope is now deprecated. This affects a lot of convenience calls in controllers and seeds.
• insert_all/upsert_all with unpersisted records in associations: this pattern is being removed. Ensure records are persisted before using bulk-insert APIs through associations.
• WITH / WITH RECURSIVE / DISTINCT in update_all: these SQL features combined with update_all are deprecated. Refactor to raw SQL or scoped queries.
• schema.rb columns now sorted alphabetically: this is not a deprecation but a behavior change. If your team diffs schema.rb in code review, expect a one-time large diff on the first run of db:schema:dump after upgrading.

On the Active Support side, String#mb_chars and ActiveSupport::Multibyte::Chars are deprecated. If your app handles multibyte string manipulation through these APIs (common in internationalized apps), you will need to migrate to Ruby's native encoding APIs or a dedicated gem.

The built-in Sidekiq adapter deprecation in Active Job is worth flagging separately: the adapter is being moved to the sidekiq gem itself. Add the latest version of the sidekiq gem to your Gemfile and remove any explicit adapter configuration pointing to the Rails built-in version.