Getting Started

This is a Symfony bundle, not a Laravel package. There is no service provider, no config/ publish tag, and no Laravel auto-discovery. Treat the first hour as an integration spike, not an install:

Pin an exact version before you install anything:
```
composer require myonlinestore/rabbitmq-manager-bundle:0.1.2
```
Then open the installed composer.json and confirm the PHP constraint. A 2017 release almost certainly targets PHP 5.6/7.0–7.1 and a Guzzle 5/6-era HTTP client. If your app runs PHP 8.x, expect conflicts before you expect functionality.
Read the source before wiring it up. Look for:
- the DependencyInjection/*Extension.php class — this is where the config keys for host/port/user/password/vhost actually live;
- the Resources/config/services.yml — the public service IDs you would otherwise get from Symfony’s container;
- the management client class that wraps the RabbitMQ HTTP API (typically on port 15672, not the AMQP port 5672).
Because Laravel won’t load the bundle, bind the underlying client yourself in a small service provider:
```
// app/Providers/RabbitAdminServiceProvider.php
$this->app->singleton(RabbitAdmin::class, function () {
    return new RabbitAdmin(
        config('rabbitmq.host'),
        (int) config('rabbitmq.management_port'), // 15672
        config('rabbitmq.user'),
        config('rabbitmq.password'),
        config('rabbitmq.vhost'),
    );
});
```
If the client requires a Symfony Extension/ContainerBuilder to configure it, that is a hard blocker — do not spend a day faking a DI container for a 0-star 2017 package. Fall back to calling the management HTTP API with Illuminate\Support\Facades\Http.
First use case to validate: a single Artisan command that lists queues and purges one queue by name against a real broker. If that works end to end (auth, vhost, JSON parsing, error handling), the rest of the package’s surface is likely usable. If it doesn’t, stop.

Implementation Patterns

Wrap it behind your own interface. The package is a pre-1.0 Symfony artifact with a fix-only changelog. Never let RabbitAdmin leak into controllers or jobs:

interface BrokerInspector {
    public function queues(): array;
    public function purge(string $queue): void;
    public function peek(string $queue, int $count = 10): array;
}

Bind the package implementation in a service provider. When the package dies or you outgrow it, you swap one binding and keep the rest of the app intact.

Operational commands, not ad-hoc calls. The package’s day-to-day value is admin tooling. Put everything behind Artisan:

rabbit:queues — list queues with message counts, consumers, and state.
rabbit:purge {queue} — require a --force flag; purge is irreversible.
rabbit:peek {queue} — fetch a few messages with ack_required=false and requeue=true so inspection does not destroy messages.
rabbit:health — fail non-zero if connections or queues exceed thresholds; wire this to your uptime monitor.

Configuration mirrors Laravel conventions. Add config/rabbitmq.php, source credentials from env, and keep the AMQP and management endpoints as separate values:

return [
    'host'            => env('RABBITMQ_HOST', '127.0.0.1'),
    'management_port' => env('RABBITMQ_MANAGEMENT_PORT', 15672),
    'amqp_port'       => env('RABBITMQ_PORT', 5672),
    'user'            => env('RABBITMQ_USER'),
    'password'        => env('RABBITMQ_PASSWORD'),
    'vhost'           => env('RABBITMQ_VHOST', '/'),
];

The vhost is part of every management URL path and needs URL-encoding (/ becomes %2F). Verify this early; it is the most common 404 cause.

Dashboard / admin-panel integration. If you are building an internal ops screen, expose the inspector through a thin controller and cache results for a few seconds. The management API is not designed to be hammered per page load, and this package almost certainly has no caching layer.

Debugging producer/consumer flows. The peek-and-publish capability is the real differentiator over raw amqp tooling: you can publish a known test payload into an exchange and confirm it lands in the expected queue without writing a throwaway producer. Use this in feature tests against a disposable broker in CI (Testcontainers or a docker compose service), not against a shared dev broker.

Do not conflate this with a Laravel queue driver. Laravel has no native RabbitMQ queue driver. This package manages the broker over the HTTP management API; it does not give php artisan queue:work a RabbitMQ backend. If your goal is “Laravel jobs on RabbitMQ,” you need a separate queue driver package (e.g. vladimir-yuldashev/laravel-queue-rabbitmq — verify current compatibility independently). This bundle is for inspection and administration only.

Gotchas and Tips

Framework mismatch is the primary cost. Symfony bundles rely on compiler passes and tagged services. Any non-trivial config path (connection pools, custom HTTP clients, event dispatchers) will require you to reimplement Symfony wiring or fork the extension class. Budget for this or pick a different solution.
The changelog is misleading. Release 0.1.2 says “Start supervisord in background,” which has nothing to do with RabbitMQ management. Treat the changelog as unmaintained and read the actual diff (v0.1.1..v0.1.2) on GitHub before upgrading.
Port confusion. The management UI/API is on 15672; AMQP is 5672. The package only speaks 15672. Errors here look like connection timeouts and are easy to misdiagnose as auth failures.
User permissions. Management operations require the user to have the management tag (and administrator for some operations like creating queues without a policy). A user with only AMQP permissions will get 401/403 from endpoints that “worked in the UI” for an admin account.
Vhost encoding. %2F for the default vhost in URL paths. Test against a non-default vhost too; some clients hard-code the empty vhost.
Purge is destructive and unpaginated. Purge removes all ready messages in a queue. Wrap it in confirmation, authorization, and an audit log entry. There is no undo.
Peek semantics. If the underlying call uses ackmode=ack_requeue_false, messages are consumed. Confirm the implementation uses ack_requeue_true (or equivalent) before using peek in debugging against production-like data.
Pagination. The RabbitMQ management API paginates queues/exchanges (page, page_size, name, use_regex). If the wrapper ignores these, list endpoints will silently truncate at the default page size. Check the source for how many results you actually get back.
Guzzle / Laravel dependency conflicts. Laravel 10/11 ships guzzlehttp/guzzle ^7. A 2017 bundle may require ^5 or ^6, or kriswallsmith/buzz. Resolve this before writing code; a composer why-not on the conflicting package will save hours.
No tests, no CI, 0 stars. There is no external safety net. Before adopting, add your own smoke test against a real broker in CI, and keep a plain Http::withBasicAuth(...) implementation of the two or three endpoints you actually use as a rollback path. That fallback is usually 50–100 lines and removes the dependency risk entirely.
Debugging technique. When a call returns an unexpected empty result or 404, curl -u user:pass http://host:15672/api/queues/%2F directly. If curl disagrees with the package, the package is the problem — not your broker.
Extension points to inspect. Favour configuring the connection through the bundle’s Extension class over subclassing client services. In early releases, subclassing internal services is the fastest way to break on patch releases.
Maturity verdict. As of 0.1.2 (September 2017) with no subsequent releases, this is a pilot-grade dependency at best. For teams that need broker admin tooling day-to-day, a thin in-house wrapper over the RabbitMQ HTTP API — typed, cached, tested, and shipped as an Artisan command set — is likely less total work than resurrecting this bundle on a modern Laravel version.

Rabbitmq Manager Bundle Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips