- Is almatar/rabbitmq still maintained?
- No. The package is explicitly marked DEPRECATED in its own description, the GitHub repository is archived, and the maintainer redirects users to vladimir-yuldashev/laravel-queue-rabbitmq. An archived repository receives no pull requests, security patches, or compatibility work for new PHP and Laravel releases. Treat any recent release date as a terminal deprecation marker rather than a sign of ongoing maintenance.
- How do I install almatar/rabbitmq in a Laravel or Lumen application?
- Installation is a normal Composer require of almatar/rabbitmq, followed by registering the package service provider so the RabbitMQ queue connector is available to Laravel's queue manager. Because the repository is archived, a fresh composer require against current framework constraints may fail or resolve to stale dependencies, even if an existing lockfile still installs cleanly. For new work you should install the maintained alternative instead.
- Which Laravel and PHP versions does almatar/rabbitmq support?
- Support is defined entirely by the composer.json constraints shipped in the final archived release, so you must check those constraints against your locked dependency matrix before assuming compatibility. The package was written against older Laravel and Lumen generations and is not a candidate for modern Laravel 10, 11, or 12 services. Framework queue contracts such as connector registration, job popping, and worker events change across majors, and an unmaintained driver tends to fail at runtime rather than at install time.
- What is the recommended alternative to almatar/rabbitmq?
- The maintainer's own recommendation, and the sensible default, is vladimir-yuldashev/laravel-queue-rabbitmq as the sanctioned AMQP queue driver. It is actively maintained, covers the same php-amqplib-based queue connector seam, and avoids the transitive security and framework-drift risk of an archived package. Standardize on it across the estate and block almatar/rabbitmq for new work via a dependency allowlist or CI check.
- How do I configure a RabbitMQ queue connection with almatar/rabbitmq?
- You add a connection entry in config/queue.php with the rabbitmq driver and the usual AMQP host, port, credentials, queue, and exchange settings, then let Laravel resolve it through Queue::connection('rabbitmq'). The package is a thin adapter over php-amqplib, so message semantics, exchange topology, and worker lifecycle remain with RabbitMQ and Laravel's queue worker rather than the package. If your code also calls exposed AMQP helpers directly instead of only using the queue connector, migration cost will be higher.
- Does almatar/rabbitmq work with Lumen?
- Yes, the package is described as a RabbitMQ adapter for Lumen and registers a service provider plus queue connector accordingly. That said, it is archived and was written against older Lumen and Laravel generations, so verify the framework version before relying on it. If Lumen support is a hard requirement, confirm the recommended successor covers your Lumen version before committing to the swap.
- How do I migrate from almatar/rabbitmq to a maintained RabbitMQ driver?
- The seam is small: inventory every rabbitmq connection in config/queue.php and any direct calls to the package's AMQP helpers, then swap the driver to vladimir-yuldashev/laravel-queue-rabbitmq and re-point the connection configuration. Confirm that exchange names, routing keys, and payload envelopes are preserved so messages already in flight remain consumable. Most migrations complete in days rather than quarters because the package does not own messaging semantics.
- Is almatar/rabbitmq safe to use in production?
- It carries high, asymmetric risk: pinned php-amqplib versions will age out of security coverage with no patch path short of forking, and the project has a bus factor of effectively zero. The most likely failure mode is a runtime break in production workers after a PHP or Laravel upgrade rather than an install-time error. With an actively maintained alternative available, there is no architectural justification for accepting that risk.
- Can I fork or vendor almatar/rabbitmq instead of replacing it?
- The MIT license does allow forking or vendoring, which is the only defensible option for a legacy application pinned to an end-of-life Laravel version where the driver swap is blocked. Treat that as a debt instrument: freeze the vendored copy, attach an owner, and set an exit date. Forking converts a dependency cost into a permanent headcount cost, which is rarely the right trade for a small wrapper with a maintained alternative.
- How do I test jobs dispatched through almatar/rabbitmq?
- The package ships no testing helpers, but it only registers a queue connector, so standard Laravel testing practices apply. Use Queue::fake() to assert that jobs are dispatched and test your job classes directly with the bus or queue fakes. Keep an integration test against a real RabbitMQ instance for the connection configuration, since that is the piece most likely to break during a driver migration.