Weave Code
Laravel Heavy Jobs Laravel Package
umbrellio/laravel-heavy-jobs
Laravel package for running heavy jobs in dedicated worker processes so resource-intensive tasks don't block or exhaust your main queue workers. Configure limits and keep background processing stable and isolated.
Позволяет отдельно хранить огромные данные задачи из очереди.
Frequently asked questions about Laravel Heavy Jobs
- What does umbrellio/laravel-heavy-jobs actually do?
- It is a Laravel queue extension for jobs whose payload or runtime is too large for your normal workers. Oversized job data is kept out of the queue message itself, and the heavy work is handed to dedicated worker processes so your main pool stays responsive. In practice your latency-sensitive jobs keep their throughput while batch and report-style jobs run isolated with their own limits.
- How is it different from Laravel's built-in queues and Laravel Horizon?
- Laravel's queue system and Horizon already cover prioritisation, supervision, and per-queue worker pools, so this package is not a replacement for either. Its narrower claim is the payload problem, jobs whose serialised data is large enough to bloat Redis or the jobs table, plus giving that work its own execution lane. If you only need more workers or better dashboards, Horizon alone is probably enough; reach for this when payload size or worker starvation is the real pain.
- How do I install umbrellio/laravel-heavy-jobs in a Laravel application?
- Install it with composer require umbrellio/laravel-heavy-jobs, then publish whatever configuration the package ships and review the defaults before deploying. Confirm in the package's composer.json that the Laravel constraint matches your framework version, and commit the lock file so every environment resolves identically. Run your existing queue test suite after the first install, because the package changes how jobs serialise and that is the seam most suites do not cover.
- Does this package support Laravel 12?
- Yes. Release 3.5.0 is explicitly described as adding Laravel 12 support, and it landed as a minor version, which suggests the package integrates through Laravel's public extension points rather than framework internals. Before upgrading, read the diff or the composer.json to see whether the Laravel constraint was widened to allow 10, 11 and 12 or replaced, since a replacement would silently drop older framework versions. Also check the release's PHP floor, because Laravel 12 requires PHP 8.2 or newer.
- What PHP version do I need for laravel-heavy-jobs?
- For a Laravel 12 install the effective floor is PHP 8.2, because that is what the framework itself requires. If you are still on Laravel 10 or 11 the package may permit a lower version, but verify that in its composer.json rather than assuming. Remember that adopting the package can raise your application's PHP floor, which ripples into base images, CI runners, and any legacy service sharing the same image.
- How do I configure limits for heavy jobs and worker isolation?
- The package is built around configurable limits: thresholds that decide what counts as heavy and how much data may remain inside the queue message. Start by publishing and reading the config file rather than editing vendor code, then set the thresholds from measured payload sizes and job durations in your own application instead of guesses. Keep those values in version control per environment, and run the heavy worker as its own supervised process on its own queue name so a runaway job cannot starve the pool your web requests depend on.
- Where are the large job payloads stored, and do I need to clean them up?
- By design the bulky part of a job is kept out of the queue message, so it lives in whichever store the package is configured to use rather than in Redis or the jobs table payload. That means you own the lifecycle: measure how much data accumulates, prune records for completed jobs, and make sure cleanup still runs when a job fails or is deleted. Treat it like any other unbounded table and add growth monitoring before it surprises you in production.
- Can I test heavy jobs with Laravel's Queue::fake() and Bus::fake()?
- Yes. Heavy jobs are still jobs, so Queue::fake() and Bus::fake() assertions such as assertPushed and assertDispatched continue to work on the dispatch side. What you should additionally cover is the hydration path that reassembles the stored payload, plus a test proving that a payload above your configured threshold is actually offloaded. If the package registers its own connection or worker command, add one integration test that runs against a real queue driver.
- What are the production concerns when running heavy jobs in dedicated workers?
- The failure modes are the ones you would expect from any out-of-band storage: orphaned payloads when a job is deleted, retries that re-read stale data, and heavy workers that quietly stop because nothing supervises them. Run the dedicated worker under Supervisor or an equivalent process manager, keep the payload store and failed_jobs under the same backup and retention policy, and alert on queue depth and storage growth rather than only on exceptions. Also confirm your deploy scripts restart the heavy worker, not just the default one.
- Is laravel-heavy-jobs actively maintained, and what alternatives should I consider?
- Maintenance is the first thing to verify: Laravel 12 support arrived in 3.5.0, but check the commit history, whether CI exercises a full Laravel and PHP matrix, and how quickly issues are answered before committing. Alternatives include plain dedicated queues and worker pools in Horizon, chunking large work into smaller jobs, or storing oversized payloads yourself and passing only an identifier through the queue. If your need is simply isolation rather than payload offloading, Laravel's native multi-queue setup covers it with no extra dependency.
Weaver
How can I help you explore Laravel packages today?