- What is barryvdh/laravel-async-queue and what problem does it solve?
- It registers an async queue driver with Laravel's QueueManager that spawns a short-lived background PHP process for each dispatched job, instead of relying on a supervised, long-running queue:work daemon. Your dispatch() call sites and ShouldQueue job classes stay unchanged, so it is an operational substitution rather than an architectural change. It fits small-to-medium Laravel monoliths on a single VPS, bare metal, or shared hosting where daemons are not available. Jobs should be short, ideally under five seconds and certainly under thirty.
- How do I install and configure the async queue driver in Laravel?
- Install it with Composer, register the service provider, add a connections entry for the async driver, and make sure a backing store is configured. Realistically this is under a day of work per environment. Before committing to that estimate, prove two platform conditions: that proc_open is permitted in the production image and that a PHP CLI binary is discoverable at a known path. Those failures surface at runtime rather than install time, so gate them explicitly.
- Does this package require a queue worker or Supervisor?
- No. Each dispatch spawns a short-lived PHP process that runs a single-job worker invocation, so you do not need a supervised queue:work daemon. That is exactly why it suits shared hosting and simple deployments without dedicated ops capacity. The trade-off is that process spawning, PHP CLI discovery, and writable storage become hosting-contract dependencies that a base-image change can silently break.
- Which Laravel versions does laravel-async-queue support?
- The package is pre-1.0 and the repository is archived, so there is no ongoing Laravel major-version compatibility work and no SemVer guarantee. Pin 0.8.1, which contains the deferred service provider fix. Because there is no upstream escalation path, treat every future Laravel upgrade as the responsibility of your own fork.
- Why should I pin version 0.8.1 and avoid 0.8.0?
- The only change in 0.8.1 is a fix for deferred service provider registration, which makes the provider and queue connector lazy. On 0.8.0 the driver binding can fail to resolve depending on when the queue connection is first touched relative to provider boot. That class of bug hides under Octane, in test suites that resolve connections early, and in partially booted console commands. There is no API or config change for job authors, so pinning is free.
- Why does dispatch() appear to succeed when no background process actually ran?
- The driver spawns a process at dispatch time, and dispatch returns successfully whether or not that process actually spawned and completed the job. There is no Horizon-equivalent dashboard, so failed-job visibility is limited to whatever your backing store and failed_jobs table expose. If you need monitoring or delivery guarantees, this driver does not provide them.
- Is barryvdh/laravel-async-queue still maintained?
- The repository is archived, so there will be no security patches, no future Laravel major compatibility work, and no upstream escalation path. It is pre-1.0, single-maintainer, and has thin ecosystem signal, which means low community-fork momentum if you need to carry the code. Adopting it implies a fork-and-own commitment with a named internal owner; if no owner can be named, that is a stop decision.
- When should I not use this async queue driver?
- Skip it if you already run Horizon or a managed broker, operate on Kubernetes or serverless/ephemeral runtimes, or have high-throughput pipelines or workloads whose contract includes delivery guarantees. Adding it where a broker already exists introduces risk for zero delivery benefit and should be stopped early in design review. It is also a poor fit for long-running jobs.
- How do I test jobs dispatched through the async queue driver?
- Keep using Laravel's normal queue fakes and assertions, since dispatch() call sites and job classes are unchanged. Be aware that boot-order issues on the 0.8 line can surface in test suites that resolve queue connections early, which is another reason to stay on 0.8.1. Gate any test that exercises real process spawning behind a check for proc_open and a discoverable PHP CLI binary.
- What are the alternatives to laravel-async-queue?
- Laravel's built-in database or sync drivers, a Redis-backed queue with Horizon, or a managed broker all avoid the process-spawning dependency. Choose those when you have ops capacity or need monitoring and delivery guarantees, and choose this driver only for a defined window on constrained hosting. Because it is a driver, moving off it later is a config-level change, which keeps the exit cheap.