Rails 8 Guide: Features, Requirements & Upgrade Path (2026) | AppSignal BlogPlatformFeaturesError TrackingPerformance MonitoringHost MonitoringAnomaly DetectionUptime MonitoringMetric DashboardsLog ManagementProcess MonitoringIntelligenceWorkflowDashboardsTime DetectiveMCP ServerHostingHatchboxLanguagesSupported LanguagesRuby (on Rails) APMElixir APMNode.js APMJavaScript Error TrackingPython APMGo APMJava APMPHP APMRust APMIntegrationsOpenTelemetryVercelKubernetesAWS CloudWatchSolutionsGrowthEnterpriseData ResidencyStartupsAdd-OnsLong-Term Log StorageHIPAA ComplianceResourcesBlogLearning CenterCustomer StoriesChangelogProduct DemosDocsPricingDocsPricingLoginRequest demoGet startedMenuGet startedLoginPricingDocsFeaturesError TrackingPerformance MonitoringHost MonitoringAnomaly DetectionUptime MonitoringMetric DashboardsLog ManagementProcess MonitoringIntelligenceWorkflowDashboardsTime DetectiveMCP ServerHostingHatchboxSupported LanguagesRuby (on Rails) APMElixir APMNode.js APMJavaScript Error TrackingPython APMGo APMJava APMPHP APMRust APMIntegrationsOpenTelemetryVercelKubernetesAWS CloudWatchGrowthEnterpriseData ResidencyStartupsAdd-OnsLong-Term Log StorageHIPAA ComplianceResourcesBlogLearning CenterCustomer StoriesChangelogProduct DemosRubyRails 8 Guide: Features, Requirements & Upgrade Path (2026)Damilola OlatunjiRails 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:
Shellbin/rails generate authentication
The generator creates models, controllers, mailers, and views:
textapp/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.

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:
Shellbin/rails generate script my_script
You then run the script with:
Shellbundle 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:

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
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:
Rubyclass 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.
↓ Article continues belowIs your Ruby app broken or slow? AppSignal lets you know.Ruby Monitoring by AppSignal
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!Frequently asked questionsWhat Ruby version does Rails 8 require?Rails 8.0 and 8.1 both require Ruby 3.2.0 or newer. The rails gem enforces this through its required_ruby_version constraint, so installation fails on older Rubies. For new applications, use the latest stable Ruby release.Is Rails 8.0 still supported in 2026?Yes, for security fixes only. Rails 8.0 stopped receiving bug fixes in May 2026 and receives security patches until November 7, 2026. After that date it reaches end of life. Rails 8.1 is the current, fully supported release.What are the Rails 8.0 release notes highlights?Rails 8.0 shipped on November 7, 2024 and requires Ruby 3.2.0 or newer. Highlights include a built-in authentication generator, the database-backed Solid Queue, Solid Cache, and Solid Cable defaults, Kamal 2 with Thruster for deployment, Propshaft, and production-ready SQLite.What is the difference between Rails 8.0 and Rails 8.1?Rails 8.1, released in October 2025, adds Active Job continuations, structured event reporting, a local CI runner, Markdown rendering, deprecated association tracking, and registry-free Kamal deploys. Rails 8.0 set the new defaults; 8.1 refines them without changing your day-to-day stack.Published Oct 7, 2024, Updated Aug 21, 2026Wondering what you can do next?
Subscribe to our Ruby Magic newsletter and never miss an article again.
Start monitoring your Ruby app with AppSignal.
Share this article on social media Most popular Ruby articlesMeasuring the Impact of Feature Flags in Ruby on Rails with AppSignalBy Julian Rubisch on Oct 2, 2024Five Things to Avoid in RubyBy Martin Streicher on May 22, 2024Should You Use Ruby on Rails or Hanami?By Aestimo Kirina on Apr 24, 2024Damilola OlatunjiDamilola is a freelance technical writer and software developer based in Lagos, Nigeria. He specializes in JavaScript and Node.js, and aims to deliver concise and practical articles for developers. When not writing or coding, he enjoys reading, playing games, and traveling.All articles by Damilola OlatunjiBecome our next author!Find out moreOn this pageRequirements and Support StatusBuilt-In Authentication Made SimpleLeaner Rails Deployments with Solid AdaptersEffortless Deployments with Kamal 2 and ThrusterSQLite is Ready for ProductionA New Era for the Asset Pipeline with PropshaftNew Script Folder and Active Record ImprovementsUpgrading from Rails 7.1 or 7.2What Changed in Rails 8.1Wrapping UpFrequently asked questionsAsk AI about this postGet a summary, extract steps, or ask follow-ups — answers cite the passage.Summarize the key pointsWhat are the main takeaways?Explain this to a beginnerScope: This post·Widen to blogIs your app broken?AppSignal lets you know.Monitoring by AppSignalShare this post$appsignal installAppSignal monitors your appsAppSignal provides insights for Ruby, Rails, Elixir, Phoenix, Node.js, Express and many other frameworks and libraries. We are located in beautiful Amsterdam. We love stroopwafels. If you do too, let us know. We might send you some!Discover AppSignalFeaturesError TrackingPerformance MonitoringHost MonitoringAnomaly DetectionUptime MonitoringMetric DashboardsWorkflowLog ManagementDashboardsProcess MonitoringTime DetectiveMCP ServerResourcesPlans & pricingDocumentationBlogCustomer StoriesChangelogLearning CenterWhy AppSignalllms.txtComparevs Better Stackvs Datadogvs Honeybadgervs New Relicvs Scout APMvs Sentryvs SolarWindsSupportNeed help or have a feature request? Talk to a real engineer. Not a bot, not a ticket queue.Contact usLive chatStatusSecurityEnterpriseData ResidencyStartupsLong-Term Log StorageHIPAA ComplianceAbout usAppSignal is built by a small, dedicated team spread across the world. We love stroopwafels.
If you do too, let us know. We might send you some.AboutJobsWrite for Our BlogDiversityOpen Source@AppSignalAppSignalTerms & ConditionsPrivacy PolicyCookie PolicyGDPR complianceContact us / Imprint

