Background workers
Move time-consuming work out of your web requests. Run the processes that keep your application moving behind the scenes.
Give background work its own process
Run a worker command alongside the web service that accepts user requests. A worker can process queued jobs, transform files, or perform application tasks that take longer than a normal page load. Separate process definitions let you update and size the worker without making every web request share its execution resources.
Connect the queue and data it uses
Bind the worker to the database, storage, and supported queue or cache service it needs. Share the appropriate application configuration while keeping access limited to its purpose. Choose persistence and retry behavior that match the work: a disposable cache entry and a queued customer payment task need very different handling when a process stops.
Build for retries and interruptions
A worker can restart during a deployment or after a failure. Make jobs safe to retry, acknowledge them only when the required work is complete, and handle termination cleanly. Shipped gives you deployment history and logs for the worker, while your job design determines how duplicate deliveries, partial progress, and external side effects are handled.
A little more detail
Questions about Background workers?
Is a background worker the same as a scheduled job?
No. A worker typically consumes work from a queue or another ongoing source. A scheduled job starts at a configured time and runs a defined task. Choose the model that matches how the work arrives.
Will Shipped make every job run exactly once?
No. Applications must account for retries and interruptions. Use idempotency keys, durable progress, and suitable queue semantics when repeating a task could duplicate a charge, notification, or other external action.
From your workspace to the web