Bringing Rails into the Ractor age: what changed and what to watch

# Why Ractors matter now Ractors are Ruby's parallel isolation primitive. The coverage in this issue argues they're now viable for production and will improve further in Ruby 4.1. The central appeal is running more work inside a single process while using multiple cores without the memory cost of many forked workers.

# Reported benefits and early data A real-world comparison cited here found nearly sevenfold memory savings when replacing Puma's multiple processes with a Ractor-based approach. That kind of reduction targets host cost and process-management overhead, especially for large monolithic Rails apps where duplicate memory footprint per worker adds up quickly.

# Ractors Rails contributors are making incremental changes to allow pieces of Rails to be safely used across Ractors. The work items mentioned include:

• configuration, Action View settings, Active Record commit callbacks, and time zone configuration shareable across Ractors.
• Fixes so Active Record's schema context doesn't deadlock during attribute initialization.
• Using per-Ractor storage for event reporters on non-main Ractors.

# Tooling and ecosystem projects you can try

• Kino: a Ractor-based web server for Ruby 4.0+ that uses every core in one process. It recently added a Rack handler, so rails server -u kino will boot, though Rails currently runs in a fallback (non-Ractor-shared) mode when full shareability isn't available. Kino demonstrates the practical path to using Ractors for HTTP workloads.
• Jean Boussier's Balkan Ruby talk, highlighted here, argues for multiprocessing as an efficient way to serve Rails apps and is recommended background if you're evaluating parallel approaches.

# Other notable Rails and Ruby changes mentioned

• Rails merged support for the HTTP QUERY method, which sends idempotent query payloads in the request body.

# Security and maintenance warnings

• A universal deserialization gadget chain was found that can turn a Marshal.load call into remote code execution on Ruby 4.0.6. The write-up is a reminder to avoid Marshal.load on untrusted input.

• Rails 7.2 reached end-of-life on Aug 9, so teams should check their audit and maintenance timelines.

# What this means for teams If you're looking to reduce memory cost and explore per-process concurrency inside one process, Ractors are approaching practicality. Expect a gradual migration: Rails itself is being hardened for shareability, but full Ractor-first Rails apps aren't a single switch yet. Try Ractor-based servers like Kino in development and staging, follow the Rails changes to the subsystems you rely on, and pay close attention to security advisories (e.g., Marshal.load) before using serialized data across process boundaries.

# Practical next steps

• Experiment with Kino for non-critical workloads to measure memory and performance in your environment.
• Track Rails pull requests and changelogs that affect Action View, Active Record, and configuration shareability.
• Audit any use of Marshal.load and update dependencies (resolv) where relevant.
• Plan Rails upgrade and maintenance timelines given Rails 7.2 EOL.