Rabbitmq Management Api Laravel Package

Product Decisions This Supports

• Build vs. buy for queue observability. This package is a thin, read-mostly HTTP client over RabbitMQ's Management API — the same endpoints your ops team uses in the RabbitMQ web UI. It does not touch the AMQP protocol, does not consume or publish messages, and does not manage broker topology beyond what the HTTP API exposes. Treat it as a reference implementation of the integration surface, not a dependency you inherit. Budget the build as days, not sprints.
• Feature: internal queue health dashboard. The highest-value PM use case is a read-only admin screen showing queue depth, consumer counts, unacked messages, publish/deliver rates, and memory per queue. This supports support-triage ("is the order-confirmation queue stuck?") and reduces escalations to the platform team.
• Feature: backlog alerting and SLOs. Queue depth is a leading indicator of user-visible latency. Polling /api/queues on a schedule and alerting on drain-rate rather than absolute depth is a cheap, high-leverage reliability feature — often more actionable than host-level metrics.
• Feature: multi-tenant queue provisioning. For SaaS products that give each tenant a queue or vhost, the Management API's declarative endpoints (create/delete queue, set policy/TTL/DLQ) enable self-serve onboarding without hand-editing broker config. This is the strongest product justification for touching the management surface at all.
• Roadmap signal, not roadmap item. Two stars, zero dependents, and a final release in March 2019 says the Laravel community has not standardized on this package. Absence of a dominant package here is a mild opportunity signal (see the elevated opportunity score) but is equally explained by teams using vendor dashboards, Prometheus exporters, or rabbitmqadmin instead of in-app code.
• Support tooling. "Requeue / purge / inspect a dead-letter queue" buttons inside your admin panel are a genuine support-cost reducer. Note that mutating operations (purge, delete) via HTTP are irreversible — gate them behind permissions and audit logging from day one.

When to Consider This Package

Adopt it — or, more likely, vendor a copy of it — only when all of the following hold:

• You are on Laravel/PHP and already run RabbitMQ; you are not considering a broker migration in the next 12 months.
• Your need is read/observe/provision via the Management HTTP API, not message production or consumption (that is php-amqplib or vladimir-yuldashev/laravel-queue-rabbitmq territory).
• You accept the maintenance burden: no releases since 2019, no dependents, no upstream triage. Expect to fork it, pin it, or reimplement. If your policy forbids unmaintained dependencies, this is already disqualifying.
• You have verified the endpoints you need against your actual broker version. RabbitMQ's management API has drifted across 3.7 → 3.8 → 3.9 → 4.x (metric naming, feature flags, removed queues fields, auth changes). A 2019 client will silently miss fields rather than fail loudly — plan for contract tests against a pinned broker image.
• Your volume is low enough that polling is acceptable. This library does not stream; every call is an HTTP round-trip. At high queue counts you want the Prometheus rabbitmq_exporter plus Grafana, not per-request PHP calls.

Look elsewhere when:

• You need metrics at scale. Prometheus + rabbitmq_exporter + Grafana is the industry-standard answer and is maintained. Do not build a metrics pipeline in PHP.
• You're on Redis. Laravel Horizon already solves queue visibility; this package is irrelevant.
• You need exactly one or two endpoints. Writing ~150 lines around Guzzle with your own DTOs will be cheaper than adopting, learning, and eventually forking this.
• Compliance/security review flags unmaintained deps. With zero dependents there is no community CVE-watching; you own it entirely.
• You want a PHP-native management UI. Prefer the RabbitMQ web UI behind SSO, or a declarative GitOps approach (rabbitmqadmin/definitions JSON in CI) over embedding broker admin into your product.

How to Pitch It (Stakeholders)

To executives: RabbitMQ already exposes everything we need to see and control our queues over HTTP; this package is a small PHP convenience layer on top of that API. We should not adopt it as a long-term dependency — it's two GitHub stars, zero downstream users, and hasn't shipped since 2019 — but it's a useful blueprint. Recommendation: spend a short, bounded engineering effort reimplementing the handful of calls we need against a supported HTTP client. That gives us queue-health dashboards, backlog alerting, and self-serve tenant provisioning without taking on an unmaintained third-party risk. Cost is days, not a quarter.

To engineering: This is a thin, MIT-licensed HTTP wrapper — no AMQP, no worker integration. It saves maybe a day of endpoint discovery and then becomes a liability: untyped responses, no coverage of RabbitMQ 3.9/4.x field changes, no error handling for the auth and pagination edge cases we'd hit. Proposal: use it as a spec, write a ~200-line internal client with typed DTOs, contract tests against a pinned broker container, and read-only scopes by default. Mutating endpoints (purge/delete) get separate credentials and audit logging.

Decision requested: approve the small internal build rather than the dependency, and confirm we are not planning a broker change in the next year — that assumption is what makes the build worthwhile.