Starting from Rails 7.1, Puma will automatically spawn x worker threads where x is the amount of available processors.
This brings up the question on how to handle workers in a simple dockerized Rails production app.
In the case of a simple Rails application that occasionally sends some mails asynchronously and periodically cleans up a few ActiveRecord Blobs, are worker Gems like Sidekiq still needed? Or is the default configuration of Puma enough to get the job done?
If your application is really simple and you don't need any kind of queue persistence and/or crash safety mechanism you can rely on Rail's ActiveJob and set it to use the main process's RAM instead of any third party queue system like Sidekiq.
Please note that Sidekiq is not only about multi-threading your application. It can leverage Redis/Memcached to give your workers routines some consistency and persistence so for example if your main app crashes and you're only using ActiveJob with the queue kept in memory, you will lose every job that was still pending to be executed. If you were using Sidekiq and your main application crashed your jobs definitions would still be persisted and you would lose nothing.
So the anwser is yes, you can execute async jobs using only Rails built-in ActiveJob without Sidekiq or a similar tool, but depending on your use case this is not recommended.