The Rails 8 release, including the subsequent 8.1 update, focuses heavily on making the framework more deployment-centric, streamlining infrastructure, and enhancing developer tooling. Rails 8.0 shipped in November 2024 and mandates Ruby 3.2.0 or newer, while Rails 8.1 is the current release, building upon the 8.0 foundation with further refinements. The support lifecycle dictates that Rails 8.0 receives only security fixes until November 2026, emphasizing the necessity of upgrading older versions.

A major theme of Rails 8 is the introduction of integrated features designed to simplify application development and deployment. Built-in authentication is provided through a generator that scaffolds complete session-based systems, including models, controllers, mailers, and views, allowing teams to bypass external solutions like Devise for default session management. Furthermore, the framework introduced Solid adapters, which replace the traditional reliance on external services like Redis for job queuing, caching, and messaging. Solid Queue utilizes an efficient mechanism for job dispatch across PostgreSQL, MySQL, or SQLite, and Solid Cache employs disk storage instead of RAM, offering persistent, encrypted caching. Solid Cable serves as the default Action Cable adapter, providing performance comparable to Redis via database polling. This integration allows smaller applications to achieve a dependency-free stack.

Deployment workflows are also significantly streamlined through the inclusion of Kamal 2 and Thruster. Kamal 2 defaults to deploying applications as Docker containers to various targets without requiring an intermediate Platform as a Service. When paired with Thruster, which handles zero-downtime deploys, HTTP/2 support, automated SSL, and asset caching, these tools facilitate production-ready environments on standard Linux boxes. This synergy enables applications to be deployed across multiple servers without complex configuration.

The database layer also saw important advancements, promoting SQLite to a fully supported production option. SQLite adapter improvements include support for full-text search and virtual tables, faster data seeding via bulk fixture inserts, transaction defaults set to IMMEDIATE mode for better concurrency, and the translation of busy-database exceptions to ActiveRecord statement timeouts. This positions SQLite as viable for small to mid-sized applications running on a single server.

In terms of asset handling, Rails 8 made Propshaft the default asset pipeline, retiring Sprockets. Propshaft focuses narrowly on resolving asset paths and applying file digests for cache busting, delegating heavy bundling and transpilation to modern tools like esbuild or Vite. Additionally, a new script folder has been introduced, accompanied by a generator, allowing developers to organize utility scripts, like data migrations, outside of the standard lib/tasks directory. Active Record also received several smaller improvements, such as distinct PostgreSQL float4 and float8 types, enhanced capabilities for table creation involving inheritance and partitioning, and default query log tagging for detailed SQL tracing.

The upgrade path from older versions, particularly Rails 7.1 or 7.2, necessitates a careful, incremental approach. It is recommended to first upgrade the underlying Ruby environment to a supported version, preferably Ruby 3.4, before addressing the Rails version. Subsequent migration should proceed by updating patch releases, ensuring the test suite remains green at each step. The process involves moving one minor version at a time, such as 7.1 to 7.2, then 7.2 to 8.0, and finally to 8.1, paying close attention to the configuration changes introduced at each transition. Existing operations involving Redis-backed caching, queuing, or cabling can be migrated to their respective Solid counterparts independently if desired.

Rails 8.1 specifically introduces several developer-facing enhancements layered upon the 8.0 stack. These include Active Job continuations, allowing long-running jobs to pause and resume from a saved state, which is beneficial for deployment scenarios. Structured event reporting offers a cleaner method for log pipelines by emitting tagged and contextual events. The framework also introduces local Continuous Integration capabilities via a configuration DSL, enabling developer machines to function as first-class test runners. Additional utility features involve Markdown rendering for controller responses, command-line fetching of credentials from the encrypted store, tracking of deprecated associations, and the removal of the dependency on Docker Hub for basic Kamal deployments through default local registry usage.