# Resque: Redis-Backed Background Job Processing for Ruby > Resque is a Ruby library that uses Redis to run background jobs across multiple queues. It is designed for applications that need durable, visible, and distributable job processing without coupling workers tightly to the web process. **resque/resque** — Resque is a Redis-backed Ruby library for creating background jobs, placing them on multiple queues, and processing them later. - Repository: https://github.com/resque/resque - Website: http://resque.github.io/ - Stars: 9,472 · Forks: 1,657 - Language: Ruby - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/resque-resque ## The Problem Resque Solves and Who It Is For Resque addresses the need to move time-consuming work out of the web request cycle. The README describes its purpose directly: it is a Redis-backed library for creating background jobs, placing them on multiple queues, and processing them later. Any Ruby class or module that responds to a `perform` method can become a Resque job. This means an existing Rails model can be turned into a background job without creating a separate class. Resque is composed of three parts: a Ruby library for creating, querying, and processing jobs; a Rake task for starting workers; and a Sinatra web application for monitoring queues and workers. It is primarily aimed at Ruby on Rails developers who need background processing and want transparency into what each worker is doing at any given moment. The project originated at GitHub in 2009, as described in the introductory blog post referenced in the README. The approach was shaped by GitHub's own production needs: resilience to memory leaks (by running each job in its own process), visibility into job state, and distributing workers across machines. The README notes that Resque workers "expect failure" as a normal condition, meaning the system is designed to handle job exceptions without crashing the worker process. ## How Resque Stores and Processes Jobs Jobs in Resque are stored as JSON packages in Redis. Each job class specifies which queue it belongs to via a class instance variable. The README gives this example of a job class: ```ruby class Archive @queue = :file_serve def self.perform(repo_id, branch = 'master') repo = Repository.find(repo_id) repo.create_archive(branch) end end ``` To enqueue a job, the application calls `Resque.enqueue`. Workers retrieve jobs using `Resque.reserve`, which performs an atomic pop from Redis. The README describes push and pop as constant-time and atomic, which means multiple workers on different machines can safely read from the same queue without conflicts. Workers run in separate processes. Each worker polls its assigned queue, processes one job at a time, and sleeps for a fixed interval when no jobs are available. The sleep interval is 5 seconds by default, visible in the README's pseudocode: `sleep 5 # Polling frequency = 5`. ## Installing Resque and Starting Your First Worker Add the gem to your Gemfile and install it with Bundler: ```bash gem 'resque' ``` In a Rake file, load the Resque tasks and your application: ```ruby require 'resque' require 'resque/tasks' require 'your/app' ``` Start a single worker against the `file_serve` queue: ```bash QUEUE=file_serve rake resque:work ``` To run workers against all queues: ```bash QUEUE=* rake resque:work ``` To start two workers at once: ```bash COUNT=2 QUEUE=* rake resque:workers ``` Each worker spawned by `COUNT=2` runs in its own process. Pressing Ctrl+C stops all of them. Workers require network access to the Redis server; they can run on any machine that can reach Redis, which supports distributed deployments across multiple servers. The README also shows a `resque:setup` Rake task that Rails applications can use to run initialisation code before any worker starts. ## Queue Priorities and the Queue List Model Resque does not implement numeric priorities. Instead, priority comes from the order in which queues are listed when starting a worker. The README describes this as the "queue list." Starting a worker with `QUEUES=critical,archive,high,low` means the worker checks `critical` first, exhausts it, then checks `archive`, and so on. Queues are created on the fly when the first job is enqueued, so there is no registration step required. This model has a consequence: a lower-priority queue only gets processed when all higher-priority queues are empty. The README includes a real-world example from GitHub, where specialized archive jobs run on a dedicated machine: ```bash QUEUES=critical,high,low rake resque:work ``` Running all queues alphabetically is possible with `QUEUE=*`. Excluding specific queues uses negation syntax: ```bash QUEUE=*,!low rake resque:work ``` Negated glob patterns also work. `QUEUE=*,!file_*` tells workers to skip all queues whose names begin with `file_`. The order of negated patterns does not matter; `QUEUE=*,!file_*` and `QUEUE=!file_*,*` produce the same result. ## Resque's Limitations and When to Choose Sidekiq The process-per-worker model is Resque's main cost. Each worker is a separate OS process. Under load, running dozens of workers means running dozens of processes, each with its own Ruby runtime loaded into memory. For applications with high job throughput or tight memory constraints, this adds up quickly. The README acknowledges this by framing the process model as a design choice that trades memory for resilience to memory bloat. Resque does not support numeric priorities, only queue ordering. Complex prioritisation schemes require managing multiple queues and starting workers with precise queue lists, which can become operationally complex when the set of queues grows large. The README notes that inotify detects only local file modifications, not external ones by other clients or tools. Applications that rely on file system events to trigger jobs need additional coordination when multiple workers run on different machines. Sidekiq is the most common alternative. Sidekiq uses threads instead of processes, which lets one Sidekiq process handle many concurrent jobs with a much smaller memory footprint. Sidekiq also uses Redis but with a different internal job format. Teams that need to run many concurrent jobs with minimal memory overhead will generally find Sidekiq's threading model more efficient. The trade-off is that thread-safe code is required for all jobs running under Sidekiq. ## Version Support, Monitoring, and License Resque 3.0 is a major update that raises minimum requirements: Ruby 3.2 or newer, Redis gem 4.0 or newer, and Sinatra 2.0 or newer. Rails 7.2 or newer is required for ActiveJob integration. Applications on Ruby 2.x must continue using Resque 2.x. The README's version support table lists Ruby 3.2, 3.3, 3.4, and 4.0 as explicitly supported. The included Sinatra web application shows workers, queues, job contents, and failure details. The README describes it as the frontend that "tells you what workers are doing, what workers are not doing, what queues you're using, what's in those queues, provides general usage stats, and helps you track failures." It runs as a separate Rack process using the config.ru file in the repository root. The examples/ directory includes god/ and monit/ subdirectories, which provide process supervisor configuration templates for keeping workers running under those tools. The last push to the repository was on 2026-09-16, coinciding with the v3.1.0 release on that date. Recent releases include v3.0.3 on 2026-09-10 and v3.0.2 on 2026-08-30, showing a steady maintenance pace in 2026. Resque is released under the MIT license, which places no restrictions on commercial use or modification. ## Conclusion Resque is a practical choice for Ruby applications that already run Redis and need simple, durable background job processing with full queue visibility. It works well when you want per-machine worker control and insight into what each worker is doing. The trade-off is a process-per-worker model, which consumes more memory than thread-based alternatives. Teams that run large numbers of concurrent jobs should evaluate whether Sidekiq's thread-based model is a better fit. Resque 3.0 requires Ruby 3.2 or newer; any application on Ruby 2.x must stay on Resque 2.x. ## FAQ ### What is a Resque worker? A Resque worker is an OS process started via a Rake task that polls one or more Redis queues for jobs and processes them. Each worker runs in its own process, which means multiple workers can run on the same machine or across different machines that share a Redis instance. ### How does Resque compare to Sidekiq? Resque uses a separate OS process for each worker, while Sidekiq uses threads within a single process. This makes Sidekiq more memory-efficient for high-concurrency workloads. Resque's process model is simpler to reason about but costs more memory at scale. Both use Redis for job storage. ### What does resque mean? The README describes it as being "pronounced like rescue." It is a deliberate misspelling of "rescue," chosen as the project name. ## Sources - [License: MIT](https://github.com/resque/resque/blob/master/LICENSE) - [Project website](http://resque.github.io/) - [README](https://github.com/resque/resque/blob/master/README.md) - [Releases](https://github.com/resque/resque/releases) - [resque/resque on GitHub](https://github.com/resque/resque) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/resque-resque