Rails 8 + Solid Queue: Building Reliable Job Processing at Scale in 2026

Why Solid Queue Changes Everything for Rails Developers

For years, Rails developers faced a choice: add Redis as a dependency for job processing, or outsource to third-party services like Sidekiq Cloud or AWS SQS. Rails 8 shipped with Solid Queue—a production-grade job queue built directly into Rails that uses your existing database. This isn't a toy scheduler. It's a serious alternative that eliminates infrastructure complexity for companies building in North America who want to keep their stack lean.

If you're running Rails 7 and haven't evaluated Solid Queue yet, 2026 is the year to move. We're seeing teams at companies across Canada and the US cut cloud infrastructure costs by 30–40% while gaining better observability and control over their background jobs.

What Makes Solid Queue Different

Solid Queue isn't trying to be Sidekiq. It's solving a different problem: reliable job processing without leaving your database. Here's what that means in practice:

• No external dependencies: Jobs live in your Postgres or MySQL database. No separate Redis instance to manage, monitor, or scale independently.
• Database-native reliability: Your existing backup and replication strategy now covers your job queue automatically.
• Built-in visibility: Rails Console access to job data. No need for a separate UI dashboard (though the Rails admin UI is clean).
• Lower operational overhead: One fewer service to configure, secure, and troubleshoot in production.
• Cost efficiency: Fewer managed services means lower AWS/cloud bills, especially for startups and mid-market teams.

Setting Up Solid Queue in Rails 8

Getting started is straightforward. If you generate a new Rails 8 app with rails new myapp, Solid Queue is already configured. For existing Rails 7 projects upgrading to Rails 8:

1. Add the gem: bundle add solid_queue
2. Run the installer: rails solid_queue:install (creates migrations and config file)
3. Migrate your database: rails db:migrate
4. Update your job queue adapter in config/environments/production.rb to config.active_job.queue_adapter = :solid_queue
5. Start a worker process: bin/jobs start (usually via Kamal or systemd in production)

That's the happy path. If you're migrating existing jobs from Sidekiq, you'll need to handle job migration, but Solid Queue's API is compatible with most ActiveJob code, so rewrites are minimal.

Production Patterns That Actually Work

Pattern 1: Worker Process Isolation

Don't run your job workers in the same process as your web server. In development, the Rails server can handle both, but in production, use separate processes. With Kamal 2.0, this is as simple as defining a separate role:

web: bin/rails server -p 3000
worker: bin/jobs start

This keeps request handling fast and prevents long-running jobs from blocking HTTP responses.

Pattern 2: Concurrency Settings

Solid Queue respects your database connection pool. By default, it runs 5 workers. For CPU-bound tasks, match this to your server cores. For I/O-bound tasks (API calls, database queries), you can safely increase concurrency. In config/solid_queue.yml:

workers:
  - processes: 2
    threads: 10
    queues: [default, critical]

Two processes with 10 threads each = 20 concurrent jobs. Monitor your database connection pool to avoid exhaustion.

Pattern 3: Queue Priority and Routing

Use multiple queues for different job types. In your job classes:

class SendEmailJob < ApplicationJob
  queue_as :emails
end

class GenerateReportJob < ApplicationJob
  queue_as :reports
end

Then configure workers to prioritize critical queues. Emails and notifications should be processed before heavy background tasks. This ensures your user-facing jobs stay fast.

Pattern 4: Dead Letter Handling

Solid Queue tracks failed jobs automatically. Instead of jobs disappearing into the void, they stay in your database with error messages. Create a monitoring dashboard or cron job that alerts when the failed job count exceeds a threshold:

SolidQueue::FailedJob.where('created_at > ?', 1.hour.ago).count

Solid Queue + Kamal: The Complete Picture

If you're deploying with Kamal 2 (and you should be—it's the Rails 8 standard), Solid Queue integrates cleanly. Define your worker role in config/deploy.yml, and Kamal orchestrates separate containers for web and worker processes. This gives you easy scaling: need more job capacity? Spin up additional worker containers without touching your web tier.

When to Still Use Sidekiq

Solid Queue is powerful, but it's not a universal replacement. Stick with Sidekiq if you:

• Run millions of jobs per day and need Redis's in-memory speed
• Need advanced features like rate limiting across multiple servers
• Require third-party integrations that only support Sidekiq
• Already have Redis in your stack for caching

For most North American businesses—SaaS platforms, e-commerce, content platforms, APIs—Solid Queue in Rails 8 is the right default choice in 2026.

Next Steps

If your team is running Rails 7 or earlier, audit your job processing setup. What's your current cost? How much operational overhead? Solid Queue can be a straightforward upgrade with real financial and operational benefits.

At ElevenClicks, we've guided dozens of Canadian and US-based companies through Rails upgrades and job queue migrations. If you're evaluating Solid Queue for a production system or need help optimizing your current setup, our Rails specialists can help you design a reliable, cost-effective job processing architecture. Let's talk about your next project.