// the find
brandonhilkert/sucker_punch
Sucker Punch is a Ruby asynchronous processing library using concurrent-ruby, heavily influenced by Sidekiq and girl_friday.
Sucker Punch runs background jobs inside your existing Ruby process using thread pools from concurrent-ruby — no Redis, no separate worker process. It's the right tool when you want async email or logging on a Heroku dyno and can't justify the cost of Sidekiq. If jobs need to survive process restarts, it's the wrong tool.
Zero infrastructure: no Redis, no separate queue process, just threads inside your web process. ActiveJob adapter ships in Rails out of the box, so swapping in or out is a one-liner. The inline testing mode is genuinely useful — `require 'sucker_punch/testing/inline'` makes all jobs synchronous without mocking. Per-job worker and queue-size configuration is simple and obvious.
In-memory queue means any jobs sitting in queue when your process restarts are silently lost — the README says this is fine for non-critical work, but that's a foothole waiting to swallow someone. The FAQ basically admits that Rails' own AsyncAdapter does the same thing now, which raises the question of why you'd add a dependency here at all. No dead-letter queue or retry mechanism — a job that throws an exception is just gone unless you wire up the exception handler yourself. Concurrency model is threads-only; CPU-bound jobs will fight the GVL and you'll get less parallelism than you expect.