Pheanstalk Bundle Laravel Package

Product Decisions This Supports

• Queue-infrastructure selection for PHP services. Choosing Beanstalkd as the job backend is a real product decision (job latency, at-least-once semantics, ops overhead, observability). This package is the "last mile" of that decision in a Symfony codebase — it wires the Pheanstalk client into the DI container and, more importantly, ships an operator CLI.
• Operational tooling vs. customer-facing features. The bundle's actual product value is the command-line console: inspecting tubes, peeking at ready/buried jobs, kicking, pausing, and pulling server stats. That's an internal-ops capability, budgeted differently from feature work — it's about mean-time-to-recovery when a queue backs up, not about new revenue.
• Build vs. buy for admin surface. Wrapping Pheanstalk directly is ~50 lines; wrapping it plus a maintained CLI of inspection commands plus Symfony service wiring is more. This package is the "buy" (adopt) option for that admin surface — cheap, MIT, but with a maintenance tail.
• Build vs. buy for the queue client itself. Because it sits on Pheanstalk, the underlying transport is a mature, single-purpose protocol client. The decision to adopt this bundle is really "do we standardize on Beanstalkd + Pheanstalk, or move to Redis/SQS/database queues?"
• Roadmap sequencing for queue migration (now broader). 4.0.4 adds Symfony 6 compatibility, which moves this bundle from "legacy-only" to "plausible for a currently-supported Symfony app that is still on Beanstalkd." That changes the shape of the decision: for Symfony 6 teams the choice is now genuinely keep the bundle on Beanstalkd vs. migrate to Symfony Messenger, rather than "you have no option but Messenger."
• Vendor/legacy triage. Still a 1-star, 0-dependent package, but the 4.0.4 release is fresh evidence that someone is tending it. That supports a decision like "pin, fork internally, or replace" — a discrete, low-risk roadmap item rather than a platform bet. Note the compatibility work landed in a patch version (4.0.4), which is a signal about release discipline: verify the Symfony 6 support yourself before assuming the integration is idiomatic (autowiring, service definitions, PHP version constraints).

Important framing correction for stakeholders: despite the package naming, this is a Symfony bundle, not a Laravel package — and 4.0.4 does not change that. In a Laravel codebase it does not integrate with the framework's queue/worker abstractions (Queue, Job, Horizon), so adopting it means running a parallel, non-idiomatic queue path. That's a material product cost and should be priced into any decision. The Symfony 6 update is irrelevant to Laravel services.

When to Consider This Package

Consider it when:

• You maintain a Symfony 2.x–6.x application already running Beanstalkd, and you need operator commands (stats, peek, pause, kick) without writing them. New: Symfony 6 apps are no longer excluded by the compatibility story as of 4.0.4.
• You want a small, MIT-licensed internal admin console for a queue that is already a sunk cost — not a new strategic dependency.
• Your team is comfortable pinning and patching a low-activity dependency, or forking it in-house. The 4.0.4 release lowers but does not eliminate this concern: a four-year gap followed by a single compatibility patch is caretaking, not a support commitment.
• The queue is non-critical or well-isolated: internal batch jobs, deferred emails, media processing — work where a stalled tube is an inconvenience, not an outage.
• You need something working this sprint, and the alternative is weeks of platform work.

Look elsewhere when:

• You're on Laravel. Use the native queue system with Redis/SQS/database drivers and Horizon for visibility; there is no reason to bolt on a Symfony bundle here. 4.0.4 does nothing for you.
• Symfony 6 teams evaluating queue strategy from scratch. 4.0.4 makes this bundle usable, but Symfony Messenger with a Beanstalkd transport remains the first-party, idiomatic path with maintained DI conventions, retry/dead-letter semantics, and a real roadmap. Adopt this bundle only if you're staying on Pheanstalk deliberately or already have it deployed.
• You need managed, durable, or high-throughput queues. Beanstalkd is a single-node, in-memory-ish server; SQS, RabbitMQ, or Kafka are the strategic answers, and this bundle doesn't shorten that path.
• Supply-chain hygiene matters to your org. The stars/dependents/activity picture is unchanged; a single patch release after a long dormancy may still fail a dependency-review gate. Expect to justify it or vendor it.
• You need observability integration (metrics, tracing, structured retries, dead-letter semantics). This gives you CLI access, not a telemetry story.

How to Pitch It (Stakeholders)

For executives (30 seconds):

This is a small, free, open-source utility for PHP applications that run background jobs on a queue server called Beanstalkd. It doesn't create new product capability — it gives engineers a command-line window into that queue, so they can see what's stuck and unstick it faster. A new release adds support for a more recent version of the PHP framework it plugs into, which widens where it can run but doesn't change its strategic weight. Risk remains modest but real: the project has been largely dormant, so if we adopt it we own patching it. Recommendation: treat it as a tactical ops convenience for existing Beanstalkd deployments, not a platform standard, and keep a time-boxed replacement plan behind it. It still does not apply to our Laravel services.

For engineering leads:

Pheanstalk is a solid, boring Beanstalkd client; the bundle adds Symfony service wiring plus a CLI of inspection/maintenance commands (stats, peek, pause, kick). 4.0.4 adds Symfony 6 compatibility — the first functional change in years, and it means teams on a supported Symfony can now run this without being pinned to an EOL framework. Caveats: the compat work shipped as a patch bump, so read the diff, check autowiring/service-definition changes, and pin the version; the project is still 1-star, 0-dependents, with no visible security process, so vendor it if it's on your critical path. If you're greenfield or on modern Symfony, Messenger is still the better default — wrapping Pheanstalk directly is trivial if all you want is the client and a couple of commands.

The one-liner decision rule: Adopt to shorten MTTD/MTTR on an existing Beanstalkd queue — now including Symfony 6 — but only if you're content to own patching it; new queue work should go to Messenger or the native framework queue.