Rails 8.0 shipped November 7, 2024 and requires Ruby 3.2.0+. Headline features: a built-in authentication generator, Solid Queue/Cache/Cable (database-backed, no Redis), Kamal 2 + Thruster deployment, Propshaft, and production-ready SQLite. Rails 8.1 (October 2025) is the current release; Rails 8.0 now gets security fixes only, through November 2026.

This guide walks through each Rails 8 feature with the commands and defaults you’ll use. You’ll also find the current support timelines, a checklist for upgrading from Rails 7.1 or 7.2, and a summary of what changed in Rails 8.1.

All version claims in this guide were verified against a fresh rails new app on Rails 8.1.3.1 and Ruby 3.4.10.

Requirements and Support Status

Rails 8.0 and 8.1 both require Ruby 3.2.0 or newer. The rails gem enforces this through its gemspec, so gem install rails fails on Ruby 3.1 or older. In practice, you’ll want a newer Ruby than the minimum: the current Ruby 3.4 series gets you YJIT improvements and the longest runway of Ruby security patches.

Here is where each recent Rails version stands, based on the Rails maintenance policy as of August 2026:

Two takeaways from that table. First, Rails 8.0 is in its final stretch: it receives security fixes only, and those stop on November 7, 2026. Second, both 7.1 and 7.2 are already off the supported list entirely. If you run either in production, treat the upgrade checklist as due now, not someday.

The minimum Ruby versions come from the Rails upgrade guide, and the 8.1 feature set is documented in the Rails 8.1 release notes.

Built-In Authentication Made Simple

Rails spent years shipping the building blocks of authentication: has_secure_password in Rails 5, then normalizes, generates_token_for, and authenticate_by in Rails 7.1.

Rails 8 assembles those pieces into a generator. One command scaffolds a complete session-based authentication system, including database-backed sessions and password resets:

bin/rails generate authentication

The generator creates models, controllers, mailers, and views:

app/models/current.rb
app/models/user.rb
app/models/session.rb
app/controllers/sessions_controller.rb
app/controllers/passwords_controller.rb
app/mailers/passwords_mailer.rb
app/views/sessions/new.html.erb
app/views/passwords/new.html.erb
app/views/passwords/edit.html.erb
app/views/passwords_mailer/reset.html.erb
app/views/passwords_mailer/reset.text.erb
db/migrate/xxxxxxx_create_users.rb
db/migrate/xxxxxxx_create_sessions.rb
test/mailers/previews/passwords_mailer_preview.rb

Because the generated code lives in your app, you can read and modify every line of it. There’s no engine hiding the session logic, which makes the generator a strong default for teams that previously reached for Devise out of habit. All that’s left to add is a sign-up flow tailored to your application.

Leaner Rails Deployments with Solid Adapters

Rails 8 cuts the number of services a typical production app needs. Job queues, caching, and pub/sub messaging traditionally meant running Redis next to your relational database. Rails 8 replaces that with three database-backed adapters, installed by default in every new app: Solid Queue, Solid Cache, and Solid Cable.

1. Solid Queue is the new default Active Job backend. It uses the FOR UPDATE SKIP LOCKED mechanism for efficient job dispatch on PostgreSQL, MySQL, or SQLite, and ships with concurrency controls, retries, and recurring jobs. It runs 20 million jobs a day at HEY.

2. Solid Cache backs Rails.cache with disk storage instead of RAM. Modern NVMe drives make this fast enough for most workloads, and disk space is cheap. You get much larger caches that persist across deploys, plus encrypted storage and retention policies.

3. Solid Cable is the default Action Cable adapter in production. It relays messages between the app and connected clients through fast database polling, with performance comparable to Redis in most situations.

A new Rails 8 app wires all three up automatically: the generated Gemfile includes the gems, production.rb sets config.cache_store = :solid_cache_store and config.active_job.queue_adapter = :solid_queue, and cable.yml points at solid_cable. Existing apps can adopt each adapter independently with its installer, for example bin/rails solid_queue:install.

Swapping Redis for Solid Queue moves your job backlog into your database — worth keeping an eye on. AppSignal instruments Solid Queue out of the box, so queue latency and failed jobs show up alongside your Rails performance data.

Effortless Deployments with Kamal 2 and Thruster

Rails 8 ships with Kamal 2 as its default deployment tool. Kamal deploys your app as a Docker container to cloud VMs, bare metal servers, or a VPS, without a PaaS in between. With a single command (kamal setup), you can provision a production-ready Rails environment on a standard Linux box.

Kamal 2 pairs with Thruster, an HTTP proxy built for Rails and included in every new app’s Gemfile. Thruster adds zero-downtime deploys, HTTP/2 support, automated SSL certificates via Let’s Encrypt, and asset caching and compression in front of Puma. Multiple apps can share a single server without extra configuration.

Since Rails 8.1, Kamal no longer needs a remote registry like Docker Hub for basic deploys: Kamal 2.8 uses a local registry by default, so your first deploy needs nothing but a server and SSH access.

If you deploy with something else, pass --skip-kamal to rails new and keep your existing workflow. The kamal and thruster gems are marked require: false, so they add nothing to your app’s boot time either way.

SQLite is Ready for Production

Rails 8 promotes SQLite from a development convenience to a supported production database, backed by extensive work on the SQLite adapter and the Ruby driver.

The Solid adapters are the headline consumers: on a single-server app, SQLite can now power Active Job, Rails.cache, and Action Cable alongside your primary database. That gives small and mid-sized apps a genuine no-dependency stack: one server, one database engine, no Redis.

The adapter itself also picked up production-focused improvements in Rails 8:

• Full-text search and virtual tables via create_virtual_table.
• Bulk fixture inserts for faster data seeding.
• Transactions default to IMMEDIATE mode for better concurrency.
• SQLite3::BusyException is translated into ActiveRecord::StatementTimeout, so busy-database errors behave like their PostgreSQL and MySQL equivalents.

PostgreSQL and MySQL remain the right call for multi-server setups or heavy write concurrency. But “SQLite in production” stopped being a punchline with this release.

A New Era for the Asset Pipeline with Propshaft

Rails 8 makes Propshaft the default asset pipeline, replacing Sprockets after more than a decade.

Sprockets was designed before modern JavaScript build tools and HTTP/2 existed, and accumulated responsibilities to match: transpilation, bundling, minification. Propshaft drops all of that. It does two things: resolves asset paths and stamps digests onto filenames for cache busting.

That narrow scope fits how Rails apps are built today. Import maps cover the no-build JavaScript path, while apps with heavier front ends reach for esbuild, Bun, or Vite. Either way, the asset pipeline no longer needs to be a build tool, and Propshaft doesn’t try to be one.

New Script Folder and Active Record Improvements

Rails 8 adds a script folder for one-off and general-purpose scripts, such as data migrations or cleanup tasks. A matching generator scaffolds them:

bin/rails generate script my_script

You then run the script with:

bundle exec ruby script/my_script.rb

This keeps utility scripts organized and out of lib/tasks, where one-off code tends to linger forever.

A Slew of Active Record Improvements

Active Record also collected a batch of smaller upgrades in Rails 8:

• PostgreSQL float4 and float8 are now distinct types.
• drop_table accepts multiple tables at once, and create_schema/drop_schema are reversible in migrations.
• Advanced PostgreSQL table options, including inheritance and partitioning, are supported on create_table.
• Migrating a fresh database loads the schema first, then runs pending migrations, which speeds up CI and onboarding.
• Query log tags are enabled by default in development, so you can trace a SQL statement back to the exact line of application code.
• MySQL 5.6.4 or later is now required, enabling datetime columns with precision.

Upgrading from Rails 7.1 or 7.2

Both Rails 7.1 and 7.2 have reached the end of their security support. Here is the upgrade path that avoids the common traps:

