Ruby on Rails 8: What the Comeback Looks Like in Production

Rails 8 arrived in November 2024 and did something unusual for a framework update: it reduced the number of services you need to run a production app. Most framework updates add features that require more infrastructure. Rails 8 replaced external services with database-backed alternatives that work out of the box.

The result is that a new Rails 8 app can ship to production with just a server, a database, and a container, and it still gets queued background jobs, caching, WebSockets, and HTTPS without reaching for Redis, Memcached, or a managed queue service.

What Changed

Rails 8 changed what a production Rails app needs to run. Solid Queue replaces Redis for background jobs, Solid Cache replaces Redis or Memcached for caching, and Solid Cable replaces Redis for WebSocket pub/sub, all reading and writing to your existing database. Kamal 2 then deploys the whole thing to any server as a Docker container, with SSL and zero-downtime rollouts built in. Four pieces, one goal: fewer services to run.

Solid Queue replaces the need for Redis as a background job backend. It uses your existing database to store and process jobs. For most apps, database-backed queuing is fast enough and removes a dependency.

Solid Cache replaces Memcached or Redis for fragment and low-level caching. Again, backed by your database.

Solid Cable makes Action Cable (WebSockets) work without Redis as a pub/sub layer.

Kamal 2 is the deployment tool that’s now bundled with Rails. It uses Docker to deploy your app to any server, a $6 VPS works, with built-in SSL, a reverse proxy (Kamal Proxy, which replaced Traefik), and zero-downtime deploys.

Thruster handles asset compression and HTTP/2 push when you deploy with Kamal. Nginx is no longer needed in the standard configuration.

Solid Queue in Practice

Background jobs in Rails use the Active Job interface regardless of the backend:

class SendWelcomeEmailJob < ApplicationJob
  queue_as :default

  def perform(user)
    UserMailer.with(user: user).welcome_email.deliver_now
  end
end

That code works with any Active Job backend. What changes with Solid Queue is that you configure it with a YAML file and it reads from your database, not from a separate Redis connection:

# config/queue.yml
default: &default
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 3
      processes: 2
      polling_interval: 0.1

production:
  <<: *default

The job record lives in your database, which means you can query it with ActiveRecord, join it to your own tables, and see the full job state without a separate Redis monitoring tool.

For apps that were using Sidekiq with Redis, this is a real simplification at low-to-medium volume. Solid Queue’s throughput is lower than Sidekiq at high volume (Redis is faster than a relational database for queue operations), but for apps processing thousands rather than millions of jobs per day, the difference is irrelevant. The Rails Active Job guide documents the adapter interface that makes swapping Sidekiq for Solid Queue a configuration change rather than a rewrite.

Authentication Generator

Rails 8 ships a rails generate authentication command that creates a complete session-based auth system in your app:

rails generate authentication

This creates:

• A User model with password hashing via BCrypt
• A Session model for tracking active sessions
• SessionsController for login/logout
• PasswordsController for password reset via email
• The necessary routes and views
• A Current model using ActiveSupport::CurrentAttributes

# Generated current.rb
class Current < ActiveSupport::CurrentAttributes
  attribute :session
  delegate :user, to: :session, allow_nil: true
end

The generated code is readable and extensible. It’s not a gem you install and configure. It’s code that lives in your app and you modify directly.

This covers the 90% case: email/password login with session management. For OAuth providers (Google, GitHub), you still reach for Omniauth. But a significant fraction of apps only need password auth, and the generator handles it cleanly.

Kamal 2: Docker Deployment to Any Server

Kamal 2 makes deploying a Rails app to a bare server about as straightforward as pushing to Heroku, but without the per-dyno pricing:

# config/deploy.yml
service: myapp
image: user/myapp

servers:
  web:
    - 192.168.0.1
  job:
    hosts:
      - 192.168.0.1
    cmd: bin/jobs

proxy:
  ssl: true
  host: myapp.com

registry:
  username: dockerhub-user
  password:
    - KAMAL_REGISTRY_PASSWORD

kamal setup    # First deploy: installs Docker, sets up the proxy, deploys
kamal deploy   # Subsequent deploys: builds, pushes, and rolls out with zero downtime

Kamal handles:

• Building the Docker image
• Pushing to a registry
• SSH-ing into your servers
• Running the new container
• Health-checking before removing the old container
• Rolling back if the health check fails

The proxy (Kamal Proxy) handles HTTPS via Let’s Encrypt automatically. You get SSL without configuring nginx or Certbot.

A $6/month Hetzner VPS can run a Rails 8 app for a small production workload. For teams used to paying for Heroku or Render dynos, this is a significant reduction in running costs for apps with modest traffic. Teams that would rather stay on a managed platform instead of running their own VPS can weigh Kamal against options covered in our Fly.io vs Railway deployment comparison.

No Node.js by Default

Rails 7 introduced importmaps as an alternative to webpack and esbuild, but they felt like a workaround. Rails 8 makes the no-Node path fully supported and the default for new apps.

New Rails 8 apps use Propshaft (the asset pipeline), importmaps for JavaScript, and Tailwind CSS via a standalone CLI (which downloads a Tailwind binary, not an npm package). You can add a Node-based build process if you need it for a JavaScript-heavy frontend, but it’s opt-in.

For Rails apps that are primarily server-rendered with light JavaScript (which is most admin tools, internal dashboards, content sites, and SaaS apps), the no-Node setup works well and eliminates a whole category of dependency management.

Who Should Look at Rails 8

Rails 8 is a good choice in 2026 for teams where:

• The primary language is Ruby, or the team has existing Rails experience
• The app is server-rendered with limited JavaScript complexity
• Minimizing external service dependencies matters (compliance, budget, operational simplicity)
• The deployment target is VPS rather than a PaaS

It’s less attractive when:

• The team is stronger in JavaScript/TypeScript (Node, Next.js are better fits)
• The app has a complex React or Vue frontend (Rails becomes just an API layer, and something like FastAPI may be lighter)
• High-concurrency requirements exceed what a multi-threaded Ruby process handles efficiently (Go or Elixir may be better suited)

If you’re weighing whether the language itself still makes sense for a new project, our breakdown of whether Rails is still worth learning in 2026 covers the hiring and ecosystem side of that decision. Teams that decide to move forward but lack in-house Rails experience can also see what to look for in our guide to hiring a Ruby on Rails developer.

The Reality

Rails had a rough few years as JavaScript frameworks dominated the conversation. Its conventions felt dated; its asset pipeline was painful. That period led to real improvements, first Hotwire for reactive UIs without JavaScript frameworks, then Rails 7’s modernized toolchain, now Rails 8’s self-contained production defaults.

The framework is in its best shape in years. The community is active. Gem quality is high. The productivity for CRUD-heavy apps is still hard to beat, a resource scaffold generates a complete model, controller, views, migrations, and tests in one command.

Teams that have written Rails off because of 2018-era complaints should spend a day with a new Rails 8 project. The experience is different from what they remember.