Rabbitmq Bundle Laravel Package

Product Decisions This Supports

• Queue/transport architecture selection. This package is one data point in the "how do we do async work in PHP" decision — RabbitMQ + AMQP vs. database queues vs. Redis vs. managed cloud queues (SQS, Google Pub/Sub). Seeing a once-popular bundle go stale is a signal about the maintenance burden of self-hosted AMQP in PHP.
• Build vs. buy vs. adopt. For a Laravel product, this is not a viable "adopt" candidate; it informs the buy managed or use a maintained Laravel-native adapter branch of the decision tree.
• Vendor and dependency risk scoring. Use it as a calibration example for your dependency review checklist: 1 star, 0 dependents, no release since 2018-06-15, single-org fork (KredytyChwilowki, a Polish lender). That's the profile of an internal fork published for convenience, not a product.
• Framework-fit gating. This is a Symfony bundle, not a Laravel package. It matters for roadmap decisions if you run a mixed Symfony/Laravel estate: it can serve Symfony services but tells you nothing about Laravel queue ergonomics.
• Legacy modernization planning. If any service in the portfolio already depends on oldsound/rabbitmq-bundle or this fork, that's a migration ticket (PHP 8 support, Symfony 5/6, security patching) you should budget for rather than a feature to build on.
• Use-case scoping for async work. It's relevant when scoping background jobs, webhook fan-out, email/SMS dispatch, spiky ingestion, or service-to-service events — the moments where a PM has to choose a messaging substrate.

When to Consider This Package

Consider it only in a narrow legacy scenario:

• The service is Symfony (not Laravel), pinned to an older Symfony/PHP line, and already has this bundle wired in. In that case, treat it as "keep the lights on," not as a strategic choice.
• You need a drop-in replacement for oldsound/rabbitmq-bundle in an existing Symfony app and cannot yet migrate.
• You're doing due diligence on an acquisition or audit and need to characterize an existing dependency.

Look elsewhere — decisively — when:

• You're on Laravel. This package provides no service provider, no Laravel queue driver, no config publishing. The realistic options are a maintained Laravel queue driver (e.g., vladimir-yuldashev/laravel-queue-rabbitmq), direct php-amqplib usage, or a managed queue.
• You need active maintenance. Last release 2018, 1 star, 0 dependents means no security patching, no PHP 8+ guarantees, no community support, and effectively no bus factor beyond one organization.
• You're greenfield. Building a new product on an abandoned fork is an avoidable technical-debt decision.
• You want managed infrastructure. SQS/Pub/Sub or a hosted RabbitMQ (CloudAMQP) shifts operational risk off your team — often the better PM-level trade for a small platform team.

How to Pitch It (Stakeholders)

Bottom line: do not adopt this package. kch/rabbitmq-bundle is a stale, single-organization fork of the old oldsound/rabbitmq-bundle, last released in June 2018, with one star and zero dependents. It is a Symfony bundle, so it doesn't serve our Laravel services at all, and it carries real maintenance and security risk for any service that does use it.

What it tells us strategically: self-hosting RabbitMQ in PHP has a well-known integration path, but the ecosystem's PHP-side adapters are inconsistently maintained. That argues for one of two positions rather than a middle ground — either standardize on a maintained Laravel-native queue driver with RabbitMQ, or move to a managed queue service and stop owning broker operations.

Recommendation for engineering: treat this package as a risk item, not a dependency to add. If any current service uses it or its predecessor, open a modernization ticket with a target framework/PHP version and a migration path. For new async work, evaluate the maintained Laravel adapter and a managed-queue option side by side on operational cost, not on feature parity — both will do the job.

Decision needed from leadership: approve the "managed queue vs. self-hosted RabbitMQ" call so the team stops re-litigating it per feature, and fund the legacy migration if the audit finds existing usage.