- How do I install enqueue/laravel-queue in a Laravel app?
- Install it with composer require enqueue/laravel-queue, plus the Enqueue transport package and client extension for the broker you want, such as enqueue/amqp-lib or ext-amqp for RabbitMQ. Laravel package auto-discovery registers the service provider, so you then add an enqueue connection block in config/queue.php and configure the transport in config/enqueue.php. Because it registers a new driver rather than replacing anything, the enqueue connection can run alongside your existing Redis, SQS or database connections, which makes a branch spike or canary rollout straightforward. A short proof of publish, consume, retry and fail end to end is a realistic first-day goal.
- Which Laravel versions does enqueue/laravel-queue support?
- Check the composer.json constraints, but treat those as the maximum allowed range rather than proof of support. The important question is which Laravel versions are actually exercised in the package CI matrix, since the Illuminate queue Job contract keeps growing and an adapter can pass install while failing at runtime. Before committing, verify your exact Laravel version against the CI config and run your own feature spike on the branch you plan to deploy.
- What transports does the Enqueue Laravel queue driver support?
- Enqueue covers AMQP/RabbitMQ, Amazon SQS, Kafka, Google PubSub, Redis, STOMP, Gearman, Beanstalk and others through its transport abstraction. That breadth is the main reason to use the package, because Laravel ships no first-party driver for RabbitMQ, Kafka, STOMP or PubSub. Support is not uniform in practice: per-transport fidelity for delays, priorities, TTL, attempts and dead-lettering varies, so confirm the behavior of your specific broker rather than assuming Laravel semantics carry over.
- Should I use enqueue/laravel-queue with Redis or SQS when Laravel already has drivers?
- No. For Redis, SQS and database connections Laravel already provides first-party, well-documented drivers, and swapping in this adapter is strictly downside risk. The package's value is filling gaps where Laravel has no native transport, realistically RabbitMQ/AMQP, Kafka, STOMP or Google PubSub. If your broker is already supported natively, keep the native driver and the observability that comes with it.
- Does enqueue/laravel-queue work with Laravel Horizon?
- No. Horizon is Redis-only and will not monitor or autoscale this connection, which for many Laravel teams removes the primary observability and autoscaling surface. If Horizon is central to your operations, plan for an alternative way to inspect queue depth, throughput and worker health on the Enqueue connection, or reconsider whether the custom broker is worth losing that tooling. This is an operational trade-off, not a bug in the adapter.
- Are job batching, job middleware, retryUntil and failOnTimeout supported by the enqueue driver?
- These are the highest-risk features, because an adapter that lags behind Laravel's Job contract can silently ignore them rather than erroring. The symptoms are quiet: batches never complete, middleware never fires, or timeout hooks never run. Verify each feature you rely on with a test on the exact Laravel version and transport you will deploy, and re-check after every framework upgrade, because API drift in Illuminate is the most likely failure mode for this package.
- Where do failed jobs go when using enqueue/laravel-queue, and does queue:failed show them?
- This must be verified rather than assumed. Failed-job capture depends on how the adapter maps Laravel's failure handling onto Enqueue primitives, and dead-lettering is a broker-specific concern that varies by transport. Prove that a deliberately failing job lands where your on-call runbook expects, and that queue:failed, queue:retry and queue:forget behave as they do on native connections, before you route production traffic through it.
- Do delays, backoff, priorities and max attempts behave the same as native Laravel queues?
- No, and the package cannot make them uniform because those semantics are broker-specific. Laravel callers expect consistent behavior across connections, but delays, per-message TTL, priority, max attempts and dead-lettering are answered per transport rather than by the adapter. Document the real behavior for your chosen broker and avoid job classes that depend on features the transport does not genuinely provide.
- Is enqueue/laravel-queue actively maintained enough for production?
- Weigh it carefully. The repository has a modest star count, few reported dependents and a small contributor base, and the wider Enqueue ecosystem has had a sporadic release cadence. Before adopting, review the issue and pull request response times over the last twelve months and decide how you would handle a breaking change in Laravel's queue contract without upstream fixes. If you adopt, pin enqueue/* and the transport implementation deliberately, since version skew shows up as runtime fatals.
- Can non-Laravel consumers read messages produced by this driver?
- Only if you document and share the payload contract. Laravel job payloads are PHP-serialized inside the Enqueue message envelope, so a consumer written in another language cannot simply read the body. If interoperability is the reason you chose a standard broker, define the envelope format up front, or isolate Laravel-produced queues from queues consumed by other services. Getting this wrong surfaces at the worst possible moment, usually during a cross-team integration.