1. Get on a supported Ruby first. Rails 8 requires Ruby 3.2.0+; Ruby 3.4 is the better target. Upgrade Ruby on your current Rails version and ship that separately.
2. Update to the latest patch release of your current series (7.1.6 or 7.2.3.x at the time of writing) and get your test suite green before changing anything else.
3. Move one minor version at a time: 7.1 to 7.2, then 7.2 to 8.0, then 8.0 to 8.1. Run bin/rails app:update at each step and review every changed file.
4. Adopt new framework defaults deliberately. Leave config.load_defaults at your old version until the app boots cleanly, then work through config/initializers/new_framework_defaults_8_0.rb one flag at a time.
5. Treat the Solid adapters as opt-in. Existing apps keep their Redis-backed cache, queue, and cable setups on upgrade. Migrate to solid_cache, solid_queue, or solid_cable individually via their installers, if at all.
6. Check your monitoring and deployment gems for Rails 8 support before you start. AppSignal’s Ruby integrations list shows which libraries are instrumented automatically, Solid Queue included.

The Rails upgrade guide documents the configuration changes for each hop in detail.

What You Already Have from Rails 7.1

Upgrading from 7.1 rather than 7.0 or earlier? Then you already have the features that release added, and none of them change in Rails 8. Rails 7.1 brought async query APIs (async_sum, async_pluck, and friends), Common Table Expressions through .with, enum with instance_methods: false, and a password_challenge accessor on has_secure_password. It also introduced the deployment groundwork Rails 8 builds on: default Dockerfiles, the /up health check endpoint, Rails.env.local?, and Puma worker counts matched to available processors. Templates gained the locals: magic comment for declaring accepted partial arguments. All of these carry forward unchanged, so the 7.1-to-8 jump is about adopting new defaults, not relearning existing APIs.

What Changed in Rails 8.1

Rails 8.1, released in October 2025, is the current release series. It keeps the Rails 8.0 stack intact and layers on developer-facing improvements. The Rails 8.1 release notes list seven major features:

• Active Job continuations. Long-running jobs can declare discrete steps and resume from the last completed step after a restart. This matters with Kamal, which gives job containers thirty seconds to shut down during a deploy.
• Structured event reporting. Rails.event.notify emits structured events with tags and context to subscribers you register, a better fit for log pipelines than parsing the human-oriented Rails logger.
• Local CI. A CI declaration DSL in config/ci.rb, run with bin/ci, turns fast developer machines into first-class test runners for small and mid-sized apps.
• Markdown rendering. Controllers can respond to Markdown requests directly with render markdown:, a nod to Markdown becoming the default format AI tools consume.
• Command-line credentials fetching. rails credentials:fetch reads a value from the encrypted credentials store, so Kamal secrets can come straight from Rails without an external secrets manager.
• Deprecated associations. Mark an association with deprecated: true and Active Record reports every usage, direct or indirect, before you remove it.
• Registry-free Kamal deployments. Kamal 2.8 defaults to a local registry, removing the Docker Hub prerequisite for basic deploys.

Here’s what a continuation-enabled job looks like:

class ProcessImportJob < ApplicationJob
  include ActiveJob::Continuable
 
  def perform(import_id)
    @import = Import.find(import_id)
 
    step :process do |step|
      @import.records.find_each(start: step.cursor) do |record|
        record.process
        step.advance! from: record.id
      end
    end
  end
end

If the container restarts mid-import, the job resumes from the saved cursor instead of reprocessing the whole batch.

None of these change Rails 8.0 application code, which keeps the 8.0-to-8.1 upgrade small. Given that 8.0’s security support ends in November 2026, there’s little reason to stop at 8.0 when upgrading.

Wrapping Up

Rails 8 is a deployment-focused release: authentication out of the box, Redis out of the stack, and a path from rails new to a production server that you own end to end. Rails 8.1 rounds it off with resumable jobs, structured events, and local CI.

If you’re starting a new app, Rails 8.1 on Ruby 3.4 is the default choice. If you’re maintaining an app on 7.1 or 7.2, the support clock has already run out, and the checklist above is the shortest route to a patched version.

For the complete list of changes, read the Rails 8.0 release notes and Rails 8.1 release notes. And if you want to get involved, the Rails GitHub repository lists open issues and contribution guidelines.

Thanks for reading!

P.S. If you’d like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!