Updated October 2026: Replaced the unmaintained redis-rails gem with Rails’ built-in :redis_cache_store, and added notes on Rails 8’s Solid Cache/Solid Queue defaults and on Redis’s license changes and the Valkey fork.

I. What is Redis?

Redis is an in-memory data structure store known for its speed and flexibility. It serves as a high-performance database, cache, and message broker, offering various data structures such as strings, hashes, lists, sets, and sorted sets. In Rails applications, Redis is widely used for caching, session storage, background job processing, counters, and more.

A note on licensing

Redis is no longer simply “BSD-licensed open source”:

  • In March 2024, starting with Redis 7.4, Redis moved from the BSD 3-clause license to a dual RSALv2 / SSPLv1 source-available license (neither is OSI-approved). Earlier releases stay under BSD.
  • Also in March 2024, the Linux Foundation launched Valkey, a community fork that continues from Redis 7.2.4 under the BSD 3-clause license.
  • In May 2025, starting with Redis 8, Redis added the OSI-approved AGPLv3 as an additional license option.

For most applications that just use Redis internally, nothing changes in practice, but it is worth knowing which server (and license) your hosting provider actually runs.

II. Applications of Redis in Rails

  1. Caching: Redis is used as a caching layer for fragment caching, low-level caching with Rails.cache.fetch, and caching the results of expensive queries, reducing database load and improving application performance.

  2. Session Storage: Rails applications can keep session data in Redis so it is shared across multiple application instances. Rails has no built-in Redis session store, so there are two options:

    • Use the :cache_store session store, which saves sessions in Rails.cache (your Redis cache, once configured below). This suits short-lived, non-critical sessions, because cache entries can be evicted:

      # config/initializers/session_store.rb
Rails.application.config.session_store :cache_store, key: "_your_app_session", expire_after: 1.day

    • Use a dedicated gem such as redis-session-store (latest release 0.11.6, November 2024), which stores sessions in their own Redis keys.

  3. Background Job Processing: Redis serves as the queue backend for job libraries such as Sidekiq and Resque, which use it to queue, schedule, retry and monitor asynchronous tasks.

  4. Counters, Leaderboards and Analytics: Redis’s atomic commands make simple real-time metrics cheap: INCR for page-view counters, sorted sets for leaderboards, and HyperLogLog for approximate unique-visitor counts. With the redis gem:

    redis = Redis.new(url: ENV["REDIS_URL"])

redis.incr("post:#{post.id}:views")                           # page-view counter
redis.zincrby("leaderboard", 10, user.id)                       # add 10 points
redis.zrange("leaderboard", 0, 9, rev: true, with_scores: true) # top 10
redis.pfadd("visitors:#{Date.current}", visitor_id)             # unique visitors (approx.)
redis.pfcount("visitors:#{Date.current}")

  5. Action Cable: Action Cable can use Redis as its pub/sub adapter to broadcast WebSocket messages across multiple server processes.

III. Do You Still Need Redis in Rails 8?

Not necessarily. Rails 8 ships database-backed alternatives:

  • Solid Cache is the default cache store for new Rails applications.
  • Solid Queue is the default Active Job backend from Rails 8.0 onwards.
  • Solid Cable is a database-backed pub/sub adapter for Action Cable.

For many apps this removes Redis from the stack entirely. Redis is still a great choice when you need very low-latency caching, Sidekiq, or the data structures above — but it is now an option, not a requirement.

IV. Using Rails’ Built-in Redis Cache Store

Since Rails 5.2, Rails includes a Redis cache store out of the box, so the old redis-rails gem (last released in 2017) is no longer needed. To use it:

  1. Add the redis gem:

    bundle add redis

  2. Configure the cache store:

    # config/environments/production.rb
config.cache_store = :redis_cache_store, {
  url: ENV["REDIS_URL"],
  namespace: "cache" # only needed if the Redis server is shared with other apps
}

    The store is fault tolerant: if Redis is unavailable, reads become cache misses and writes are dropped instead of raising errors.

  3. Configure Redis for caching:

    Use a dedicated Redis instance (or at least a separate configuration) for the cache and set an eviction policy, for example maxmemory-policy allkeys-lfu, so Redis evicts old entries when memory is full. Don’t share this instance with Sidekiq: Sidekiq needs noeviction so that jobs are never silently dropped.

  4. Enable caching in development (optional):

    Caching is only enabled in production by default. To try it locally, set the same config.cache_store in config/environments/development.rb and toggle caching with:

    bin/rails dev:cache

  5. Verify Redis Integration:

    Rails.cache.write("example_key", "example_value")
Rails.cache.read("example_key") # => "example_value"

# The common pattern: compute once, then read from the cache
Rails.cache.fetch("stats/daily", expires_in: 1.hour) do
  Order.where(created_at: Time.current.all_day).count
end

    If Redis is properly configured, you should be able to cache and retrieve data using the Redis store.

V. Conclusion

Redis is a powerful tool for enhancing the performance and scalability of Rails applications. Use Rails’ built-in :redis_cache_store instead of redis-rails, keep separate Redis configurations for the cache (allkeys-lfu) and for job queues (noeviction), and reach for Redis’s data structures for counters and leaderboards. On Rails 8, weigh it against Solid Cache, Solid Queue and Solid Cable — and against Valkey if the Redis license matters to you.