Rails 8 Guide: Features, Requirements & Upgrade Path (2026)

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: VersionMinimum RubyBug FixesSecurity FixesRails 8.1Ruby 3.2.0Until October 10, 2026Until October 10, 2027Rails 8.0Ruby 3.2.0Ended May 7, 2026Until November 7, 2026Rails 7.2Ruby 3.1.0EndedEnded August 9, 2026Rails 7.1Ruby 2.7.0EndedEnded (end of life) 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: The generator creates models, controllers, mailers, and views: 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. 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. 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. 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: You then run the script with: 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: 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. 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. 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. 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. 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. 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