- Does leezy/pheanstalk-bundle work in a Laravel application?
- No. It is a Symfony bundle that wires the pda/pheanstalk client into Symfony's dependency injection container, configuration tree and console, and Laravel has no bundle concept at all. There is no service provider, no facade, no queue connector and no publishable config, so composer require gives you nothing Laravel can dispatch jobs through. For a Laravel codebase you should use the framework's built-in beanstalkd queue driver, which sits on top of the same Pheanstalk client.
- How do I install leezy/pheanstalk-bundle in a Symfony project?
- Run composer require leezy/pheanstalk-bundle, then register LeezyPheanstalkBundle in config/bundles.php (or AppKernel for older Symfony versions). Add a leezy_pheanstalk block to your config file with at least one connection, and inject the generated connection service into whichever service produces or consumes jobs. Check the Symfony and PHP constraints on Packagist first, because bundle structure and DI APIs move between Symfony majors and an old constraint set may pin you off your target runtime.
- What should Laravel developers use for beanstalkd queues instead of this bundle?
- Use Laravel's native beanstalkd queue driver: set QUEUE_CONNECTION=beanstalkd, configure the beanstalkd entry in config/queue.php with host, port and queue name, and require pda/pheanstalk in composer.json. You then dispatch jobs with the normal dispatch() helper or Queue::push and consume them with php artisan queue:work beanstalkd. That gives you failed-job handling, retries, backoff, queue priorities and testing helpers that the Symfony bundle never provides to Laravel.
- How do I configure multiple beanstalkd connections and timeouts with this bundle?
- Define a leezy_pheanstalk connections map in your Symfony config, keyed by connection name, with host, port and timeout per server. One connection is marked as the default, and you can inject a specific named connection service or rely on autowiring aliases for the default one. Keep timeouts short enough that an unreachable beanstalkd host fails fast instead of blocking your request cycle.
- Which Symfony and PHP versions does leezy/pheanstalk-bundle support, and is it still maintained?
- Verify the exact constraint matrix on Packagist before adopting it, because the public signals around this package are weak: roughly 124 stars, no dependents and a single maintainer. For infrastructure glue, near-zero downstream usage means near-zero community testing and a high chance of drift when a new Symfony or PHP major lands. Pin it, run your test suite on your exact runtime, and check the last release date plus any maintained forks before you build on it.
- Is beanstalkd reliable enough for production background jobs?
- Beanstalkd is an in-memory work queue by default, so a broker restart or host loss silently discards jobs that were still queued unless you run it with the binlog enabled. The bundle only wires up the client; it adds no durability, replication or delivery guarantee of its own, and teams sometimes assume otherwise. It fits short-lived, idempotent, latency-sensitive jobs well, and fits durable, retry-heavy or long-running workloads poorly. If you need persistence across restarts, enable the binlog or choose a different broker.
- How do I run and monitor beanstalkd workers for this bundle?
- The bundle ships console commands and exposes the Pheanstalk connection as a service, so your own worker command can reserve, process, delete or bury jobs from a named tube. In production, run those commands under Supervisor or systemd so they restart on failure rather than as ad-hoc foreground processes. Monitoring comes from Pheanstalk stats calls on tubes and the server, plus the bundle's profiler integration during development, and third-party beanstalkd console UIs for day-to-day queue inspection.
- How do I test code that pushes jobs onto a beanstalkd queue?
- Because the Pheanstalk client is a concrete class, the cleanest approach is to inject the bundle's connection service and replace it with a test double that records pushed payloads. In Laravel you do not need any of this: Queue::fake() plus assertPushed or assertPushedOn covers the same assertions with no broker required. For end-to-end confidence, point tests at a real beanstalkd instance using a dedicated tube and clean it between runs.
- Can I bridge leezy/pheanstalk-bundle into Laravel with a custom service provider?
- It is technically possible to wrap the bundle's services in a Laravel provider, but it buys you nothing: Laravel's native driver already uses the same pda/pheanstalk client underneath. You would be building a fork or re-implementation to reach zero incremental capability, which is pure maintenance overhead. The only defensible reason is a polyglot PHP estate that has deliberately standardized on a shared beanstalkd transport across Symfony and Laravel services.
- What are the alternatives to this bundle for background job processing?
- In Laravel, the realistic options are the native beanstalkd driver, Redis with Horizon, Amazon SQS, or the database queue driver for low-volume work. In Symfony, the comparable choice is Symfony Messenger with a beanstalkd or AMQP transport, or Enqueue for multi-transport abstraction. If you genuinely need raw tube-level control, priority and TTR handling, use pda/pheanstalk directly rather than going through a bundle that is not maintained for your stack.