What’s new in Rails 8: the release that fires your PaaS

Most Rails apps we inherit look the same from the outside. A Rails app, a Redis for jobs, another Redis (or Memcached) for caching, a third piece of glue for WebSockets, Nginx in front, and a platform bill that grows faster than the user count.

Rails 8 asks a blunt question: do you actually need all of that? For most apps, the honest answer is no. Here’s what shipped, what each piece replaces, and where we think the line is.

The short version

Rails 8.0 was released on November 7, 2024, under the slogan “No PaaS Required”. The release is less about new syntax and more about removing moving parts:

• Solid Queue replaces Redis plus Sidekiq, Resque or Delayed Job for background jobs.
• Solid Cache replaces Redis or Memcached for caching.
• Solid Cable replaces Redis as the pub/sub backend for Action Cable.
• Kamal 2 and Kamal Proxy replace a PaaS (or a pile of hand-written deploy scripts) for getting the app onto servers.
• Thruster replaces Nginx in front of Puma for asset caching, compression and X-Sendfile.
• Propshaft replaces Sprockets as the default asset pipeline for new apps.
• bin/rails generate authentication gives you a sensible, session-based login system without pulling in a gem.

Every “Solid” adapter is database-backed. That’s the whole trick: your database is already the most reliable thing you run, so let it do more.

Solid Queue: jobs without Redis

Solid Queue stores jobs in your database and uses FOR UPDATE SKIP LOCKED on databases that support it (PostgreSQL and MySQL 8+), so many workers can pull jobs without stepping on each other. It also works on SQLite.

New Rails 8 apps get it by default. On a single server it runs inside Puma as a plugin; on bigger setups you run it as its own process with bin/jobs. It supports recurring jobs through config/recurring.yml, concurrency limits through limits_concurrency, and pairs with Mission Control – Jobs if you want a dashboard.

What it doesn’t do: it has no retry mechanism of its own. It leans on Active Job’s retry_on and discard_on, which is the right call, but it means your retry rules live in your job classes, not in a Sidekiq config file.

Who should care: almost everyone starting a new app, and anyone paying for Redis only because Sidekiq needs it. We wrote a separate migration guide from Sidekiq to Solid Queue.

Solid Cache: a bigger cache on disk

Solid Cache keeps cache entries in a database table instead of RAM. That sounds slower, and per lookup it is. But disk is cheap, so the cache can be much bigger, and a bigger cache usually means more hits. For the typical Rails use — HTML fragment caching — that trade is a good one.

It also supports encryption at rest and explicit retention limits, which matters if anything sensitive ends up in your cache.

Who should care: apps that cache rendered views and are paying for a large Redis or Memcached instance to do it. If you use Redis for something that genuinely needs sub-millisecond reads across many processes, keep it.

Solid Cable: WebSockets without Redis

Action Cable needs a pub/sub backend so that a message published by one process reaches clients connected to another. Until now that was nearly always Redis. Solid Cable does it with database polling, and keeps messages for a day by default, which is handy when you’re debugging what was sent.

Who should care: apps with modest real-time needs — Turbo Stream updates, notifications, presence. If you’re pushing thousands of messages per second, measure before you switch.

Kamal 2, Kamal Proxy and Thruster: deploy anywhere

Kamal deploys your app as Docker containers to any Linux server you can SSH into. Give it IP addresses and an SSH key, run kamal setup, and it prepares a fresh box and boots your app. New Rails 8 apps come with a config/deploy.yml and a production Dockerfile already written.

Kamal 2 swapped Traefik for Kamal Proxy, a small proxy built for this job. It gives you zero-downtime deploys, automatic Let’s Encrypt certificates and several apps on one server. Kamal 2 also added secrets integration with 1Password, Bitwarden and LastPass, and aliases such as kamal console for a remote Rails console.

Thruster sits in front of Puma inside the container. It handles asset caching, compression and X-Sendfile, so you don’t need Nginx in front of the app for those jobs.

Who should care: teams on a PaaS whose bill has outgrown the app, and teams who want to own their infrastructure without hiring someone to babysit it. We walk through a full single-server setup in Deploying Rails 8 with Kamal 2.

Propshaft: a smaller asset pipeline

Propshaft is now the default for new apps. Its job is deliberately small: put your assets on a load path and add digests to file names so browsers can cache them forever. Transpiling and bundling are left to tools built for that (importmaps, or jsbundling and cssbundling).

Sprockets is still supported. There’s no reason to rip it out of a working app just because the default changed. Switch when you’re already touching the asset setup.

The authentication generator

Run bin/rails generate authentication and you get User, Session and Current models, a SessionsController, a PasswordsController with a password-reset mailer, an Authentication concern, and the migrations to go with them. It uses has_secure_password with bcrypt, and the sessions controller ships with rate limiting on login attempts.

What it doesn’t give you: sign-up, email confirmation, OAuth, two-factor, or account locking. That’s intentional. It’s a starting point you’re meant to read and own. We compared it with Devise in The Rails 8 auth generator vs Devise.

SQLite is a real production option now

Rails 8 ships production-friendly SQLite defaults, including WAL mode and IMMEDIATE transactions, plus a fix in the Ruby driver for a file-corruption issue. Combined with the Solid adapters, a small app can run on one server with one SQLite file per concern (primary, cache, queue, cable) and nothing else.

That isn’t for everyone. If you need several app servers writing to the same database, you want PostgreSQL or MySQL. But for internal tools, early products and side projects, “one box, no database server” is a genuinely good setup now.

What we tell clients

Here’s the honest breakdown we give people who ask whether Rails 8 changes anything for them:

1. Starting a new app? Take the defaults. Solid Queue, Solid Cache, Kamal, Propshaft. Add Redis later if you measure a reason to.
2. Running a 7.x app on a PaaS? Upgrade Rails first, change infrastructure second. The upgrade itself is usually smooth; we wrote up the steps we follow from 7.2 to 8.0.
3. Running Sidekiq happily? You don’t have to move. Solid Queue is a great default, not a mandatory migration. Move when Redis is costing you money or attention.
4. Paying a lot for hosting? That’s where Rails 8 earns its slogan. Kamal on a couple of plain servers is often a fraction of the PaaS bill.

None of this is magic. It’s Rails doing what it has always done best: taking the setup most apps need and making it the default, so you can spend your time on the parts that are actually yours.

If you’d rather have someone plan this move with you, that’s what we do.

Sources

• Rails 8.0: No PaaS Required — rubyonrails.org
• Rails 8.0 release notes — Rails Guides
• Solid Queue README — GitHub
• Securing Rails Applications: Authentication — Rails Guides
• Kamal documentation — kamal-deploy.org