Active Job provides an application interface for background work, while the configured queue adapter determines how that work is stored and executed. The hosting environment must support that adapter’s services and workers.
IN THIS ARTICLE
What you need before you begin
Identify the actual queue adapter, Rails version and production worker command. Do not assume a new Rails default is also the configuration of an older application.
01 Operate Rails background jobs on hosting
Configure the adapter and its required database, broker or other service. Apply any required schema setup through a reviewed deployment.
Start the supported worker or dispatcher through the approved supervisor. Give it the same relevant production configuration as the web application.
Submit a harmless test job and verify the real result. Confirm it is not being held only in process memory when durable execution is required.
Set queue selection, concurrency, retry and failure behavior according to the adapter. Design externally visible actions to tolerate redelivery.
Restart workers as part of deployment and monitor queued age and failed work. Document how to retry or discard a job after reviewing its effect.
Confirm the expected result
Confirm a job completes after the submitting browser disconnects and that workers return after a controlled restart. Test delayed work as well as immediate jobs.
Troubleshoot unexpected results
If jobs remain pending, check the adapter, queue name and worker environment. If a job failed after an external action, reconcile the result before retrying.
A common question
Does choosing Active Job automatically start a worker?
No. The adapter and deployment determine execution. A production queue may require separately supervised processes and supporting storage even when enqueueing succeeds.