- How do I install and configure the RabbitMQ queue driver for Laravel?
- Install it with composer require vyuldashev/laravel-queue-rabbitmq, then publish the config file with php artisan vendor:publish and define your hosts, queues, and options in config/rabbitmq.php. Set QUEUE_CONNECTION=rabbitmq, or add a dedicated connection in config/queue.php and point workers at it with the --connection flag. You also need the bcmath, json, and sockets PHP extensions available, since php-amqplib handles the AMQP transport. After that your dispatch() and Bus calls keep working unchanged.
- Which Laravel and PHP versions does laravel-queue-rabbitmq support?
- The 14.x line targets Laravel 11 and 12 on PHP 8.2 through 8.4, using php-amqplib as the transport and RabbitMQ 3.12+/4.x as the broker. v14.4.0 added PHP 8.4 to the CI matrix, which is good evidence the suite passes there, but you should still validate against your own extension set in staging. Because Laravel patch releases have broken the driver before, version 14.4.0 specifically fixed compatibility with Laravel 12.34, treat whatever you install as a pin-and-test dependency rather than a floating one.
- Does this RabbitMQ driver work with Laravel Horizon?
- Horizon is built around Redis, and its throughput metrics, retry inspection, and job tagging assume a Redis backend, so do not assume full Horizon parity when you move queues to RabbitMQ. Verify what actually works in your Laravel and Horizon versions in a staging environment before cutting over. In practice most teams replace that visibility with the RabbitMQ management UI, rabbitmq_exporter plus Prometheus and Grafana, or a small custom dashboard. Budget that build cost as part of the migration, not after it.
- Do I need the rabbitmq_delayed_message_exchange plugin for delayed jobs?
- Delayed jobs depend on either the rabbitmq_delayed_message_exchange plugin or the driver's per-delay queue strategy, so the plugin path is a deployment prerequisite rather than an optional nicety. Some managed RabbitMQ offerings do not expose that plugin, which leaves you with per-delay-queue fan-out and the extra queues and consumers it creates. Confirm plugin availability with your broker provider before designing around delayed dispatch. If neither option fits your setup, keep delayed jobs on a separate connection.
- How do I configure priority queues and exchange routing in this driver?
- Queues and exchanges are declared in config/rabbitmq.php, where each queue entry can set its own options including max priority, durability flags, and binding routing keys. The driver maps Laravel queue names onto AMQP queues and exchanges, so routing stays configuration rather than application code. Quorum queues, priorities, and dead-lettering all work but require deliberate choices instead of defaults. Test the declarations against a real broker first, since queue arguments cannot be changed on an existing queue without deleting and recreating it.
- Can jobs run twice with the RabbitMQ queue driver?
- AMQP consumption is at-least-once, so a connection drop, a nack, or a worker crash can redeliver a message and execute the job again. Jobs must therefore be idempotent, with a dedup strategy such as unique keys or upserts wherever duplicates would be harmful. Teams migrating from the database or Redis drivers often discover duplicate-execution bugs in production because those semantics were previously tolerated. Audit your highest-volume jobs before moving them.
- How are failed jobs and retries handled with this Laravel queue driver?
- Laravel's normal retry and failure semantics still apply: failed jobs land in the failed_jobs table and can be retried with queue:retry and inspected with queue:failed. On the broker side you can configure dead-letter exchanges and queues in config/rabbitmq.php so rejected or expired messages route somewhere you can inspect. Make sure worker timeouts, tries, and max-time settings line up with the broker's consumer acknowledgement behaviour. Exercise the failure path end to end with a deliberately throwing job before going live.
- How do I test a Laravel app that uses the RabbitMQ queue connection?
- Queue::fake() and Bus::fake() work exactly as they do with any other driver, so unit tests need no broker at all. For integration coverage, run RabbitMQ in Docker or CI service containers and assert that a dispatched job is consumed and its side effects applied. Include at least one test that runs against the real broker whenever you upgrade Laravel or the package, because that is what catches a driver incompatibility. Keep it in CI rather than relying on manual staging checks.
- Is laravel-queue-rabbitmq actively maintained and safe to depend on?
- It is community maintained with a small contributor pool and no commercial SLA, with support handled through GitHub issues. Recent releases show responsiveness, including the Laravel 12.34 compatibility fix and PHP 8.4 CI coverage, but that is evidence of attention rather than deep bench strength. Pin the package to an exact version, run a queue integration test on every Laravel upgrade including patch releases, and keep a fork-and-patch plan in case upstream stalls. Teams without in-house AMQP operations experience should weigh that risk carefully.
- Can I migrate from Redis or database queues to RabbitMQ gradually?
- Yes, and you should avoid cutting over in place. Add the rabbitmq connection alongside your existing driver in config/queue.php, then move one non-critical queue such as notifications, search indexing, or webhooks end to end, including failure and retry behaviour. For the highest-volume queue, run dual dispatch or shadow consumption for one to two weeks to compare throughput and catch duplicated or lost jobs. Only then migrate the remaining queues and retire the old connection.