By Rails 8 is finally here, and it's shaking things up in a pretty exciting way. If you're already active in the Rails community, you might have heard the tagline: "No PaaS Required."
This is an unusual (but not surprising) mission—the release is all about making it easier to deploy your Rails apps without needing a fully-featured platform-as-a-service (PaaS).
Platforms offer a way for developers to get their apps on the web without managing the underlying infrastructure that runs their code. Businesses like Heroku, Render, Fly, and Railway have all been popular choices in the Rails community. Developers are often willing to trade some extra hosting costs for the developer experience platforms offer, but this Rails release is looking to make that trade a little less tempting.
In this article, we'll review the new and improved features that have made it possible. Things like Solid Cache, Solid Queue, and Solid Cable are new in Rails 8 and strip out some of the dependencies we used to need (such as Redis). Kamal 2 is now the default for deployments, and there are new authentication generators that remove the need for yet another gem. Let's get into it.
What did Rails 8 change?
Rails (and specifically Rails 8) really wants to make it easier for you to ship applications to production without needing to pay for a platform. Most of the changes in this release of Rails revolve around that mission - reducing the work it takes to host Rails applications yourself, with no PaaS required!
Let's take a closer look at each of the major changes.
Solid Cache for Redis-free caching
Rails uses ActiveSupport to cache things, which is critical to making web apps performant. Historically people have leaned on Redis for caching because it's fast and reliable.
Solid Cache was released a while ago as a Redis-free cache store for ActiveSupport It's been in use at 37signals and more for some time now, and Rails is now promoting it as the default choice. Because it uses a database (SQLite by default) for the cache store instead of RAM, you have the added bonus of being able to cache much more than you ordinarily would. Database space is cheaper than RAM, so while using a database to back a caching system is slower than using RAM, the ability to cache more things for longer can make some apps even more performant.
This performance tradeoff is great for some use cases but may not be ideal for others, so it's still easy to use one of the other cache stores. Removing the need for Redis or Memcached by default gets you one step closer to the "No PaaS Required" mission that Rails is on.
Solid Queue for Redis-free background jobs
You probably already know that Rails uses the ActiveJob library to make it easier for you to write and run background jobs. Much like caching, Rails lets you select the backend that powers ActiveJob. Many folks love Sidekiq or Good Job, but most options today have two problems:
- They are another dependency to import, manage, and potentially pay for
- They lean on another service like Redis (that you have to host, manage, and potentially pay for)
Solid Queue seeks to solve both of these by managing background jobs without relying on Redis. If you've been using Sidekiq or another queueing provider that depends on Redis, Solid Queue is an alternative that reduces complexity and makes hosting easier. Like Solid Cache, Solid Queue uses the application's database instead of RAM to keep track of background jobs. It's yet another feature that Rails is now providing by default to reduce dependencies and make production deployments simpler.
Solid Cable for Redis-free web sockets
Rails uses Action Cable to make it easy for developers to use web sockets for real-time features. Historically, this requires Redis. You can probably guess where this is going!
Keeping with the 'Solid' theme, Rails 8 ships with another default database-backed adapter. You don't need to use it, but if you're looking to use web sockets and you want to avoid having to configure and maintain Redis, this is an excellent first-party option. Together with Solid Cache and Solid Queue, Solid Cable makes it even easier to ship Rails applications without a PaaS by removing the need for Redis and leaning on the database.
Kamal 2 for easier deployments
The next new feature in Rails 8 is quite different from the Solid adapters. Still, Kamal (and specifically Kamal 2) makes it more straightforward to ship applications with your own hardware. Because Docker has made it easy to modularize software, having a piece of software to ship Docker containers, regardless of language, makes complete sense.
In my opinion, Kamal, even when paired with the rest of Rails 8, can't really touch the developer experience of most platforms. Still, it makes it way easier to ship software to your own web server, even if you're not using Rails! It might not be a complete replacement for a PaaS, but once you have your initial setup completed, running kamal deploy is a huge improvement over doing deployments yourself.
Authentication generators (without Devise!)
If you're making a Rails app that has users, you'll probably need authentication. So far, Rails hasn't included authentication as part of the framework. The community has several great solutions to help Rails developers write authentication, the most popular of which is Devise.
Rails 8 ships with authentication generators. This isn't a full authentication system, but it's enough to help you get the critical parts (like security) right. It's up to the developer to write the views to handle login and the user sign-up flow, but the generators will handle sessions, password authentication, and even password emails. DHH has talked a bit about how the choice to exclude the views in the authenticators is an intentional one meant to prevent Rails apps from looking all the same.
The addition of these new generators doesn't directly simplify shipping applications, but it does offer a first-party solution for a common problem in building web applications that Rails has been missing for far too long.
Propshaft for the asset pipeline
One of the biggest (under the hood) changes in Rails 8 is the move from Sprockets to Propshaft for the default asset pipeline. Rails still supports Sprockets if you want or need to use it, but new Rails 8 8 applications default to Propshaft.
Propshaft is very opinionated about not bundling or minifying assets. Just as Rails is looking to make PaaS unnecessary, it's also trying to make complicated build pipelines unnecessary. Like many of the other new defaults in Rails 8, you can use Propshaft with older versions of Rails and still use Sprockets for Rails 8!
SQLite and Rails
While SQLite isn't exactly part of Rails, Rails is leaning on SQLite even more with this release. SQLite is a serverless database engine, making it simpler than something like Postgres. If your Rails application uses SQLite, you won't need a database process running separately from your web process. Of course, this is very much in line with the mission of Rails 8, making it simpler to ship web applications.
Rails 8 ships with first-party support for SQLite, ensuring it's powerful enough to handle your traditional database needs and support the new database-backed Solid adapters.
Everything new in Rails 8 is about making platforms less necessary
If you're upgrading an existing Rails app to Rails 8, there's not a lot that you have to do to complete the upgrade. Only a few things were removed, mostly in Active Record, which has already had deprecation notices for some time. You can, of course, take advantage of all the "new in Rails 8" defaults to simplify your application deployments, but it's optional.
The biggest changes in Rails 8 are for new Rails apps! New Rails apps will default to Solid Queue for background jobs, Solid Cache for caching, Solid Cable for web sockets, Propshaft for the asset pipeline, and Kamal 2 for deployments.
Rails has been on a mission lately to compress complexity and provide a full-featured framework for making modern web apps. Rails 8 moves beyond making web apps and into shipping web apps while remaining compatible with existing options.
You can use all, some, or none of the Rails 8 defaults and still use a platform if you prefer that developer experience. But this release aims to give you the option to skip the platform and take more ownership of your infrastructure.
If you enjoyed this article, sign up for the Honeybadger newsletter for more Ruby and Rails news and tutorials right in your inbox!
