Use the queue library you know
Run Celery, BullMQ, Sidekiq, a Laravel queue worker or your own consumer process. Configure the command and broker connection your application requires.
Background workers
Keep requests moving.
Let workers do the rest.
Process files, send messages and handle queued jobs without holding up a web response. Run a dedicated worker with its own start command, environment and resources.
Your code. Infrastructure included.
YOUR APPLICATIONYOUR QUEUE
Send receipt01
Create report02
Process upload03
receipt-worker / process
$ celery -A app worker
connected to configured queue
Ready to process the next job_
Meanwhile, your web app keeps responding.
Long-runningA dedicated application process
IndependentSeparate resources from your web app
PrivateNo public HTTP endpoint
BACKGROUND WORKERS ON OPENSTEAD
Give background work room to run.
A worker can use the same repository as your web application, with a different command and resource allocation. Your task library stays in charge of the queue.
Size the process separately
Assign worker memory and CPU independently of the web app. Adjust application concurrency to fit the service’s capacity and the type of jobs it processes.
Connect the rest of the stack
Use private connections to Key Value and databases in the same environment. Inspect runtime output from the worker’s service page.
MADE FOR YOUR STACK
Same codebase. A different entry point.
Deploy your application repository twice: once to receive requests, and once to process work. Each service can have its own command, variables and instance plan.
- Workers run without a public web route.
- Queue or broker resources are provisioned separately.
- Your application controls acknowledgements, retries and job safety.
A Laravel queue workeropenstead / configuration
WORKER CONFIGURATIONRepository your-team / application
Service type Background worker
Start command
php artisan queue:work redis
--sleep=3 --tries=3 --timeout=90
Environment
QUEUE_CONNECTION=redis
REDIS_HOST=your-key-value-private-hostUse your service credentials and tune timeouts for the jobs you run. Design jobs to tolerate retries and process restarts.
PUT IT TO WORK
Built for the work
your application does.
Messages and notifications
Queue transactional messages and let a worker send them through your chosen delivery provider.
Imports and file processing
Handle data imports, transformations and uploaded files outside the HTTP request lifecycle.
Reports and integrations
Generate reports or synchronize data with external systems in a separate application process.
HOW IT WORKS
The web app hands off. The worker picks up.
Configure the process
Choose the application repository or image and set the worker start command. Add the environment variables and credentials it needs.
Connect a queue
Provision Key Value or use another compatible broker. Give the web application and worker the same queue connection settings.
Deploy and follow the work
Launch the worker, submit a test job and inspect its logs. Configure retries and concurrency in your task library.
Can I use the same repository as my web app?
Yes. Create a separate worker service from the same repository, then set its worker command and environment variables. The web app and worker have independent deployments and resources.
Does a worker expose a website or API?
A worker has no public HTTP endpoint. Use a web service for incoming web traffic and a private service for an internal HTTP API.
Is the queue included in the worker plan?
The worker plan runs your consumer process. Provision Key Value or another compatible broker separately, and configure both the producer and consumer to use it.
How do retries and failed jobs work?
Your task library controls retries, failed-job storage and acknowledgements. Use idempotent handlers where appropriate so repeating a task does not repeat an unintended side effect.
MAKE YOUR NEXT MOVE
Do more work behind every response.
Your code. Infrastructure included.