Rabbitmq Supervisor Bundle Laravel Package

Product Decisions This Supports

• Deployment and release reliability: 3.3.0 groups consumers so Supervisor signals them in parallel, meaning a fleet of RabbitMQ workers can be stopped/restarted together instead of sequentially. This directly shortens deploy windows and rollback times for message-driven features.
• Operational readiness of async workloads: The "wait for supervisord by default" change reduces startup race conditions — relevant if you run workers in containers or orchestrated environments where process ordering is not guaranteed.
• Build vs. buy for worker supervision: This package is a thin Symfony bundle that generates Supervisor configuration and manages consumer groups. It is not a queue framework, not a monitoring product, and not a Laravel package. The decision it informs is "do we standardise worker supervision on Supervisor + this bundle, or invest in a platform-native alternative?"
• Roadmap input for async/background processing: If your roadmap includes scaling consumers, graceful shutdown, or zero-downtime deploys, the parallel-signal capability is a concrete enabler. If your roadmap is moving toward Kubernetes Jobs, Laravel Horizon, or a managed queue platform, this package becomes transitional rather than strategic.
• Framework fit: The kernel.project_dir change is Symfony 3+ compatibility work. For a Laravel codebase this package is not a drop-in dependency — any adoption implies a Symfony service or a parallel Symfony process, which is a meaningful architectural decision, not a utility install.

When to Consider This Package

Consider it when:

• You run RabbitMQ consumers under Supervisor and want declarative, version-controlled consumer group definitions rather than hand-maintained .conf files.
• You need coordinated stop/start of many workers — the 3.3.0 parallel signalling is a real operational win at scale, and the supervisord wait reduces flaky cold starts.
• You are on Symfony 3+ or can isolate the bundle in a Symfony service alongside a Laravel application.
• You want a low-commitment, low-magic layer: it is configuration generation, so exit costs are low and the blast radius is small.

Look elsewhere when:

• You are Laravel-first — Horizon (Redis) or a queue-agnostic worker manager will fit more naturally, and forcing a Symfony bundle in adds a second framework runtime to maintain.
• You are container/Kubernetes-native — liveness probes, Jobs, and Deployments already solve process supervision; bolting Supervisor on adds a redundant control plane.
• You need observability, retry policies, dead-letter handling, or autoscaling — this package does none of those. Pair it with a real monitoring/alerting layer or choose a platform that bundles them.
• You require active vendor support or SLAs: this is a small community bundle with a single-maintainer risk profile.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost operational utility that makes our background message workers restart faster and more predictably during releases. Version 3.3.0 improves deploy speed by restarting worker groups in parallel and removes a class of startup race conditions. It is not a platform investment and carries minimal lock-in — but it also does not solve monitoring, retries, or autoscaling, so it should be framed as plumbing, not strategy.

To engineering: 3.3.0 groups consumers for parallel signal delivery, waits for supervisord by default, and resolves paths via kernel.project_dir on Symfony 3+. Net effect: faster graceful shutdowns and fewer ordering bugs in containerised setups. Caveats: this is a Symfony bundle, so Laravel adoption means a separate Symfony runtime or a manual port of the Supervisor config generation — evaluate against Horizon or native orchestration before committing. No breaking changes are apparent in this release, but confirm the new default supervisord wait behaviour against your existing startup scripts, since a blocking wait can change boot timing in tightly sequenced deployments.