By Rails 8 shipped with a bold premise: “No PaaS Required.” As cloud platforms have grown more costly, Ruby on Rails has shifted to reducing external infrastructure dependencies so that developers can deploy and run applications with fewer ever service dependencies.
Traditionally, deploying a Rails app to the internet has meant provisioning a database server (e.g., PostgreSQL) and additional services like Redis for caching, background jobs, or WebSockets. With Rails 8, the core team hopes to change that by baking in solutions for caching, job queues, and real-time WebSockets - all powered by your application’s database.
In this article, we’ll explore how Rails 8 delivers on the “No PaaS Required” promise, starting with an overview of the “Solid Trifecta.”
Solid Cache helps you cache without Redis
One of my favorite additions in Rails 8 is Solid Cache, a new cache store that replaces the need for Redis or Memcached. Solid Cache uses a database to persist cached data instead of an in-memory key-value store. While storing cached objects on disk is technically slower than RAM, there are some significant advantages.
First, disk storage gives you more space and is much cheaper than memory. With Solid Cache, you can afford to cache far more data (and keep it longer) without running out of RAM. At 37signals (the company behind Basecamp and HEY), switching from Redis to Solid Cache let them expand their cache to 10+ terabytes of data, ultimately bringing their P95 render times down by 50%.
Yes, reading from memory is faster than reading from disk. In many cases (like Basecamp’s usage), the tradeoff of caching more data makes this speed hit worth it.
By default, Rails 8 uses Solid Cache (backed by SQLite). Of course, as is usual for Rails conventions, you can still opt for another option like Redis if it’s a better choice for you. But sticking with this default lets you cache things without supporting another production service like Redis, which simplifies your infrastructure burden.
Solid Queue helps you do background jobs — without Redis
My second favorite part of the “Solid” trifecta is Solid Queue, a new Active Job backend that handles background job processing without needing Redis or even a separate job system dependency like Sidekiq.
Many Rails developers use gems like Sidekiq (which relies on Redis) or Delayed Job for background jobs. Solid Queue is Rails’ attempt to remove the need for another dependency. It integrates job queueing into your application’s database, so you don’t need a memory solution or queueing system.
Solid Queue stores jobs as records in a database table and uses efficient SQL features to manage a job queue. It can run either embedded in the Rails web process (as a Puma plugin for single-server setups) or in separate worker processes.
As one Rails core team member noted, the goal was to let a developer “install Rails, set up a database, and have background job processing right out of the box without having to manage seven different gems and other systems.”
Solid Cable helps you do web sockets (surprise, without Redis)
The third piece of Rails 8’s “No-Redis-needed” puzzle is Solid Cable — a new Action Cable adapter that, you guessed it, uses a database. Historically, Action Cable required a Redis server to broadcast messages between multiple Rails processes. With Solid Cable, you can leverage Action Cable for real-time WebSocket functionality, unlocking live updates for application features like chat and notifications—without running additional services.
I hope the benefit of the “Solid” trifecta is becoming clear by now. You can cache long-term data, process high-throughput background jobs, and deploy real-time features without standing up a Redis server or other pub/sub service. Together, these features lower the complexity for small apps (you can run everything on a single host with one database) and fit the Rails 8 philosophy of making deployment easier.
Is removing the need for Redis that big of a deal?
After seeing how so much of Rails 8 is about removing the dependency on Redis, you might be curious how much that actually matters. The answer depends on your context, but there are undoubtedly some notable benefits.
Fewer moving parts means less complexity, specifically in deployments. Every additional service (Redis, a separate background job runner, etc.) is another thing that can break or need scaling. By using the database for more, you simplify your production operations. You don’t need to monitor Redis memory or ensure a Redis instance is always running.
Many Rails devs have encountered the scenario where, in development, you don’t run a cache server or perhaps use a different queue adapter, but in production, you use Redis/Sidekiq. With the new Rails defaults, you can run the same setup in development and production, minimizing surprises. The stack is more self-contained and “just works” out of the box without special configuration for production.
Fewer servers or add-ons also means a cheaper hosting bill. Even on a larger scale, consolidating infrastructure comes with some cost efficiency. Database space is cheaper than memory!
Rails doesn’t prevent you from using Redis or other services. It just makes them optional. You can start with the built-in Solid adapters, and if you need to, you can introduce Redis or other solutions down the line.
SQLite removes the need for a database process
Another meaningful shift in Rails 8 is the embrace of SQLite as a usable production database, enabled by numerous improvements to Rails’ SQLite adapter. If your app can use SQLite in production, you don’t need a separate database server running. Instead, your data lives in a simple file on disk managed by the app process itself. Rails 8’s improvements to SQLite make this more realistic than it used to be.
SQLite can make deployment much more straightforward. You don’t have to install or manage MySQL or Postgres on the server or use (and pay for!) a managed DB service. It’s just a file that the Rails app reads and writes.
If you outgrow SQLite, you can, of course, migrate to a fully-featured database system later. The Rails core team just changed the default to a lightweight option—which fits well with the “No PaaS” narrative.
Kamal 2 helps you deploy
Rails 8 simplifies running an app in production—but what about getting the app to production? The release of Kamal 2 attempts to answer that question.
Kamal is an orchestration tool that deploys your app (via a Docker container) to any Linux server with minimal fuss. It automates building your app’s image, pushing it, and running it on servers without you having to handcraft all the server setup.
With some configuration and one command (kamal setup), Kamal will take a fresh Linux box and provision it with what it needs to run your Docker container.
After that, deployment is as simple as running kamal deploy, which pulls the latest image and swaps out the old container for the new one as a zero-downtime deployment.
Kamal 2 hopes to give you a PaaS-like deployment experience on any Linux host. You can turn any server into a Rails server running your app with a single command. Initial configuration might be a pain, but subsequent deploys are much more straightforward. It’s a big step toward making self-hosting as convenient as pushing to a platform like Heroku.
Is "No PaaS" a good idea?
Does Rails 8 truly make platforms a thing of the past? And can small to medium-sized teams really save money by self-hosting?
I recently deployed a hobby project on a VPS using Kamal, and it was a frustrating experience. While deployments are relatively seamless after I got it working, setup was far from it, and my work is cut out for me if I ever need to scale this project.
So, for me, the answer is no — Rails 8 doesn’t remove the value proposition of platforms. I’d rather focus on my app and let a platform like Heroku handle the infrastructure.
Solo developers and small teams would benefit more from focusing on their users than chasing economies of scale. Why not outsource hosting, deployments, and scaling to a platform that crushes it in these areas and focus on building a product your customers love?
Of course, as your team and application grow, you may find a platform’s pricing less attractive. At some point, it makes sense to have time and/or people dedicated to SRE and ops responsibilities, and Kamal (along with the other awesome Rails 8 defaults) is a huge step towards making that easier.
Bringing it all together
Rails 8 narrows the gap between self-hosting and using a platform, but it doesn’t close it enough to honestly claim “No PaaS required.” It’s clear, however, that Rails 8 makes it easier to choose a VPS over a PaaS without sacrificing too much developer experience; I just don’t think it’s a platform killer.
Solid Cache, Solid Queue, and Solid Cable all bring previously third-party requirements for web apps into first-party support, and I am grateful for that. It’s awesome to have lightweight but powerful defaults to get an application off the ground, and even better, they don’t require much infrastructure. If you choose to self-host, Kamal can take some of the burden of deployments away for you.
Whether you’re using a platform or not, monitoring is essential for responding quickly to errors and outages and providing a great user experience to your customers. Sign up for Honeybadger to gain real-time insights into your Rails application’s health and performance.
